OAuth 2.0-tokenintrospektion

OAuth 2.0-tokenintrospektion definierar en metod som tillåter en auktoriserad skyddad resurs att fråga auktorisationsservern för att bestämma metadata som är associerade med en given token (antingen en åtkomsttoken eller en uppdateringstoken), tillhandahållen av en OAuth-klient. Baserat på metadata för den specifika token tillåter det resursägaren att komma åt den skyddade resursen.

Denna metadata inkluderar:

• Huruvida tokenet för närvarande är aktivt (eller om det har gått ut eller återkallats)
• De behörigheter åtkomsttoken ger (vilket vanligtvis uttrycks genom OAuth 2.0-scope)
• Auktorisationskontexten i vilken token beviljades (inklusive vem som auktoriserade tokenet och till vilken klient det utfärdades)

Tokenintrospektion möjliggör för den skyddade resursen att fråga denna information, oavsett om den är inbäddad i tokenet självt.

Det finns två typer av åtkomsttoken, beroende på hur de är kodade:

• Identifierarbaserad: Token representerar en slumpmässig, svårgissad identifierare associerad med auktorisationen i auktorisationsserverns databas.
• Självständig: Auktorisationen är kodad inom tokenet självt och skyddas genom kryptografi för att förhindra manipulering. JSON Web Token (JWT) är den vanliga standarden för denna metod.

För självständiga token kan den auktorisationsrelaterade metadata direkt analyseras från åtkomsttoken. Dock, för identifierarbaserade token, måste auktorisationsserverns tokenintrospektionsfunktion användas för att validera/hämta metadata.

Tokenintrospektionsbegäran#

Användning av identifierarbaserade åtkomsttoken kräver verifiering med auktorisationsservern via en nätverksbegäran. Det finns ett standardprotokoll för detta som kallas OAuth 2.0 Token Introspection (RFC 7662).

Den skyddade resursen kommer att POST:a tokenet till auktorisationsserverns introspektionsendpoint och i gengäld kommer den att erhålla ett JSON-objekt som innehåller tokenets parametrar.

Observera att introspektionsbegäranden inte kan initieras godtyckligt; de måste uppfylla minst ett av följande villkor:

• Autentisering med hjälp av referenser (som måste vara förregistrerade hos auktorisationsservern), eller
• Auktorisation genom att använda en åtkomsttoken.

Som ett resultat, i denna specifika interaktion, blir den skyddade resursen OAuth-klienten, och auktorisationsservern blir den skyddade resursen.

Nedan är ett exempel på en introspektionsbegäran, där den skyddade resursen autentiserar med hjälp av en klient-ID och klienthemlighet, som erhölls efter att ha registrerat sig som en OAuth-klient hos auktorisationsservern.

Nedan är ett exempel på en introspektionsbegäran som direkt använder en åtkomsttoken. Åtkomsttoken kan erhållas direkt från /token-endpointen genom att använda referenserna för en registrerad maskin-till-maskin-app och client_credentials-granttypen.

Tokenintrospektionssvar#

Den viktigaste parametern är active, som är ett booleanvärde. Om true, indikerar det att tokenet är giltigt, och JSON-objektet kommer att inkludera andra token-detaljer, såsom scope-värden. Om false, är tokenet antingen ogiltigt eller förfallet, och den skyddade resursen måste returnera ett 401 Unauthorized-svar med invalid_token-felkoden.

Här är ett exempel på ett svar för en giltig token:

Förutom active, som är obligatorisk, är alla andra parametrar valfria.

Den skyddade resursen kan använda dessa ytterligare fält för att bestämma åtkomstbehörigheter, på liknande sätt som hur det skulle analysera och validera en JWT-åtkomsttoken.