JWT vs Sessionsautentisering

Generellt sett är det första steget i att använda en applikation autentisering, där slutanvändaren tillhandahåller sina identitetsuppgifter för att lyckas logga in. Efter detta steg vet identitetssystemet (dvs. identitetsleverantör, autentiseringsserver, etc.) vem användaren är och vilka resurser de har tillgång till.

Eftersom HTTP är i grunden stillöst är varje förfrågan i en session oberoende och kommer inte ihåg information från tidigare förfrågningar. Att återautentisera användare vid varje åtgärd är besvärligt och skadar användarupplevelsen.

Låt oss presentera Sessionsbaserad autentisering och JWT (JSON Web Tokens) autentisering, två populära metoder för att upprätthålla autentiseringsstatus. Var och en har unika fördelar och kompromisser, och valet mellan dem beror på ditt applikations specifika behov. Om du står inför valet mellan de två är denna guide här för att hjälpa till.

Vad är sessionsbaserad autentisering?#

Sessionsbaserad autentisering förlitar sig på servern för att hålla reda på användarens autentiseringsstatus. Genom att skapa och hantera sessioner möjliggör servern för användare att förbli inloggade och fortsätta interagera med en applikation utan att behöva ange sina uppgifter vid varje begäran.

Hur fungerar sessionsbaserad autentisering?#

Session skapande

1. En användare autentiserar och tillhandahåller vissa uppgifter (t.ex. e-post och lösenord).
2. Om uppgifterna är giltiga skapar servern en bestående post som representerar den sessionen. Sessionen innehåller information som en slumpmässig sträng, användaridentifierare, sessionens starttid, sessionens utgångstid, etc.
3. SessionID lagras i databasen och returneras till användarens klient som en cookie.

Session validering

1. Processen kan aktiveras manuellt av användaren (t.ex. klicka på en flik, uppdatera en sida) eller automatiskt av klienten (t.ex. under initial sidladdning eller via API-anrop med en SessionID).
2. Varje efterföljande samtal skickar en HTTP-förfrågan från klienten som innehåller session-cookien till servern.
3. Servern validerar SessionID genom att konsultera sessionsdata som sparats på servern.
4. Om giltig, bearbetar servern begäran och godkänner användaren.

Hur återkallar man en session?#

Sessioner kan ogiltigförklaras i realtid, vilket är praktiskt i situationer där snabb återkallelse av åtkomst är nödvändig.

• Användare loggar ut manuellt: Servern tar bort sessionsposten, vilket effektivt loggar ut användaren.
• Administratörer framtvingar utloggning: Administratörer eller system kan avsluta specifika sessioner genom att ta bort dem från databasen. Till exempel vid ett säkerhetsintrång.
• Sessions utgång: Sessioner kan automatiskt upphöra efter en angiven varaktighet av inaktivitet eller en fast tidsgräns.

Fördelar med sessionsbaserad autentisering#

• Enkel och pålitlig: Sessionsposten ger en tydlig, centraliserad källa som möjliggör en hög grad av tillförlitlighet och gör beslut om auktorisering mer pålitliga.
• Återkallelse i realtid: Genom att ta bort eller ogiltigförklara sessionens post kan en användares åtkomst snabbt återkallas.

Nackdelar med sessionsbaserad autentisering#

• Fördröjning i distribuerade system: Att underhålla sessionsdata över flera servrar kräver alltid synkronisering av en session lagringsplats. Detta introducerar ytterligare fördröjning eftersom servern måste kontrollera sessionen varje gång en begäran görs.
• Hög resursförbrukning: Varje session tar serverresurser, vilket påverkar prestanda när användarbasen växer.
• Säkerhetsrisk: Sessionskapande (via stulna sessionscookies) kan ge obehörig åtkomst till användarkonton.
• Begränsad användning för APIer: Sessionsbaserad autentisering är inte idealisk för mobilappar. Det lagrar sessionsdata på servern, vilket kan öka lasten och komplexiteten med många användare. Dessutom använder det cookies, som är svårare att hantera på mobila enheter.

Vad är JWT-autentisering?#

