Varför JWT i de flesta OAuth 2.0-tjänster

OAuth 2.0 används i stor utsträckning idag. Som ett kärnramverk för auktoriseringstjänster är en av OAuth 2.0:s huvuduppgifter att utfärda åtkomsttokens för användare. Vi har lagt märke till att många OAuth-tjänsteleverantörer på marknaden utfärdar åtkomsttokens i JWT-format.

I denna artikel kommer vi att introducera vad JWT är och varför det är utbrett som format för åtkomsttokens som utfärdas av OAuth 2.0.

Introduktion till JWT#

JWT står för JSON Web Token, och det definieras av RFC 7519 på följande sätt:

JSON Web Token (JWT) är ett kompakt, URL-säkert sätt att representera anspråk som ska överföras mellan två parter.

Denna definition gör det klart att JWT är en token som används för att överföra anspråk mellan olika parter.

Eftersom JWT:er överförs bland flera parter, är de signerade för att säkerställa dataens integritet och äkthet.

En signerad JWT har följande format:

Den består av tre delar separerade med .: header, payload och signature.

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

Du kan försöka avkoda den på https://jwt.io:

Som visas i bilden innehåller header-sektionen av JWT information om den använda signeringsalgoritmen och tokenens typ. Payload-sektionen innehåller de anspråk som JWT bär, och signature används för att verifiera JWT:ens integritet.

Nu när vi förstår vad JWT är och betydelsen av dess olika delar, låt oss gå vidare till att förklara varför många OAuth-auktoriseringstjänster väljer JWT som sin åtkomsttoken.

Fördelar med att använda JWT#

De främsta skillnaderna mellan JWT och traditionella slumpmässigt genererade string-baserade tokens är att JWT:er kan bära information och kan valideras genom avkodning. Dessa skillnader ger två betydande fördelar:

• Resurseffektivitet: JWT:er kan bära information om användaren eller sessionen, vilket eliminerar behovet av frekventa databasuppslag. Denna effektivitet kan minska resurskonsumtionen av tjänster.
• Förbättrad tillgänglighet och skalbarhet: JWT:er minskar beroendet av server-side state management. Detta tillåter tjänster att vara mer statslösa, vilket förbättrar deras tillgänglighet och skalbarhet.

När du använder traditionella random string-baserade tokens är den typiska processen för verifiering och autentisering följande:

Som visas i diagrammet, när ett system har många användare och många olika Resursservrar, kan det resultera i många tokenvalideringsförfrågningar till Autentiseringstjänsten.

Över tid, när systemet växer, kan Autentiseringstjänsten lätt bli en flaskhals, vilket utgör en utmaning för den övergripande tjänstens tillgänglighet.

Men när JWT:er introduceras, ändras valideringsprocessen till:

Tack vare funktionen hos JWT:er, som tillåter validering genom avkodning, kan Resursservern verifiera JWT:ens integritet och extrahera användarinformation från dem utan behov av att interagera med Autentiseringstjänsten (För detaljer om avkodning och validering av JWT:er, kan du hänvisa till Logto-dokumentationen).

Begränsningar av JWT#

Även om JWT:er erbjuder betydande fördelar i moderna mjukvaruarkitekturer, har de också begränsningar att överväga.

Lätt avlyssnad payload#

Som tidigare nämnts består en JWT av tre delar: header, payload och signature. Hur genereras dessa komponenter? Låt oss ta JWT:n från föregående exempel och demonstrera JWT-genereringsprocessen:

Som visas i koden ovan, är JWT:ens header och payload helt enkelt kodade som base64-strängar.

Detta innebär att så länge någon har tillgång till tokenen, kan de enkelt avkoda base64-strängen av JWT-payloaden och få tillgång till den information den bär. Omvänt är det också relativt lätt att förfalska en payload och ersätta den ursprungliga JWT:ens payload med en manipulerad.

Även om det är sant att en JWT:s payload kan vara relativt lätt att förfalska, är det viktigt att notera att signaturdelen av JWT inte kan ersättas med förfalskat innehåll, eftersom det kräver den hemliga signeringsnyckeln. Därför, utan rätt signatur, kan JWT:n inte passera validering.

