paragraaf 4.2 token introspection
Opened this issue · 1 comments
Omschrijving
In paragraaf 4.2 staat het volgende:
“Protected resources MUST interpret access tokens using either JWT, token introspection, or a combination of the two.
The protected resource MUST check the aud (audience) claim, if it exists in the token, to ensure that it includes the protected resource's identifier. The protected resource MUST ensure that the rights associated with the token are sufficient to grant access to the resource. For example, this can be accomplished by querying the scopes and acr associated with the token from the authorization server's token introspection endpoint.”
Waarom bijvoorbeeld OAuth scope en ACR claim checken tegen het introspection endpoint? Als is gekozen voor een JWT token wil je zo min mogelijk contact hebben met het token introspection endpoint (onder meer uit performance oogpunt). Afhankelijk van de dataclassificatie kan je vanaf een bepaalt niveau, checken bij het token introspection endpoint of het OAuth access token nog geldig is (never trust, always verify). In het geval dat de dataclassificatie onder het afgesproken niveau is, kan je het OAuth access token op geldigheidsduur (tijd) laten verlopen (hiervoor heeft MS gekozen bij Azure AD). De scope en acr claim zou ik opnemen in het OAuth access token en vervolgens de resource hierop laten checken.
Waarom is niet gekozen voor deze optie?
Tevens staat beschreven “…, if it exists in the token, ..” zie geel gearceerde tekst. In mijn ogen betekent dit dat het mogelijk is dat de aud claim leeg is. Hoe moet ik dit lezen in combinatie met RFC 7519 - 4.1.3?
“ Enige toelichting nog op mijn vraag.
Aud claim in OAuth access token is volgens mij verplicht. Zie RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (ietf.org) paragraaf 2.2
Ik heb geschreven: “De scope en acr claim zou ik opnemen in het OAuth access token en vervolgens de resource hierop laten checken.”. Ik bedoel uitsluitend de acr claim toevoegen aan het OAuth access toeken (scope blijft optioneel). De reden is dat het Authentication Assurance Level in mijn ogen een essentiële toegangsparameter is voor de data in verband met zero trust.”
Naam
Jeroen Mol
No response
Organisatie
RWS
Wat is er mis met deze tekst? Het voorbeeld vind ik wel redelijk goed: vaak wil het het token:
- centraal valideren bij een introspection of token exchange endpoint (zeker als het externe token ingetrokken mag worden en/of opaque is). Zie ook best current practices van Gartner ID G00723547. In sommige gevallen is dit niet nodig.
- inwisselen voor een token met meer informatie voor de back-end. Daarbij wil je vaak (maar niet altijd) de "scope", "aud" en/of "acr_value" vertalen in claims die de back-end resource begrijpt. Deze kunnen opgenomen worden in authorization_details, zie RAR, https://datatracker.ietf.org/doc/html/rfc9396
Ik zou het laatste stukje van de de tekst veranderen in de bovenstaande paragraaf:
"The protected resource MUST check the aud (audience) claim, if it exists in the token, to ensure that it includes the protected resource's identifier. The protected resource MUST ensure that the rights associated with the token are sufficient to grant access to the resource. For example, this can be accomplished by querying the scopes and acr associated with the token from the authorization server's token introspection endpoint.”
Originele tekst "authorization server's token introspection endpoint"
Voorstel: "authorization server's token introspection or token exchange endpoint"
Er kunnen redenen zijn dat in een bepaalde implementatie de doelarchitectuur nog niet bereikt kan worden. Bijvoorbeeld gebrek aan ondersteuning van (bepaalde delen van) standaarden of performancebeperkingen in huidige tools. Dat doet voor het OAuth NL profiel niet ter zake.