Add shared OAuth constants and expose ExchangeConfig fields#5003
Merged
Add shared OAuth constants and expose ExchangeConfig fields#5003
Conversation
Add token-type URNs (access_token, id_token, jwt) and the token-exchange grant-type URN to pkg/oauth, and replace private constants in pkg/auth/tokenexchange with references to the shared pkg/oauth definitions. Expose RequestedTokenType and Resource fields on tokenexchange ExchangeConfig so callers can request non-default token types (RFC 8693) and specify an RFC 8707 resource indicator. Additional URN constants (JWT-Bearer grant, ID-JAG token type) will be added by the PRs that introduce their first consumers. Enforce RFC 8707 Section 2 constraints on Resource in ExchangeConfig.Validate(): reject non-absolute URIs and URIs with a fragment component. The godoc already stated the contract; this makes Validate() fail loudly at config time rather than forwarding a bad resource indicator to the STS. Regenerate docs/server/ to pick up the updated SubjectTokenType godoc wording in tokenexchange.Config.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5003 +/- ##
=======================================
Coverage 69.05% 69.06%
=======================================
Files 554 554
Lines 73160 73176 +16
=======================================
+ Hits 50521 50538 +17
- Misses 19625 19627 +2
+ Partials 3014 3011 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
JAORMX
approved these changes
Apr 22, 2026
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
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.
Summary
This is preparatory refactoring for the XAA (Cross-Application Access) / ID-JAG work landing on top of this branch. It does two things together because the second depends on the first:
pkg/oauth(which already houses RFC 6749 grant types, RFC 7636 PKCE, RFC 7591 auth methods, and the well-known discovery paths) so follow-up work has a single place to reference them.RequestedTokenTypeandResourceonExchangeConfig. The privateexchangeRequeststruct has carriedResourcesince the original RFC 8693 implementation (Implement OAuth 2.0 Token Exchange (RFC 8693) support #2082), but there was no way for a caller to set it. Upcoming work (the XAA strategy) needs to override both fields. Additive; zero values preserve prior behavior.Resource"Must be an absolute URI without a fragment" per RFC 8707 §2, butValidate()didn't enforce it. Now it does, so misconfigurations surface at config time instead of as opaque STS errors at runtime.Type of change
Primarily a constants-move refactor. The new
ExchangeConfigfields are additive (zero values = prior behavior). The only actual behavior change is the newResourceURI validation, which rejects inputs that the godoc already prohibited.Test plan
task test)task test-e2e)task lint-fix)New
TestExchangeConfig_Validate_Resourcecovers 7 cases (empty, absolute https, absolute urn, relative path, scheme-less host, URI with fragment, malformed URI). NewTestTokenSource_Token_RequestedTokenTypeAndResourcecovers wire-level propagation of both new fields (defaults, each field alone, both together). Existing tests pass unchanged.Changes
pkg/oauth/constants.goTokenType{AccessToken,IDToken,JWT}andGrantTypeTokenExchangeURN constants.pkg/auth/tokenexchange/exchange.gooauth.*references; addRequestedTokenTypeandResourcetoExchangeConfig; enforce RFC 8707 §2 onResourceinValidate(); includeResourcein the redactedString()output.pkg/auth/tokenexchange/middleware.gooauth.*constants.pkg/auth/tokenexchange/exchange_test.godocs/server/{docs.go,swagger.json,swagger.yaml}SubjectTokenTypegodoc wording.Does this introduce a user-facing change?
No. The new
ExchangeConfigfields are not yet surfaced through the middlewareConfigstruct or any CRD, so they are only reachable by in-process callers that constructExchangeConfigdirectly. Wiring through the higher-level config layers will land with the first consumer.Special notes for reviewers
RequestedTokenTypeis intentionally left as an open-ended string (no normalization). The XAA strategy in the follow-up stack sets it tourn:ietf:params:oauth:token-type:id-jag, which wouldn't survive a short-form allowlist check.🤖 Generated with Claude Code