Svenska
  • jwt
  • autentisering
  • session
  • token
  • återkalla jwt

JWT vs Sessionsautentisering

Lär dig skillnaderna mellan sessionsbaserad och JWT-autentisering. Utforska kompromisser, fördelar och användningsområden för att välja det rätta autentiseringsschemat för dina appar.

Ran
Ran
Product & Design
Darcy Ye
Darcy Ye
Developer

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 i grunden är statslöst, är varje begäran i en session oberoende och minns inte information från tidigare. Att återautenticera användare för varje åtgärd är besvärligt och skadar användarupplevelsen.

Låt oss gå in på Sessionsbaserad autentisering och JWT (JSON Web Tokens) autentisering, två populära metoder för att upprätthålla autentiseringsstatus. Varje har unika fördelar och kompromisser, och valet mellan dem beror på din applikations specifika behov. Om du funderar på vilket av de två som passar bäst, är den här guiden här för att hjälpa till.

Vad är sessionsbaserad autentisering?

Sessionsbaserad autentisering bygger på att servern upprätthåller en register över användarens autentiseringsstatus. Genom att skapa och hantera sessioner möjliggör servern att användare förblir inloggade och fortsätter interagera med en applikation utan att behöva ange autentiseringsuppgifter vid varje begäran.

Hur fungerar sessionsbaserad autentisering?

Sessionsskapande

  1. En användare autentiserar och tillhandahåller några autentiseringsuppgifter (t.ex. e-post och lösenord).
  2. Om autentiseringsuppgifterna är giltiga skapar servern en beständig post som representerar den sessionen. Sessionen innehåller information såsom en slumpmässig sträng, användaridentifierare, sessionsstarttid, sessionstidsgräns, etc.
  3. SessionID lagras i databasen och returneras till användarens klient som en kaka.

Sessionsvalidering

  1. Processen kan utlösas manuellt av användaren (t.ex. genom att klicka på en flik, uppdatera en sida) eller automatiskt av klienten (t.ex. under initiala sidladdningar eller via API-anrop med SessionID).
  2. Varje efterföljande anrop skickar en HTTP-begäran från klienten som innehåller sessionskakan till servern.
  3. Servern validerar SessionID genom att konsultera sessionsdata som lagrats på servern.
  4. Om giltigt behandlar servern begäran och auktoriserar användaren.

Hur återkallar man en session?

Sessioner kan omedelbart ogiltigförklaras, vilket är praktiskt i situationer där snabb åtkomståterkallande är nödvändigt.

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

Fördelar med sessionsbaserad autentisering

  • Enkelt och tillförlitligt: Sessionsposten ger en tydlig, centraliserad källa, som möjliggör hög grad av tillit och gör auktoriseringsbeslut mer tillförlitliga.
  • Omedelbar återkallning: Genom att ta bort eller ogiltiggöra sessionsposten kan en användares åtkomst snabbt återkallas.

Nackdelar med sessionsbaserad autentisering

  • Fördröjning i distribuerade system: Upprätthålla sessionsdata över flera servrar kräver alltid synkronisering av en sessionslagring. Detta introducerar ytterligare fördröjning eftersom servern måste kontrollera sessionslagringen varje gång en begäran görs.
  • Hög resursförbrukning: Varje session tar serverresurser, vilket påverkar prestandan när användarbasen skalar upp.
  • Säkerhetsrisk: Sessionskapning (via stulna sessionskakor) kan ge obehörig åtkomst till användarkonton.
  • Begränsad användning för API:er: Sessionsbaserad autentisering är inte ideal för mobilappar. Den lagrar sessionsdata på servern, vilket kan öka belastningen och komplexiteten med många användare. Dessutom använder den kakor, vilka är svårare att hantera på mobila enheter.

Vad är JWT-autentisering?

JSON Web Tokens (JWTs) tar en annan angreppssätt 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 statslös, vilket betyder att servern inte hanterar autentiseringsposter.

Hur fungerar JWT-autentisering?

En JWT består av tre delar: en header, användardata (payload), och signatur.

  • Headern innehåller signeringsalgoritmen (t.ex., HS256) och tokenens typ (JWT).
  • Användardatan (payload) innehåller kärn påståenden (claims), såsom användarens identitet, användarroll och utgångstid.
  • Signaturen använder en nyckel för att signera header och användardata, vilket möjliggör verifiering av om signaturen har manipulerats.

image.png

JWT utfärdande

  1. Klienten skickar användaruppgifter till autentiseringsservern (En universell identitetsleverantör är särskilt gynnsam för att hantera åtkomst över flera domäner.)
  2. Vid lyckad autentisering genererar servern en JWT som inkluderar header, användardata och signatur.
  3. Autentiseringsservern skickar den utfärdade token till Klienten. Klienten lagrar JWT (t.ex., i kakor, localStorage eller sessionStorage).

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

