JWT vs Sessie-authenticatie

Over het algemeen is de eerste stap bij het gebruik van een applicatie authenticatie, waarbij de eindgebruiker zijn identiteitsgegevens verstrekt om succesvol in te loggen. Na deze stap weet het identiteitsysteem (d.w.z. identiteitsprovider, auth-server, enz.) wie de gebruiker is en tot welke resources zij toegang hebben.

Gezien HTTP inherent statusloos is, is elke aanvraag in een sessie onafhankelijk en onthoudt het geen informatie van eerdere aanvragen. Het telkens opnieuw authentiseren van gebruikers voor elke actie is omslachtig en schaadt de gebruikerservaring.

Laten we kennismaken met Sessie-gebaseerde authenticatie en JWT (JSON Web Tokens) authenticatie, twee populaire methoden om de authenticatiestatus te behouden. Elk heeft unieke voordelen en afwegingen, en de keuze tussen hen hangt af van de specifieke behoeften van je applicatie. Als je twijfelt tussen de twee, biedt deze gids hulp.

Wat is sessie-gebaseerde authenticatie?#

Sessie-gebaseerde authenticatie vertrouwt op de server om een record van de authenticatiestatus van de gebruiker bij te houden. Door het creëren en beheren van sessies stelt de server gebruikers in staat ingelogd te blijven en te blijven communiceren met een applicatie zonder elke keer opnieuw hun inloggegevens te moeten invoeren.

Hoe werkt sessie-gebaseerde authenticatie?#

Aanmaken van een sessie

1. Een gebruiker authentiseert en verstrekt enkele inloggegevens (bijv. e-mail en wachtwoord).
2. Als de inloggegevens geldig zijn, maakt de server een persistent record aan dat die sessie vertegenwoordigt. De sessie bevat informatie zoals een willekeurige string, gebruikersidentificatie, sessie starttijd, sessie-vervaltijd, enz.
3. De SessionID wordt opgeslagen in de database en teruggestuurd naar de client van de gebruiker als een cookie.

Valideren van een sessie

