feat: re-check the app allowlist at OAuth2 code redemption - #28740
Draft
BobbyHo wants to merge 2 commits into
Draft
feat: re-check the app allowlist at OAuth2 code redemption#28740BobbyHo wants to merge 2 commits into
BobbyHo wants to merge 2 commits into
Conversation
An authorization code's scope is checked against the app's registered scopes when the code is issued, and the code stays valid for ten minutes after that. An admin who narrows the registration in that window had the narrowing ignored: the code still minted a token carrying the wider scope. authorizationCodeGrant now re-checks the code's stored scope against the registration as it stands at redemption, and refuses with invalid_scope when it is no longer covered. The catalog filter and the coverage loop move out of negotiateScope into grantableScopes and firstScopeOutsideAllowlist so both sides run the same comparison; each caller picks its own rejection reason. Refresh is deliberately left alone. RFC 6749 section 6 bounds a refresh by the scope originally granted, so a narrowing takes effect at the next authorization instead of dropping capability from a live session.
Contributor
Docs previewCheck off each page once it's been reviewed. If a page changes in a later push, its checkbox clears automatically so it gets a fresh look. Pages not yet wired into the docs navigation aren't listed here. |
Drop what the code already says and keep the parts that are not visible from it: the canonical precondition on firstScopeOutsideAllowlist, why refresh is exempt, and why the stored scope is canonicalized again. ReasonStaleScope moves into the existing export block in authorize_internal_test.go rather than repeating its comment.
This was referenced Aug 28, 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
1 participant
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.
TL;DR
Second of the PLAT-480 stack, stacked on #28237. #28237 made the negotiated scope bound the issued token; this PR makes an administrator's narrowing of an app's registered scopes apply to codes that were already issued.
An authorization code is valid for ten minutes, and its scope is checked against the app's registered scopes exactly once, when the code is issued. An administrator who narrowed the registration inside that window had the narrowing ignored: the code still redeemed for a token carrying the wider scope.
Depends on #28237
Stack: #28237, this PR, #28744.