Så, när du använder JWT:er, är det viktigt att hålla följande överväganden i åtanke:

1. Använd alltid SSL: För att säkerställa att JWT-information inte avslöjas under överföring, är det viktigt att använda SSL (Secure Sockets Layer) eller dess efterträdare, TLS (Transport Layer Security), för att kryptera data under transport.
2. Undvik lagring av känslig data: Det rekommenderas inte att lagra känslig data i JWT-payload. Payload kan enkelt avkodas, som nämnts tidigare, och bör främst innehålla icke-känsliga, relevanta anspråk.
3. Validera JWT:er: Innan du förlitar dig på informationen inom en JWT, se till att den har passerat en giltig och säker valideringsprocess, inklusive verifiering av signaturen och kontroll av tokenens utgångsdatum. Detta hjälper till att förhindra användning av manipulerade eller obehöriga tokens.

Svår att återkalla#

I allmänhet har åtkomsttokens vanligtvis en utgångstid. Om åtkomsttoken är representerad som slumpmässiga strängar utan någon information, kan vi kontrollera om tokenen har återkallats under varje validering i Autentiseringstjänsten.

Som för JWT:er, på grund av att JWT:er innehåller utgångsinformation inom sig själva, och det faktum att JWT-validering inte beror på Autentiseringstjänsten, när en Autentiseringstjänst utfärdar en åtkomsttoken i JWT-format, blir det omöjligt att ändra tokenens tillstånd under dess användning.

Efter att en JWT token naturligt utgår, kan vi få en ny JWT från auktoriseringsservern med en förnyelsetoken (du kan hänvisa till Logtos blogg för information om förnyelsetokens).

Dock, i vissa situationer, som när en användare återkallar auktorisering eller byter lösenord, och du behöver återkalla en redan utfärdad men ännu inte utgången token, finns det ingen enkel lösning tillgänglig.

Det finns två vanliga metoder för att mildra påverkan av tokenåterkallning mitt i processen:

1. Sätt en kortare utgångstid för åtkomsttokenen och förlita dig på tokenförnyelsemekanismen för att snabbt uppdatera tokenens status.

Eftersom åtkomsttokenen har en kortare utgångstid, när en användare upptäcker att åtkomsttokenen har upphört, kan de begära en ny åtkomsttoken med en förnyelsetoken från auktoriseringstjänsten. På så sätt kan tokenens status på användarens sida synkronisera med backend så snart som möjligt. Dock kommer denna metod med ytterligare överhead, vilket användarna behöver överväga.

2. Upprätthåll en återkallelselista för åtkomsttokens och kontrollera huruvida tokenen är med på listan under varje validering.

Denna metod har vissa begränsningar. En av fördelarna med JWT är att den inte kräver att servern lagrar state information, och JWT:er är vanligtvis statslösa. Men att upprätthålla en återkallelselista kräver effektiv lagring och underhåll, beroende på ytterligare lagringsmekanismer. Detta offrar i princip fördelarna med JWT och kan potentiellt leda till prestandaproblem. Därför behöver tokenåterkallningsmekanismen implementeras av utvecklarna på ett sätt som är lämpligt för deras specifika användningsfall.

Sammanfattning#

I denna artikel gav vi en kort introduktion till JWT, och lyfte fram dess fördelar och begränsningar. Vid det här laget bör du ha en djupare förståelse för JWT och de scenarier där det vanligtvis används. Även om JWT har sina utmaningar, överväger fördelarna den medför när det används som tokenformat i OAuth 2.0-tjänster långt dess nackdelar.

Logto, som en snabbt växande identitetsautentiseringstjänst, använder också JWT som format för sina åtkomsttokens. Den följer strikt olika auktoriserings- och autentiseringsprotokoll, vilket gör det exceptionellt enkelt att integrera identitetsautentiseringstjänster i dina produkter. Logto har officiellt lanserat sin SaaS-tjänst, och du kan prova den gratis idag.