1. Het proces kan handmatig door de gebruiker worden gestart (bijv. een tabblad klikken, een pagina verversen) of automatisch door de client (bijv. tijdens het laden van de initiële pagina's of via API-aanroepen met een SessionID).
2. Elke volgende oproep stuurt een HTTP-verzoek van de client met de sessie-cookie naar de server.
3. De server valideert de SessionID door de sessiegegevens op de server te raadplegen.
4. Als deze geldig is, verwerkt de server het verzoek en autoriseert de gebruiker.

Hoe een sessie intrekken?#

Sessies kunnen in realtime ongeldig worden gemaakt, wat handig is in situaties waar snelle toegangsintrekking nodig is.

• Gebruikers loggen handmatig uit: De server verwijdert het sessierecord, wat effectief de gebruiker uitlogt.
• Beheerders forceren gebruikersuitlogging: Beheerders of systemen kunnen een specifieke sessie beëindigen door deze uit de database te verwijderen. Bijvoorbeeld, tijdens een beveiligingslek.
• Sessie-verval: Sessies kunnen automatisch verlopen na een ingestelde duur van inactiviteit, of een vaste tijdsduur.

Voordelen van sessie-gebaseerde authenticatie#

• Eenvoudig en betrouwbaar: Het sessierecord biedt een duidelijke, gecentraliseerde bron, wat een hoge mate van vertrouwen mogelijk maakt en autorisatiebeslissingen betrouwbaarder maakt.
• Realtime intrekking: Door het sessierecord te verwijderen of ongeldig te maken, kan de toegang van een gebruiker snel worden ingetrokken.

Nadelen van sessie-gebaseerde authenticatie#

• Vertraging in een gedistribueerd systeem: Het bijhouden van sessiegegevens over meerdere servers vereist altijd het synchroniseren van een sessie-opslag. Dit introduceert extra vertraging omdat de server de sessie-opslag moet controleren elke keer dat een verzoek wordt gedaan.
• Hoge resourceconsumptie: Elke sessie gebruikt serverresources, wat invloed heeft op de prestaties wanneer de gebruikersbasis groeit.
• Veiligheidsrisico: Sessiekaping (via gestolen sessiecookies) kan ongeoorloofde toegang tot gebruikersaccounts mogelijk maken.
• Beperkt gebruik voor API's: Sessie-gebaseerde authenticatie is niet ideaal voor mobiele apps. Het slaat sessiegegevens op de server op, wat de belasting en complexiteit kan verhogen met veel gebruikers. Bovendien gebruikt het cookies, die moeilijker te hanteren zijn op mobiele apparaten.

Wat is JWT-authenticatie?#

JSON Web Tokens (JWTs) hanteren een andere benadering door alle relevante gebruikersinformatie direct in een token te embedden, gebruikmakend van een JSON-object. In tegenstelling tot sessie-gebaseerde methoden, zijn JWTs statusloos, wat betekent dat de server geen authenticatierecords bijhoudt.

Hoe werkt JWT-authenticatie?#

Een JWT bestaat uit drie delen: een header, payload, en handtekening.

• De header bevat het ondertekeningsalgoritme (bijv. HS256) en het type van het token (JWT).
• De payload bevat kern claims, zoals de identiteit van de gebruiker, gebruikersrol, en vervaltijd.
• De handtekening gebruikt een sleutel om de header en payload te ondertekenen, zodat kan worden geverifieerd of de handtekening is aangepast.

Uitgifte van JWTs

1. De client stuurt gebruikersgegevens naar de authenticatieserver (Een universele identiteitsprovider is bijzonder nuttig voor het beheren van toegang over meerdere domeinen.)
2. Na succesvolle authenticatie genereert de server een JWT die de header, payload en handtekening bevat.
3. AuthServer stuurt het uitgegeven token naar Client. De client slaat de JWT op (bijv. in cookies, localStorage of sessionStorage).

Sessies-gebaseerde workflows volgen een vergelijkbaar proces. Echter, na authenticatie worden gebruikersgegevens op de server opgeslagen binnen een sessie, terwijl JWT's vertrouwen op tokens die naar de client worden gestuurd voor opslag en later gebruik.

Validatie van tokens

1. Voor volgende API-verzoeken stuurt de client de JWT in de Authorization header (Bearer <token>).
2. De server verifieert de JWT's handtekening met een geheime of publieke sleutel en controleert de claims ervan (bijv. verval, uitgever).
3. Als het token geldig is, verleent de server de client toegang tot de gevraagde resources.

Sessie-gebaseerde authenticatie vereist dat de server een sessie-opslag opvraagt, wat traag kan zijn, vooral als het afhankelijk is van externe of gecentraliseerde databases. In tegenstelling, is JWT-authenticatie statusloos, met alle benodigde informatie opgeslagen in het client-token, en maakt het gebruik van handtekeningen om de veiligheid te waarborgen. Dit elimineert de noodzaak voor sessiebeheer, wat het sneller en meer schaalbaar maakt, vooral in gedistribueerde systemen.

Hoe een JWT intrekken?#

Aan de clientzijde betekent uitloggen meestal het opruimen van de lokale sessie en het verwijderen van tokens (ID, toegang, verversingstoken) uit de opslag. Echter, voor JWT-authenticatie betekent dit alleen dat de gebruiker lokaal is uitgelogd, terwijl de gecentraliseerde sessie op de autorisatie server intact blijft. Dit resulteert in gebruikers die mogelijk nog steeds toegang hebben tot andere apps onder dezelfde sessie totdat het token verloopt of handmatig wordt beëindigd.

Het intrekken van een JWT (JSON Web Token) is uitdagender dan sessie-gebaseerde authenticatie omdat JWT's statusloos zijn en niet ongeldig kunnen worden gemaakt zodra ze zijn uitgegeven, tenzij specifieke strategieën worden toegepast. Veelgebruikte methoden omvatten:

• Korte vervaltijden: Stel een korte exp claim (bijv. 15 minuten) in voor de JWT. Eenmaal verlopen moet de gebruiker zich opnieuw authentiseren. Dit minimaliseert risico als een token wordt gecompromitteerd, aangezien de aanvaller het slechts voor beperkte tijd kan gebruiken. Om een naadloze gebruikerservaring te behouden, kan verversingstoken worden gebruikt om het ongemak van herauthenticatie te minimaliseren.
• Tokenzwarte lijst: Voor kritische gevallen (bijv. gebruikersuitgang, wachtwoordwijzigingen), houd een zwarte lijst bij van ingetrokken tokens. De server controleert binnenkomende tokens tegen deze blokkadelijst en wijst een overeenkoming af. Hoewel effectief, vereist deze aanpak het bijhouden van ingetrokken tokens, wat tegen de statusloze aard van JWT's indruist en inefficiënt kan worden als de lijst te groot wordt.
• Intrekkingsendpoint: Introduceer een intrekkingsendpoint op de autorisatieserver waar tokens (bijv. verversing tokens) ongeldig kunnen worden gemaakt. Zodra een verversingstoken is ingetrokken, worden eventuele toegangstokens die daaruit zijn uitgegeven niet langer vernieuwd. Deze methode werkt goed in OAuth2 flows.

Voordelen van JWT-authenticatie#

• Snel en informatiever: De zelf-bevattende aard van JWT's maakt client-side verificatie sneller en efficiënter, zonder de noodzaak van serverinteractie. Ze kunnen ook aangepaste claims (bijv. gebruikersrollen of andere relevante gegevens) binnen het token opnemen, zodat servers rollen kunnen bepalen zonder een database te raadplegen.
• Verbeterde beveiliging: JWT's maken gebruik van onderteken- en versleutelingstechnieken, waardoor aanvallen moeilijker worden.
• Ondersteuning voor kruis-domein: JWT's zijn perfect voor Single Sign-On (SSO) en kruis-domein authenticatie. Ze stellen gebruikers in staat te authentiseren via meerdere domeinen of diensten met hetzelfde token.
• Mobielvriendelijk: JWT's werken uitstekend voor mobiele applicaties die statusloze authenticatie nodig hebben. Tokens kunnen aan de clientzijde worden opgeslagen en met elk verzoek worden verzonden, wat de efficiëntie en het gebruiksgemak verbetert.

Nadelen van JWT-authenticatie#

• JWT is niet bijgewerkt in realtime

  Zodra een JWT is ondertekend, kan het niet worden ingetrokken of bijgewerkt, en zal het als geldig worden beschouwd zolang de handtekening geldig is en niet is verlopen.

  Als de toegangsrechten van een gebruiker veranderen (meestal verlaagd), behoudt de gebruiker toegang tot de resources totdat de JWT verloopt. Evenzo, als een JWT rol-gebaseerde autorisatie-informatie bevat, zal het nieuwe autorisatiescope niet van kracht worden totdat de oude JWT verloopt. In andere woorden, JWT's zijn niet geschikt voor realtime intrekking en gebruikers kunnen een juiste vervaltijd instellen om dit probleem te mitigeren.

• Meerdere apparaten en intrekkingsdilemma

  Het is niet mogelijk om alle uitgegeven JWT's te valideren voordat ze verlopen om de intrekking van gebruikers van alle apparaten te implementeren. Hoewel het theoretisch mogelijk is om de ondertekeningssleutel in te trekken om de JWT ongeldig te maken, zou dit ook alle JWT's die die sleutel gebruiken ongeldig maken, en het proces van het afhandelen van cache sleutels zou deze aanpak onpraktisch maken voor eenvoudige gebruikersintrekkingsoperaties.

Sommige identiteitsproviders kunnen kant-en-klare oplossingen hebben voor deze JWT-problemen. Voor meer informatie, bekijk "Best Practices to Enhance the JWT Authentication Experience.”

Wat is het verschil tussen JWT en Sessie?#

Sessies en JWT's zijn twee populaire benaderingen voor het behouden van authenticatie- en autorisatiecontext in een stateloze HTTP-wereld. Hoewel beide benaderingen hun voor- en nadelen hebben, bieden ze verschillende voordelen en nadelen.

Sessies bieden sterkere garanties voor individuele verzoek autorisatie en zijn eenvoudiger veilig te implementeren. Echter, hun afhankelijkheid van server-side database validatie introduceert vertragingsoverhead, wat de gebruikerservaring voor hoog responsieve applicaties negatief kan beïnvloeden.

JWT's daarentegen zijn voordelig voor snellere autorisatie en interoperabiliteit met externe apps, maar vereisen meer inspanning van ontwikkelaars om beveiligingscomplexiteiten aan te pakken. Bijvoorbeeld, we kunnen webhooks gebruiken om clients te informeren wanneer de toegang van de gebruiker is ingetrokken, zodat clients de gecachte JWT kunnen wissen en de gebruiker kunnen dwingen om zich opnieuw te authentiseren.

Aangezien token-gebaseerde authenticatie geschikter is om op te schalen met beheersbare nadelen, wordt het door steeds meer moderne applicaties geadopteerd.

Sessie vs. JWT: De juiste methode kiezen#

Je authenticatiemethode moet overeenkomen met de architectuur van je app en specifieke behoeften. Hier is een snelle gids om je te helpen beslissen:

Wanneer sessie-gebaseerde authenticatie gebruiken#

Sessie-gebaseerde authenticatie werkt het beste wanneer je realtime sessiecontrole nodig hebt, gecentraliseerd beheer nodig hebt, of schaalbaarheid geen grote zorg is. Hier excelleert het:

• Webapplicaties met blijvende sessies

  Voor platforms zoals online winkelwebsites zijn sessies essentieel om gebruikers, winkelwagentjes en voorkeuren tijdens hun bezoek bij te houden.

• Applicaties die real-time sessiecontrole vereisen

  Applicaties zoals bankieren of financiële diensten profiteren van server-gecontroleerde sessiegegevens, wat robuust toegangsbeheer en beveiliging garandeert.

• Enkele-server of kleinschalige systemen

  Interne tools of kleinschalige apps zonder grote schaalbaarheidsbehoeften profiteren van eenvoudig sessiebeheer voor gebruiksgemak en betrouwbaarheid.

Wanneer JWT-authenticatie gebruiken#

JWT-authenticatie is beter geschikt voor applicaties die prioriteit geven aan schaalbaarheid, efficiëntie en gedistribueerde systemen. Het is bijzonder nuttig voor statusloze interacties tussen clients en servers. Overweeg token-gebaseerde authenticatie voor het volgende:

• Single Sign-On (SSO)

  JWT's zijn perfect voor Single Sign-On, waarin gebruikers eenmaal kunnen authentiseren en naadloos meerdere diensten of applicaties met dezelfde token kunnen gebruiken. Deel een gedetailleerde uitleg over veilige cloud-gebaseerde toepassingen met OAuth 2.0 en OIDC, met JWT-formaat voor zowel toegangstokens als ID-tokens.

• Mobiele applicaties

  Mobiele apps verkiezen vaak JWT's voor authenticatie omdat tokens veilig op het apparaat kunnen worden opgeslagen en met elke API-aanroep kunnen worden verzonden. Verken de snelle integratie van JWT-authenticatie voor Android / iOS.

• Microservices-architecturen

  In microservices-omgevingen stellen JWT's elke dienst in staat onafhankelijk het token te valideren zonder afhankelijk te zijn van een centraal sessie-opslag, wat schaalbaarheid en efficiëntie waarborgt.

• Kruis-domein authenticatie

  JWT's exceleren in scenario's die meerdere domeinen of subdomeinen betreffen (bijv. api.example.com, dashboard.example.com en docs.example.com). In tegenstelling tot cookies, stellen JWT's authenticatie over domeinen zonder extra afhankelijkheden mogelijk.

• API's en webdiensten

  RESTful API's en webdiensten gebruiken meestal JWTs voor authenticatie omdat ze lichtgewicht, draagbaar zijn en de noodzaak voor serverside sessiebeheer elimineren. Leer meer over machine-to-machine authenticatie voor scenario's waarin je app direct moet communiceren met resources.

Beste werkwijzen om de JWT-authenticatie-ervaring te verbeteren#

JWT-authenticatie is een geweldig hulpmiddel, maar het kan uitdagingen met zich meebrengen die de gebruikerservaring beïnvloeden. Logto biedt een eenvoudige en betrouwbare oplossing om deze obstakels te overwinnen, waardoor het een topkeuze is voor veilige en efficiënte authenticatie.

Omgaan met gebruikersafmeldproblemen met JWT#

Een veelvoorkomende uitdaging met JWT-authenticatie is het garanderen van een goed gebruikersafmeldingsproces. Logto vereenvoudigt dit proces met zijn kant-en-klare SDK.

• Door het wissen van tokens en lokale sessies aan de clientzijde en het omleiden van gebruikers naar Logto's eindelijnsessie-endpoint, kun je eenvoudig sessies beëindigen op zowel de client-applicatie als de server.
• Bovendien ondersteunt Logto back-channel logout, zodat de AuthServer aan alle client-applicaties die dezelfde sessie delen een melding kan geven als een gebruiker zich afmeldt.

Dit verzekert consistente en veilige sessiebeheer over je ecosysteem. Leer meer over het omgaan met afmeldingen.

Omgaan met wijzigingen in gebruikersrechten#

Real-time wijzigingen in gebruikersrechten beheren met JWT kan ook lastig zijn. Aangezien JWT's van nature statusloos zijn, kunnen alle bijgewerkte rechten of rollen pas van kracht worden nadat het token is verlopen. Logto biedt strategieën om dit effectief aan te pakken:

• Voor het verlagen van rechten voor deze gebruiker: Gebruik korte vervaltijden voor toegangstokens of verifieer de rechten dynamisch via een API-aanroep.
• Voor het toevoegen van nieuwe rechten voor deze gebruiker: Werk de AuthServer bij om het nieuwe toestemmingenscope op te nemen en vraag gebruikers opnieuw toestemming te geven om deze wijzigingen toe te passen.

Deze oplossingen helpen ervoor te zorgen dat rechten up-to-date blijven en zorg dragen voor een veiliger, responsiever systeem. Leer meer over het omgaan met rechtwijzigingen.

Logto, een schaalbare identiteits- en toegangsbeheerinfrastructuur, biedt een complete identiteitsoplossing met zowel cloud service als open-source versie beschikbaar.