feat: add LiteLLM OAuth2 SSO authentication button #6612
Conversation
Implement OAuth2 SSO integration for LiteLLM proxy authentication: - Add OAuth URL generator for LiteLLM SSO flow with proper redirect_uri - Implement URI callback handler for LiteLLM OAuth2 responses - Add ClineProvider method to handle LiteLLM OAuth callback and store tokens - Create LiteLLM SSO authentication button in settings UI - Add internationalization support for LiteLLM OAuth button text This enables users to authenticate with their LiteLLM proxy via SSO by: 1. Entering their LiteLLM base URL in settings 2. Clicking "Get LiteLLM API Key via SSO" button 3. Completing OAuth flow in browser 4. Automatically receiving and storing the API token The implementation follows OAuth2 RFC 6749 standards and supports both JSON response format and VSCode extension redirect flows as implemented in LiteLLM PR #13227.
![roomote[bot]](https://avatars.githubusercontent.com/in/1546624?s=60&v=4){kind=small}
| await visibleProvider.handleLiteLLMCallback({ | ||
| accessToken, | ||
| tokenType: tokenType || "Bearer", | ||
| expiresIn: expiresIn ? parseInt(expiresIn, 10) : 86400, |
There was a problem hiding this comment.
Is 86400 seconds (24 hours) a reasonable default for token expiry? Some OAuth tokens might have much shorter lifespans. Could we consider a more conservative default or make this configurable?
|
|
||
| // Store the OAuth response metadata | ||
| const { accessToken, tokenType, expiresIn, scope } = oauthResponse | ||
| const expiresAt = new Date(Date.now() + expiresIn * 1000).toISOString() |
There was a problem hiding this comment.
The token expiry time is calculated and logged but doesn't appear to be used elsewhere. Consider implementing token refresh logic or at least warning users when their token is about to expire. This would improve the user experience by preventing unexpected authentication failures.
| requestyDefaultModelId, | ||
| openRouterDefaultModelId, | ||
| glamaDefaultModelId, | ||
| litellmDefaultModelId, |
There was a problem hiding this comment.
I notice litellmDefaultModelId is imported here. Could you confirm this constant is already defined in the @roo-code/types package? I want to ensure we're not missing any type definitions.
| } | ||
|
|
||
| export function getLiteLLMAuthUrl(baseUrl: string, uriScheme?: string) { | ||
| const cleanBaseUrl = baseUrl.replace(/\/+$/, "") |
There was a problem hiding this comment.
Consider adding URL validation before constructing the OAuth URL. Something like:
| const cleanBaseUrl = baseUrl.replace(/\/+$/, "") | |
| export function getLiteLLMAuthUrl(baseUrl: string, uriScheme?: string) { | |
| try { | |
| new URL(baseUrl); // Validate URL format | |
| } catch (error) { | |
| throw new Error('Invalid LiteLLM base URL'); | |
| } | |
| const cleanBaseUrl = baseUrl.replace(/\/+$/, "") | |
| return `${cleanBaseUrl}/sso/key/generate?response_type=oauth_token&redirect_uri=${getCallbackUrl("litellm", uriScheme)}` | |
| } |
This would prevent malformed URLs from causing issues downstream.
| } | ||
|
|
||
| // LiteLLM | ||
| async handleLiteLLMCallback(oauthResponse: { |
There was a problem hiding this comment.
Consider adding inline documentation explaining the OAuth flow or linking to LiteLLM's OAuth documentation. This would help future maintainers understand the integration better. For example:
| async handleLiteLLMCallback(oauthResponse: { | |
| // LiteLLM OAuth2 SSO integration | |
| // This implements the OAuth2 flow described in LiteLLM PR #13227 | |
| // The flow: User clicks SSO button -> Redirected to LiteLLM OAuth page -> | |
| // LiteLLM redirects back with access_token -> Token stored as API key | |
| async handleLiteLLMCallback(oauthResponse: { |
hannesrudolph
added
the
Issue/PR - Triage
hannesrudolph
added
PR - Draft / In Progress
and removed
Issue/PR - Triage
github-project-automation
bot
moved this from PR [Draft / In Progress]
to Done
in Roo Code Roadmap
2 participants
Related GitHub Issue
N/A
Roo Code Task Context (Optional)
<!-- This implementation was developed based on LiteLLM PR #13227 and implementing the corresponding RooCode integration -->
Description
This PR implements OAuth2 SSO integration for LiteLLM proxy authentication, enabling users to authenticate with their LiteLLM proxy via SSO and automatically configure their API key in RooCode.
Key Implementation Details:
response_type=oauth_tokenparameter/litellmroutehandleLiteLLMCallback()method in ClineProvider to process OAuth responsesDesign Choices:
Test Procedure
Manual Testing Steps:
https://your-litellm-proxy.com)Testing Environment:
Pre-Submission Checklist
Screenshots / Videos
<!-- To be added after manual testing with LiteLLM proxy instance -->
Documentation Updates
Additional Notes
This implementation is designed to work with LiteLLM proxies that have the OAuth2 SSO endpoint from LiteLLM PR #13227. The feature provides a seamless authentication experience similar to other OAuth providers (OpenRouter, Glama, Requesty) already implemented in RooCode.
The OAuth flow supports: