Made member token scope authoritative#28346
Conversation
Member identity and entitlement tokens are issued by the same service with the same signature, issuer, and audience, and were only differentiated by a descriptive scope claim that nothing enforced. This makes scope the source of truth for a token's purpose: identity tokens now declare members:identity and the identity decode path requires it, so read-only entitlement tokens are not silently accepted in its place. The change is additive to the entitlement token payload, so consumers verifying it via the JWKS are unaffected.
WalkthroughThis PR introduces standardized JWT scope handling in 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Member identity and entitlement tokens are issued by the same service with the same signature, issuer, and audience, and were only differentiated by a descriptive
scopeclaim that nothing enforced.This makes
scopethe source of truth for a token's purpose:scope: members:identitydecodeToken) requires that scope and rejects anything elseThe change is additive to the entitlement token payload, so anything verifying it via the JWKS is unaffected. This feels like a more correct pattern than assuming tokens can act as members, which was the prior behavior.
Tests
Updated the
token-serviceunit tests to cover the identity/entitlement scopes and the decode-path enforcement.