Tokenvalidering

  1. För efterföljande API-anrop skickar klienten JWT i Authorization-huvudet (Bearer <token>).
  2. Servern verifierar JWT:s signatur med hjälp av en hemlighet eller offentlig nyckel och kontrollerar dess påståenden (t.ex., utgång, utfärdare).
  3. Om token är giltig beviljar servern klienten tillgång till de begärda resurserna.

Sessionsbaserad autentisering kräver att servern förfrågar en sessionslagring, vilket kan vara långsamt, särskilt om det förlitar sig på externa eller centraliserade databaser. Däremot är JWT-autentisering statslöst, med all nödvändig information lagrad i klienttoken och utnyttjar signatur för att säkerställa säkerhet. Detta eliminerar behovet av sessionshantering, vilket gör det snabbare och mer skalbart, särskilt i distribuerade system.

Hur återkallar man en JWT?

På klientsidan innebär utloggning vanligtvis att man rensar den lokala sessionen och tar bort tokens (ID, åtkomst, uppdateringstoken) från lagring. Men för JWT-autentisering signerar detta bara ut användaren lokalt, lämnar den centraliserade sessionen på autorisationsservern intakt. Som ett resultat kan användare fortfarande nå andra appar under samma session tills tokenen går ut eller avslutas manuellt.

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

  • Kort utgångstid: Sätt en kort exp-påstående (t.ex. 15 minuter) för JWT. När den gått ut måste användaren återautenticera. Detta minimerar risken om en token komprometteras, eftersom angriparen endast kan använda den under en begränsad tid. För att behålla en sömlös användarupplevelse kan updateringstoken användas för att minska besväret med återautenticering.
  • Token-svartlistning: För kritiska fall (t.ex. användarutloggning, lösenordsändringar) upprätthåll en svartlista över återkallade tokens. Servern kontrollerar inkommande tokens mot denna blocklista och avvisar alla träffar. Även om effektivt, kräver detta angreppsätt att man spårar återkallade tokens, vilket går emot JWT:s statslösa natur och kan bli ineffektivt om listan växer för mycket.
  • Återkallningsändpunkt: Introducera en återkallningsändpunkt på auktorisationsservern där tokens (t.ex. uppdateringstokens) kan ogiltigförklaras. När en uppdateringstoken återkallas, kommer alla åtkomsttokens som utfärdats från den inte längre att förnyas. Denna metod fungerar bra i OAuth2 flöden.

Fördelar med JWT-autentisering

  • Snabbt och mer informativt: Den självständiga naturen hos JWT gör klientens verifiering snabbare och mer effektiv, utan behov av serverinteraktion. De kan också inkludera anpassade påståenden (t.ex. användarroller eller andra relevanta data) inom tokenen, vilket möjliggör för servrar att bestämma roller utan att göra en förfrågan till en databas.
  • Förbättrad säkerhet: JWT använder signerings- och krypteringstekniker, vilket gör attacker svårare.
  • Stöd för flera domäner: JWT är perfekta för Single Sign-On (SSO) och tvärdomänautentisering. De tillåter användare att autentisera över flera domäner eller tjänster med samma token.
  • Mobilvänlig: JWT fungerar utmärkt för mobilapplikationer som behöver statslös autentisering. Tokens kan lagras på klientsidan och skickas med varje begäran, vilket förbättrar effektiviteten och användbarheten.

Nackdelar med JWT-autentisering

  • JWT uppdateras inte i realtidståg

    När en JWT har signerats kan den inte återkallas eller uppdateras, och den anses vara giltig så länge signaturen är giltig och den inte har löpt ut.

    Om åtkomsttillstånden för en användare ändras (vanligtvis blir begränsad), kommer användaren fortfarande att ha borttagen åtkomst till resurserna tills JWT går ut. På samma sätt, om en JWT innehåller rollbaserad auktoriseringsinformation, kommer det nya auktoriseringsområdet inte att träda i kraft förrän den gamla JWT går ut. Med andra ord är JWT:s inte lämpliga för återkallning i realtid och användare kan ställa in en lämplig utgångstid för att mildra detta problem.

  • Flera enheter och återkallningsdilemma

    Det är inte möjligt att validera alla utgivna JWT:s innan de går ut för att genomföra användaråterkallning av alla enheter. Även om det är teoretiskt möjligt att återkalla signeringsnyckeln för att göra JWT ogiltiga, skulle detta också ogiltigförklara alla JWT:s som använder den nyckeln, och processen för att hantera cache nycklar skulle göra denna metod opraktisk för enkla användaråterkallningsoperationer.

Vissa identitetsleverantörer kan ha förbyggda lösningar för dessa JWT-problem. För mer information, kolla på "Bästa praxis för att förbättra JWT-autentiseringens upplevelse.

Vad är skillnaden mellan JWT och Session?

Sessioner och JWT:s är två populära angreppssätt för att bevara autentiserings- och auktoriseringssamband i en statslös HTTP-värld. Medan båda angrepsssätten har sina för- och nackdelar, erbjuder de olika fördelar och nackdelar.

