OAuth 2.0-tokenintrospektion
Den här artikeln utforskar OAuth 2.0-tokenintrospektion, en metod som tillåter en skyddad resurs att fråga auktorisationsservern om tokenmetadata för att avgöra om en åtkomst- eller uppdateringstoken är giltig.
Den här artikeln utforskar OAuth 2.0-tokenintrospektion, en metod som tillåter en skyddad resurs att fråga auktorisationsservern om tokenmetadata för att avgöra om en åtkomst- eller uppdateringstoken är giltig.
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:
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:
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.
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:
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.
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.