Add token endpoint handler #3408
Open
+593
−10
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #3408 +/- ##
==========================================
+ Coverage 64.83% 64.88% +0.05%
==========================================
Files 380 382 +2
Lines 37004 37082 +78
==========================================
+ Hits 23992 24062 +70
- Misses 11127 11128 +1
- Partials 1885 1892 +7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
tgrunnagle
previously approved these changes
Jan 22, 2026
Implement POST /oauth/token handler that exchanges authorization codes for access tokens using fosite's access request/response flow. The handler validates the incoming token request, retrieves the stored authorization session, generates JWT access tokens, and supports RFC 8707 resource parameter for audience-restricted tokens targeting specific MCP servers. This handler completes the OAuth 2.0 authorization code flow started by the authorize and callback handlers. When a client presents an authorization code, fosite retrieves the session that was stored during the callback phase - this session contains the user's subject, the upstream token session ID (tsid), and the client ID binding. The token endpoint uses these stored claims to generate the access token, maintaining the link between issued tokens and upstream IDP tokens for later token injection by the proxy middleware. The test infrastructure is extended to properly track authorization code and PKCE sessions across the full authorize→callback→token flow.
Implement proper validation of the resource parameter in the token endpoint per RFC 8707. Previously, any client-provided resource was blindly granted as the token audience, which was a security risk. Changes: - Add ErrInvalidTarget error for RFC 8707 invalid_target responses - Add ValidateAudienceURI to validate URI format (absolute, no fragment, http/https only) - Add ValidateAudienceAllowed to check resources against an allowlist - Add AllowedAudiences config field to AuthorizationServerParams and AuthorizationServerConfig - Update TokenHandler to validate before granting audience - Secure default: empty AllowedAudiences rejects all resource requests Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
jhrozek
force-pushed
the
auth-proxy-pr-10-2-handlers-token
branch
from
b09fb39 to
f78d47e
Compare
github-actions
bot
added
size/L
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement POST /oauth/token handler that exchanges authorization codes for access tokens using fosite's access request/response flow. The handler validates the incoming token request, retrieves the stored authorization session, generates JWT access tokens, and supports RFC 8707 resource parameter for audience-restricted tokens targeting specific MCP servers.
This handler completes the OAuth 2.0 authorization code flow started by the authorize and callback handlers. When a client presents an authorization code, fosite retrieves the session that was stored during the callback phase - this session contains the user's subject, the upstream token session ID (tsid), and the client ID binding. The token endpoint uses these stored claims to generate the access token, maintaining the link between issued tokens and upstream IDP tokens for later token injection by the proxy middleware. The test infrastructure is extended to properly track authorization code and PKCE sessions across the full authorize→callback→token flow.