Sessioner ger starkare garantier för individuell begärans auktorisering och är enklare att implementera säkert. Men deras beroende av serversidans databasvalidering introducerar fördröjning, vilket kan påverka användarupplevelsen negativt för mycket responsiva applikationer.

JWT:s är å andra sidan fördelaktiga för snabbare auktorisering och interoperabilitet med externa appar, men kräver mer utvecklaransträngning för att hantera säkerhetskomplexiteten. Till exempel kan vi använda webbhooks för att informera klienter när användarens åtkomst återkallas, så att klienter kan rensa den cachade JWT och tvinga användaren att återautenticera.

Eftersom token-baserad autentisering är mer lämplig för att skala upp med sina hanterbara nackdelar adopteras den av fler och fler moderna applikationer.

Session vs. JWT: Att välja rätt metod

Ditt autentiseringsmetod bör matcha din apps arkitektur och specifika behov. Här är en snabbguide för att hjälpa dig bestämma:

När ska man använda sessionsbaserad autentisering

Sessionsbaserad autentisering fungerar bäst när du behöver realtidskontroll för sessioner, behöver centraliserad hantering, eller skalbarhet inte är en stor oro. Här är var det är fördelaktigt:

  • Webbapplikationer med ihållande sessioner

    För plattformar som nätbutiker är sessioner viktiga för att spåra användare, kundvagnar och preferenser under deras besök.

  • Applikationer som kräver realtidskontroll för sessioner

    Applikationer som bank- eller finansiella tjänster drar nytta av serverkontrollerad sessionsdata, vilket säkerställer god åtkomsthantering och säkerhet.

  • Enkel-server eller småskaliga system

    Interna verktyg eller småskaliga appar utan tunga skalbarhetsbehov gynnas av enkel sessionshantering för användarvänlighet och tillförlitlighet.

När ska man använda JWT-autentisering

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

  • Single Sign-On (SSO)

    JWT:s är perfekta för Single Sign-On, vilket gör att användare kan autentisera en gång och sömlöst komma åt flera tjänster eller applikationer med samma token. Dela en detaljerad förklaring om säkra molnbaserade applikationer som använder OAuth 2.0 och OIDC, med JWT-format för både åtkomsttokens och ID-tokens.

  • Mobila applikationer

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

  • Mikrotjänster-arkitekturer

    I mikrotjänstmiljöer gör JWT att varje tjänst oberoende kan validera tokenen utan att förlita sig på en central sessionlagring, vilket säkerställer skalbarhet och effektivitet.

  • Tvärdomänautentisering

    JWT glänser 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 kakor tillåter JWT autentisering mellan domäner utan ytterligare beroenden.

  • API:er och webbservrar

    RESTful API:er och webbservrar använder ofta JWT för autentisering eftersom de är lätta, portabla, och eliminerar behovet av serverside sessionhantering. Lär dig 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-autentiseringens upplevelse

JWT-autentisering är ett fantastiskt verktyg, men det kan komma med 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 förstaval för säker och effektiv autentisering.

Hantera användarutloggningsproblem med JWT

Ett vanligt problem med JWT-autentisering är att säkerställa en korrekt användarutloggningsupplevelse. Logto förenklar denna process med sitt färdiga SDK.

  • Genom att rensa tokens och lokala sessioner på klientsidan och omdirigera användare till Logtos end session endpoint, kan du enkelt avsluta sessioner både på klientapplikationen och servern.
  • Dessutom stöder Logto back-channel logout, vilket möjliggör för Autentiseringsservern att informera alla klientapplikationer som delar samma session när en användare loggar ut.

Detta säkerställer konsekvent och säker sessionshantering över ditt ekosystem. Lär dig mer om utloggningsmekanismer och hur man implementerar utloggning.

Hantera användartillståndsändringar

Att hantera realtidsändringar av användartillstånd med JWT kan också vara svårt. Eftersom JWT:s är statslösa är varje uppdaterade tillstånd eller roller inte tillgängliga förrän tokenen går ut. Logto erbjuder strategier för att hantera detta effektivt:

  • För att minska rättigheterna för denna användare: Använd korta åtkomsttoken-utgångstider eller verifiera dynamiskt rättigheterna via ett API-anrop.
  • För att lägga till nya rättigheter för denna användare: Uppdatera Autentiseringsservern för att inkludera det nya rättighetsområdet och ombe användare att acceptera dessa ändringar.

Dessa lösningar hjälper till att hålla rättigheterna uppdaterade och säkerställer ett säkrare, mer responsivt system. Lär dig mer om att hantera realtidsändringar av användarrättigheter.

Logto, som är en skalbar identitetsaccesshanteringsinfrastruktur, tillhandahåller en komplett identitetslösning med både molntjänst och öppen källkod-version tillgänglig.