Opaka token vs JWT

I Logto, som en OIDC-baserad omfattande CIAM-plattform, spelar auktorisationstoken en avgörande roll för att säkra användarinteraktioner och hantera åtkomst till resurser. Bland de olika typerna av token som används för auktorisation är opaka token och JWT:er (JSON Web Tokens) de viktigaste.

Vi har fått flera frågor från vår community, såsom: Vad är skillnaden mellan en opak token och en JWT? Varför kan jag inte avkoda access-token jag fick, och varför verkar token-längden kort? Detta blogginlägg syftar till att klargöra dessa koncept och hjälpa dig förstå skillnaderna mellan opaka token och JWT:er, deras användningsområden och varför du kan uppleva olika beteenden när du arbetar med dem.

Vad är en opak token?#

En opak token är en typ av access-token som, som namnet antyder, är opak eller icke-transparent för klienten eller någon extern part. Detta innebär att token i sig inte bär någon läsbar information om användaren eller den beviljade auktorisationen.

När du får en opak token, framstår den ofta som en till synes slumpmässig sträng av tecken, och att försöka avkoda den ger ingen meningsfull data.

Här är ett exempel på en opak token:

Eftersom det faktiska innehållet av token endast är känt för den auktoriseringsserver som utfärdade den, måste klienten skicka tillbaka den till servern för att validera en opak token, som sedan verifierar dess äkthet och bestämmer de tillhörande rättigheterna. Denna metod säkerställer att känslig information förblir dold, vilket ger ett extra säkerhetslager, men det kräver också ytterligare serverkommunikation för att validera token.

Fördelar:

• säker: Opaka token exponerar ingen känslig information för klienten. Tokeninnehållet är endast känt av auktorisationsservern.
• återkallbar: Eftersom token är lagrad på servern, och det enda sättet att validera den är genom introspektion-endpointen på auktorisationsservern, kan servern enkelt återkalla token om det behövs och förhindra obehörig åtkomst.
• liten storlek: Opaka token är vanligtvis kortare än JWT:er, vilket kan vara fördelaktigt för prestanda och lagringsöverväganden.

Nackdelar:

• stateful: Opaka token kräver att auktorisationsservern håller tillstånd för att validera token, vilket kan introducera ytterligare komplexitet och överhuvud.
• prestanda: Behovet av ytterligare serverkommunikation för att validera token kan påverka prestandan, särskilt i högtrafikscenarier.

Vad är en JWT?#

Till skillnad från opaka token är en JWT (JSON Web Token) en självständig, statslös token som bär information i ett strukturerat och läsbart format.

En JWT består av tre delar: en header, en payload och en signature, var och en kodad i Base64URL.

Här är ett exempel på en JWT:

• header innehåller information om typen av token och algoritmen som används för att signera. Till exempel, {"alg": "HS256", "typ": "JWT"}.
• payload-sektionen innehåller claims—bitar av information om användaren eller auktorisationen—såsom användar-ID, utgångstid och omfattningar. Eftersom denna data är kodad men inte krypterad, kan vem som helst som har token dekoda det för att se claims, även om de inte kan ändra det utan att göra signaturen ogiltig. Baserat på specifikationen och auktorisationsserverns konfiguration kan olika claims inkluderas i payload. Detta ger token sin självständiga natur. Till exempel, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• signature genereras genom att kombinera header, payload och en hemlig nyckel med den specificerade algoritmen. Denna signatur används för att verifiera tokenens integritet och säkerställa att den inte har manipulerats.

JWT:er används vanligtvis eftersom de kan verifieras lokalt av klienten eller någon tjänst utan att behöva interagera med auktorisationsservern. Detta gör JWT:er särskilt effektiva för distribuerade system, där flera tjänster kan behöva verifiera tokenens autenticitet oberoende.

Men denna bekvämlighet medför också ansvaret att säkerställa att tokenens claims inte är överdrivet exponerade, eftersom de är synliga för alla som har åtkomst till token. Dessutom är JWT:er vanligtvis kortlivade, och utgångstiden ingår i tokenens claims för att säkerställa att token inte är giltig på obestämd tid.

Fördelar:

• statslös: JWT:er är självständiga och kräver ingen serversidig status för att validera.
• kompatibilitet mellan tjänster: JWT:er kan enkelt delas och verifieras över olika tjänster, vilket gör dem idealiska för distribuerade system.
• utbyggbar: Payload för en JWT kan innehålla anpassade claims, vilket möjliggör flexibel auktorisation och informationsdelning.
• standard: JWT-token följer en väldefinierad standard (RFC 7519), vilket gör dem allmänt stödda och interoperabla.

Nackdelar:

• exponering: Claims i en JWT är synliga för alla som har åtkomst till token, så känslig information bör inte inkluderas i payload.
• stor storlek: JWT:er kan vara större än opaka token på grund av den ytterligare information de bär, vilket kan påverka prestanda och lagringsöverväganden. Claims i en JWT-token bör hållas till ett minimum för att minska tokenens storlek.
• återkallningskomplexitet: Eftersom JWT:er är statslösa är de vanligtvis giltiga under en kort tidsperiod, och det finns ingen inbyggd mekanism för att återkalla token innan de löper ut, vilket betyder att en komprometterad token kan förbli giltig tills den löper ut.

Validering av opak access-token#

En opak access-token valideras genom att skicka tillbaka den till auktorisationsservern för verifiering. Auktorisationsservern upprätthåller tillståndet för utfärdade token och kan bestämma tokenens giltighet baserat på sin interna lagring.

1. Klienten begär en access-token från auktorisationsservern.
2. Auktorisationsservern utfärdar en opak token.
3. Klienten skickar resursåtkomstbegäran med den opaka token i headern.
4. Resursleverantören skickar en tokenintrospektionsbegäran till auktorisationsservern för att validera token.
5. Auktorisationsservern svarar med tokeninformationen.

Validering av JWT access-token (offline)#

En JWT access-token kan valideras offline av klienten eller någon tjänst som har åtkomst till tokenens offentliga nyckel.

0. Resursleverantören förhämtar auktorisationsserverns offentliga nyckel från OIDC-upptäcktsendpoints. Den offentliga nyckeln används för att verifiera tokenens signatur och säkerställa dess integritet.
1. Klienten begär en access-token från auktorisationsservern.
2. Auktorisationsservern utfärdar en JWT-token.
3. Klienten skickar resursåtkomstbegäran med JWT-token i headern.
4. Resursleverantören dekodar och validerar JWT-token med den offentliga nyckel som erhålls från auktorisationsservern.
5. Resursleverantören beviljar åtkomst baserat på tokenens giltighet.

Användningsfall i OIDC#

I kontexten av OIDC (OpenID Connect), tjänar opaka token och JWT:er olika syften och används i olika scenarier.

Opaka token#

1. Användarprofilhämtning:

Som standard, när en klient begär en access-token utan att specificera en resurs och inkluderar openid-omfånget, utfärdar auktorisationsservern en opak access-token. Denna token används främst för att hämta användarprofilinformation från OIDC /oidc/userinfo-endpoints. När en begäran med den opaka access-token tas emot, kontrollerar auktorisationsservern sin interna lagring för att hämta den tillhörande auktorisationsinformationen och verifierar tokenens giltighet innan den svarar med användarprofilens information.

2. Uppdatering av tokenbyte:

Uppdateringstoken är utformade för att endast bytas mellan klienten och auktorisationsservern, utan att behöva delas med resursleverantörer. Som sådana utfärdas uppdateringstoken vanligtvis som opaka token. När den nuvarande access-tokenen löper ut, kan klienten använda den opaka uppdateringstoken för att få en ny access-token, vilket säkerställer kontinuerlig åtkomst utan att behöva återautentisera användaren.

JWT:er#

1. ID-token:

I OIDC är ID-token en JWT som innehåller användarinformation och används för att autentisera användaren. Typiskt utfärdad tillsammans med access-token, tillåter ID-token klienten att verifiera användarens identitet. Till exempel:

Klienten kan validera ID-token för att säkerställa användarens identitet och extrahera användarinformation för personalisering eller auktorisationsändamål. ID-token är för engångsbruk och bör inte användas för API-resursauktorisation.

2. API-resursåtkomst:

När en klient begär en access-token med en specifik resursindikator, utfärdar auktorisationsservern en JWT access-token avsedd för att åtkomst till den resursen. JWT:en innehåller claims som resursleverantören kan använda för att auktorisera klientens åtkomst. Till exempel:

Resursleverantören kan validera begäran genom att kontrollera claims:

• iss: Bekräftar att token utfärdades av en betrodd auktorisationsserver.
• sub: Identifierar användaren associerad med token.
• aud: Säkerställer att token är avsedd för den specifika resursen.
• scope: Verifierar de rättigheter som beviljats användaren.

Slutsats#

Sammanfattningsvis tjänar opaka token och JWT:er olika syften i OIDC-baserade system, med opaka token som ger en säker och stateful ansats för auktorisation och JWT:er som erbjuder en självständig och statslös alternativ. Att förstå skillnaderna mellan dessa toke typer och deras användningsområden är avgörande för att designa säkra och effektiva autentiserings- och auktorisationsmekanismer i dina applikationer.

Upptäck fler funktioner för access-token i Logto:

• Använd RBAC för att skydda ditt API
• Organisationsaccess-token
• Anpassade JWT-claims