JSON Web Tokens (JWTs) tar en annan ansats genom att bädda in all relevant användarinformation direkt i en token med hjälp av ett JSON-objekt. Till skillnad från sessionsbaserade metoder är JWTs stateless, vilket betyder att servern inte hanterar autentiseringsposter.

Hur fungerar JWT-autentisering?#

En JWT består av tre delar: ett header, payload, och *** signatur***.

• Headern innehåller signeringsalgoritmen (t.ex. HS256) och tokenens typ (JWT).
• Payloaden innehåller kärn claims, såsom användarens identitet, användarroll och utgångstid.
• Signaturen använder en nyckel för att signera headern och payloaden, vilket möjliggör verifiering om signaturen har manipulerats med.

JWT-utgivning

1. Klienten skickar inloggningsuppgifter till autentiseringsservern (En universell identitetsleverantör är särskilt fördelaktig för hantering av åtkomst över flera domäner.)
2. Efter lyckad autentisering genererar servern en JWT som inkluderar header, payload och signatur.
3. AuthServer skickar den utfärdade token till Client. Klienten lagrar JWT (t.ex. i cookies, localStorage eller sessionStorage).

Sessionsbaserade arbetsflöden följer en liknande process. Dock, efter autentisering, lagras användarinformation på servern inom en session, medan JWTs förlitar sig på tokens skickade till klienten för lagring och efterföljande användning.

Token validering

1. För efterföljande API-begäranden skickar klienten JWT i Authorization-headern (Bearer <token>).
2. Servern verifierar JWT:s signatur med en hemlig eller offentlig nyckel och kontrollerar dess claims (t.ex. utgångstid, utfärdare).
3. Om token är giltig beviljar servern klienten åtkomst till de begärda resurserna.

Sessionsbaserad autentisering kräver att servern frågar en session lagringsplats, vilket kan vara långsamt, speciellt om det förlitar sig på externa eller centraliserade databaser. I kontrast är JWT-autentisering stateless, med all nödvändig information lagrad i klienttoken, och använder signatur för att säkerställa säkerhet. Detta eliminerar behovet av sessionshantering, vilket gör det snabbare och mer skalbart, speciellt i distribuerade system.

Hur återkalla en JWT?#

På klientsidan innebär utloggning vanligtvis att rensa den lokala sessionen och ta bort tokens (ID, tillgång, uppfräschnings-token) från lagring. Dock, för JWT-autentisering, signer detta bara ut användaren lokalt, vilket innebär att den centraliserade sessionen på auktoriseringsservern förblir intakt. Som ett resultat kan användare fortfarande få åtkomst till andra appar under samma session tills token löper ut eller avslutas manuellt.

Att återkalla en JWT (JSON Web Token) är mer utmanande än sessionsbaserad autentisering eftersom JWTs är stateless och kan inte ogiltigförklaras när de väl har utfärdats, såvida inte specifika strategier implementeras. Vanliga metoder inkluderar:

• Kort giltighetstid: Ställ in ett kort exp claim (t.ex. 15 minuter) för JWT. När den har löpt ut måste användaren återautentisera. Detta minimerar risken om en token komprometteras eftersom angriparen bara kan använda den under en begränsad tid. För att bibehålla en sömlös användarupplevelse kan refresh token användas för att minimera besväret med återautentisering.
• Token svartlista: För kritiska fall (t.ex. användarutloggning, lösenordsändringar) upprätthåll en svartlista av återkallade tokens. Servern kontrollerar inkommande tokens mot denna blocklista och avvisar alla matchningar. Även om det är effektivt kräver detta angreppspårning av återkallade tokens, vilket går emot stateless-naturen hos JWTs och kan bli ineffektivt om listan växer för stor.
• Återkallnings-API: Inför en återkallnings-API på auktoriseringsservern där tokens (t.ex. uppfräschningstokens) kan ogiltigförklaras. När en uppfräschningstoken är ogiltigförklarad kommer inga åtkomsttokens utfärd från den längre att förnyas. Denna metod fungerar bra i OAuth2 flöden.

Fördelar med JWT-autentisering#

