Opaka token vs JWT
Förstå skillnaderna mellan opaka token och JWT:er, deras användningsområden och hur de valideras i OIDC-baserade system.
Förstå skillnaderna mellan opaka token och JWT:er, deras användningsområden och hur de valideras i OIDC-baserade system.
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.
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:
Nackdelar:
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:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cheader 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:
Nackdelar:
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.
En JWT access-token kan valideras offline av klienten eller någon tjänst som har åtkomst till tokenens offentliga nyckel.
I kontexten av OIDC (OpenID Connect), tjänar opaka token och JWT:er olika syften och används i olika scenarier.
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.
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.
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.
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.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: