Att ansluta prickarna: En djupgående utforskning av OIDC-resurs och dina JWT-access tokens

Bakgrund#

I en tidigare session gav vi en introduktion till OpenID Connect (OIDC) protokoll, uppdateringstokens, access tokens och ID-tokens, viktiga komponenter för att bygga robust autentisering i din applikation. Men frågor kvarstår i vårt community, med en återkommande fråga: "Varför är min access token inte en JWT?"

För de som är nya i begreppen, eller även de som behöver en repetition, syftar detta blogginlägg till att belysa förhållandet mellan OIDC-resursindikatorer och deras roll i att erhålla access tokens.

Förstå OIDC-resurs#

Om du är bekant med OAuth 2.0-protokoll, borde termen "resurs" låta bekant. Eftersom OIDC är byggt på OAuth 2.0, ärver den detta koncept.

En "resurs" eller "skyddad resurs" är en representation av en enhet som klientapplikationen vill komma åt på uppdrag av den autentiserade användaren. Detta kan vara användarinformation, server-API:er eller någon annan data som auktoriserats av din server.

Enligt protokollet är resursen en parameter i förfrågningar till auktoriseringsservern. Det är ett värde som representeras som en absolut URI, som https://my-company.com/api. Det fungerar som en identifierare för resursen, potentiellt motsvarande en nätverksadressbar plats eller till och med en unik men fiktiv URI.

I Logto kan du skapa en "API-resurs" via sidan "Admin Console → API-resurser". Du kan hänvisa till denna dokumentation för mer detaljer.

JWT-access token#

JWT (JSON web token) format access token utfärdas endast när "resurs"-parametern specificeras under förfrågan om access token, och den innehåller en uppsättning claims, som du kan dekryptera och validera, till exempel, för att säkerställa tokenens integritet och användarens behörigheter.

Denna "resurs" blir sedan en av aud token claim i JWT, vilket indikerar den avsedda publiken för tokenen. Se RFC-7519.

Så, relationen blir tydlig:

• Specificera resursindikatorn när du begär en JWT-token.
• Resursindikatorn stämmer överens med aud token claim.
• När du gör API-förfrågningar måste JWT-access token inkluderas som bärartoken i headern. Din API-server bör dekryptera och validera aud-claim och andra behörighetsrelaterade claims för att säkra API-förfrågan.
• Varje access token motsvarar en enda resurs. Om du har flera API-resurser registrerade med olika URI:er, begär separata access tokens för var och en.

🤔 Men vad händer om klienten inte specificerar resursen när den begär access token?

Opaque access token#

I Logtos fall, om resursindikatorn inte specificeras när access token begärs, antar auktoriseringsservern att den är för OIDC /userinfo-endpointen, och således utfärdas en opaque access token som senare kan användas av klienten för att begära användarprofil som användar-ID, namn, e-post, etc., från OIDC userinfo endpoint.

I vilken Logto SDK som helst kan du erhålla en sådan token om du anropar getAccessToken() eller direkt begär OIDC-token endpoint utan att specificera resurs-parametern.

Observera att denna opaque access token inte är lämplig för dina egna API-resursförfrågningar, eftersom det inte finns något sätt att verifiera den utan att begära OIDC-servern.

Sammanfattningsvis#

OIDC-resurser definierar specifika data eller tjänster en klientapplikation vill komma åt på användarens vägnar, med JWT-access tokens som tjänar som det säkra sättet för denna åtkomst. "aud"-claim i JWT-access tokens stämmer överens med resursindikatorn, vilket hjälper servrar vid verifieringen av behörigheter vid klientförfrågningar.

I Logto är den opaque access token enbart för att hämta användarprofilinformation från OIDC userinfo endpoint, medan klienter kan begära flera access tokens, var och en dedikerad till en specifik resurs.

Vi hoppas att detta blogginlägg klargör eventuella tvivel och ansluter punkterna för dig. Tveka inte att dela dina tankar.