• Snabb och mer informativ: Den självförsörjande naturen av JWTs gör klientbaserad verifiering snabbare och mer effektiv, utan behov av serverinteraktion. De kan också inkludera anpassade claims (t.ex. användarroller eller annan relevant data) inom token, som tillåter servrar att avgöra roller utan att fråga en databas.
• Förbättrad säkerhet: JWTs använder signering och krypteringstekniker, vilket gör attacker svårare.
• Korsdomänstöd: JWTs är perfekta för Single Sign-On (SSO) och autentisering över domäner. De tillåter användare att autentisera över flera domäner eller tjänster med samma token.
• Mobilvänlig: JWTs fungerar utmärkt för mobila applikationer som behöver stateless autentisering. Tokens kan lagras på klientsidan och skickas med varje begäran, vilket förbättrar effektiviteten och användarvänligheten.

Nackdelar med JWT-autentisering#

• JWT uppdateras inte i realtid

  När en JWT är signerad kan den inte återkallas eller uppdateras, och den kommer att betraktas som giltig så länge signaturen är giltig och inte har löpt ut.

  Om åtkomsträttigheterna för en användare ändras (vanligtvis försämrade) kommer användaren fortfarande att ha borttagen åtkomst till resurserna tills JWT löper ut. På samma sätt, om en JWT innehåller rollbaserad auktoriseringsinformation, kommer den nya auktoriseringsomfattningen inte att träda i kraft förrän den gamla JWT löper ut. Med andra ord, JWTs är inte lämpliga för återkallning i realtid och användare kan ställa in en lämplig utgångstid för att motverka detta problem.

• Flera enheter och återkallningsdilemma

  Det är inte möjligt att validera alla utfärdade JWTs innan de löper ut för att genomföra återkallelse för alla användarenheter. Även om det teoretiskt är möjligt att återkalla signeringsnyckeln för att göra JWTs ogiltig, skulle detta också ogiltigförklara alla JWTs som använder den nyckeln, och processen för att hantera cache-nycklar skulle göra detta tillvägagångssätt opraktiskt för enkla användaråterkallelseoperationer.

Vissa identitetsleverantörer kan ha färdigbyggda lösningar för dessa JWT-problem. För mer information, kolla "Best Practices to Enhance the JWT Authentication Experience.”

Vad är skillnaden mellan JWT och session?#

Sessioner och JWTs är två populära metoder för att upprätthålla autentiserings- och auktoriseringskontext i en stateless HTTP-värld. Även om båda metoderna har sina för- och nackdelar erbjuder de olika fördelar och nackdelar.

Sessioner erbjuder starkare garantier för individuell begäran om auktorisering och är enklare att implementera på ett säkert sätt. Men deras beroende av serverdatabasens validering inför latensökning, vilket kan negativt påverka användarupplevelsen för mycket responsiva applikationer.

JWTs, å andra sidan, är fördelaktiga för snabbare auktorisering och interoperabilitet med externa appar, men kräver mer utvecklaransträngning för att adressera säkerhetskomplexiteter. Till exempel kan vi använda webhooks för att meddela klienter när användarens åtkomst återkallas, så att klienter kan rensa den cachelagrade JWT och tvinga användaren att återautentisera.

Eftersom tokenbaserad autentisering är mer lämpad för skalning med sina nackdelar fortfarande hanterbara, antas det av fler och fler moderna applikationer.

Session vs. JWT: Välja metoden#

Din autentiseringsmetod bör matcha din apps arkitektur och specifika behov. Här är en snabb guide för att hjälpa dig att fatta beslutet:

När man ska använda sessionsbaserad autentisering#

Sessionsbaserad autentisering fungerar bäst när du behöver realtidskontroll av sessioner, behöver centraliserad hantering eller skalbarhet inte är ett stort bekymmer. Här är där den lyser:

• Webbapplikationer med bestående sessioner

  För plattformar som online-shoppingwebbplatser är sessioner avgörande för att spåra användare, shoppingkorgar och preferenser under deras besök.

• Applikationer som kräver realtidskontroll av sessioner

  Applikationer som bank- eller finanstjänster drar nytta av serverstyrd sessiondata, vilket säkerställer robust åtkomsthantering och säkerhet.

• Enkel-server eller småskaliga system

  Interna verktyg eller småskaliga appar utan tunga skalningskrav frodas på enkel sessionshantering för användarvänlighet och tillförlitlighet.

När man ska använda JWT-autentisering#

JWT-autentisering är bättre anpassad för applikationer som prioriterar skalbarhet, effektivitet och distribuerade system. Det är särskilt användbart för stateless-interaktioner mellan klienter och servrar. Överväg tokenbaserad autentisering för följande:

• Single Sign-On (SSO)

  JWTs är perfekta för Single Sign-On, vilket möjliggör att användare kan autentisera en gång och smidigt få åtkomst till flera tjänster eller applikationer med samma token. Dela en detaljerad förklaring om säker moln-baserade applikationer med OAuth 2.0 och OIDC, med JWT-format för både tillgångstokens och ID-tokens.

• Mobilapplikationer

  Mobilappar föredrar ofta JWTs för autentisering eftersom tokens kan lagras säkert på enheten och skickas med varje API-begäran. Utforska den snabba integreringen av JWT-autentisering för Android / iOS.

• Mikrotjänstarkitekturer

  I mikrotjänstmiljöer tillåter JWTs varje tjänst att självständigt validera tokenen utan att förlita sig på en central sessionslagring, vilket säkerställer skalbarhet och effektivitet.

• Korsdomänsautentisering

  JWTs utmärker sig i scenarier som involverar flera domäner eller subdomäner (t.ex. api.example.com, dashboard.example.com och docs.example.com). Till skillnad från cookies tillåter JWTs autentisering över domäner utan ytterligare beroenden.

• APIer och webbtjänster

  RESTful APIs och webbtjänster använder vanligen JWTs för autentisering eftersom de är lätta, bärbara och eliminerar behovet av serverbaserad sessionshantering. Läs mer om maskin-till-maskin-autentisering för scenarier där din app behöver kommunicera direkt med resurser.

Bästa praxis för att förbättra JWT-autentiseringsupplevelsen#

JWT-autentisering är ett utmärkt verktyg, men det kan medföra utmaningar som påverkar användarupplevelsen. Logto erbjuder en enkel och pålitlig lösning för att övervinna dessa hinder, vilket gör det till ett toppval för säker och effektiv autentisering.

Hantering av användarutloggningsproblem med JWT#

Ett vanligt problem med JWT-autentisering är att säkerställa en korrekt utloggningsupplevelse för användare. Logto förenklar denna process med sitt ut-ur-lådan SDK.

• Genom att rensa tokens och lokala sessioner på klientsidan och omdirigera användare till Logto's slutsession-API, kan du enkelt avsluta sessioner på både klientapplikationen och servern.
• Dessutom stödjer Logto back-channel logout, vilket möjliggör för AuthServer att meddela alla klientapplikationer som delar samma session när en användare loggar ut.

Detta säkerställer konsekvent och säker sessionshantering i hela ditt ekosystem. Lär dig mer om hantering av utloggning.

Hantering av användaråtkomstförändringar#

Att hantera realtidsförändringar i användaråtkomsträttigheter med JWT kan också vara knepigt. Eftersom JWTs är stateless i design kan eventuella uppdaterade åtkomsträttigheter eller roller inte träda i kraft förrän token löper ut. Logto erbjuder strategier för att hantera detta effektivt:

• För minskning av rättigheter för denna användare: Använd korta access token utgångstider eller verifiera dynamiskt rättigheter via ett API-anrop.
• För tillagda nya rättigheter för denna användare: Uppdatera AuthServer för att inkludera den nya åtkomstomfattningen och om-konsent användare för att tillämpa dessa ändringar.

Dessa lösningar hjälper till att hålla rättigheter uppdaterade och säkerställa en säkrare, mer responsiv system. Lär dig mer om hantering av åtkomstförändringar.

Logto, som är en skalbar identitetshanteringsinfrastruktur, ger en komplett identitetslösning med både molntjänst och öppen källkodsversion tillgänglig.