JWT versus 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 identiteitssysteem (bijv. identity provider, auth-server, enz.) wie de gebruiker is en tot welke bronnen hij toegang heeft.

Aangezien HTTP van nature statusloos is, is elke aanvraag in een sessie onafhankelijk en haalt deze geen informatie uit eerdere aanvragen. Het steeds opnieuw authentiseren van gebruikers is omslachtig en schaadt de gebruikerservaring.

Laten we sessiegebaseerde authenticatie en JWT (JSON Web Tokens) authenticatie bekijken, twee populaire methoden om 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, is deze gids hier om te helpen.

Wat is sessiegebaseerde authenticatie?#

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

Hoe werkt sessiegebaseerde authenticatie?#

Sessiecreatie

1. Een gebruiker authenticiseert 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, gebruikers-ID, sessie starttijd, sessieverloop tijd, enz.
3. De SessionID wordt in de database opgeslagen en aan de client van de gebruiker teruggegeven als een cookie.

Sessievalidatie

1. Het proces kan handmatig door de gebruiker worden geactiveerd (bijv. op een tab klikken, een pagina vernieuwen) of automatisch door de client (bijv. tijdens initiële paginaladingen of via API-aanroepen met een SessionID).
2. Elke daaropvolgende oproep stuurt een HTTP-aanvraag van de client die de sessie-cookie naar de server bevat.
3. De server valideert het SessionID door de sessiegegevens op de server te raadplegen.
4. Bij geldigheid verwerkt de server de aanvraag en autoriseert de gebruiker.

Hoe een sessie te herroepen?#

Sessies kunnen in real-time ongeldig worden gemaakt, wat handig is in situaties waar snelle toegangsherroeping noodzakelijk is.

• Gebruikers loggen handmatig uit: De server verwijdert het sessierecord, waardoor de gebruiker wordt uitgelogd.
• Beheerders dwingen gebruikers uit te loggen: Beheerders of systemen kunnen een specifieke sessie beëindigen door deze uit de database te verwijderen. Bijvoorbeeld, tijdens een beveiligingsinbreuk.
• Sessieverloop: Sessies kunnen automatisch verlopen na een ingestelde periode van inactiviteit of een vast tijdslimiet.

Voordelen van sessiegebaseerde authenticatie#

• Eenvoudig en betrouwbaar: Het sessierecord biedt een duidelijke, gecentraliseerde bron, waardoor er een hoge mate van vertrouwen is en autorisatiebeslissingen betrouwbaarder zijn.
• Revoke in real-time: Door het sessierecord te verwijderen of ongeldig te maken, kan de toegang van een gebruiker snel worden ingetrokken.

Nadelen van sessiegebaseerde authenticatie#

• Latentie in gedistribueerd systeem: Het synchen van sessiegegevens over meerdere servers vereist altijd het synchroniseren van een sessiestore. Dit introduceert extra latentie omdat de server de sessiestore elke keer dat een verzoek binnenkomt moet controleren.
• Hoge middelenconsumptie: Elke sessie vereist serverbronnen, wat de prestaties aantast naarmate het gebruikersbestand toeneemt.
• Beveiligingsrisico: Sessieovername (via gestolen sessiecookies) kan ongeautoriseerde toegang tot gebruikersaccounts toestaan.
• Beperkt gebruik voor APIs: Sessiegebaseerde authenticatie is niet ideaal voor mobiele apps. Het slaat sessiegegevens op de server op, wat de belasting en complexiteit kan vergroten met veel gebruikers. Bovendien gebruikt het cookies, die moeilijker te beheren zijn op mobiele apparaten.

Wat is JWT-authenticatie?#

JSON Web Tokens (JWTs) nemen een andere benadering door alle relevante gebruikersinformatie direct in een token op te nemen, met gebruik van een JSON-object. In tegenstelling tot sessiegebaseerde methoden zijn JWTs statusloos, wat betekent dat de server geen authenticatierecords beheert.

Hoe werkt JWT-authenticatie?#

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

• De header bevat het ondertekeningsalgoritme (bijv. HS256) en het type van de token (JWT).
• De payload bevat kernclaims, zoals de identiteit van de gebruiker, de gebruikersrol en de vervaltijd.
• De signature maakt gebruik van een sleutel om de header en payload te ondertekenen, waardoor de verificatie of de handtekening is gewijzigd mogelijk wordt.

JWT-uitgifte

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

Sessiegebaseerde werkstromen volgen een vergelijkbaar proces. Echter, na authenticatie wordt gebruikersinformatie op de server opgeslagen binnen een sessie, terwijl JWTs vertrouwen op tokens die naar de client worden gestuurd voor opslag en verder gebruik.

Tokenvalidatie

1. Voor opvolgende API-aanvragen stuurt de client de JWT in de Authorization-header (Bearer <token>).
2. De server verifieert de handtekening van de JWT met gebruik van een geheime of openbare sleutel en controleert de claims (bijv. verval, uitgever).
3. Als de token geldig is, verleent de server de client toegang tot de gevraagde bronnen.

Sessiegebaseerde authenticatie vereist dat de server een sessiestore raadpleegt, wat traag kan zijn, vooral als deze afhankelijk is van externe of gecentraliseerde databases. Daarentegen is JWT-authenticatie statusloos, met alle noodzakelijke informatie opgeslagen in de cliënttoken, en maakt gebruik van handtekeningsvalidatie voor beveiliging. Dit elimineert de noodzaak voor sessiebeheer, waardoor het sneller en schaalbaarder wordt, vooral in gedistribueerde systemen.

Hoe een JWT te herroepen?#

Aan de clientzijde betekent uitloggen meestal het wissen van de lokale sessie en het verwijderen van tokens (ID, toegangstoken, ververstoken) uit de opslag. Echter, voor JWT-authenticatie, logt dit de gebruiker alleen lokaal uit, waardoor de gecentraliseerde sessie op de autorisatieserver intact blijft. Als gevolg hiervan kunnen gebruikers mogelijk nog andere apps onder dezelfde sessie openen totdat het token verloopt of handmatig wordt beëindigd.

Het herroepen van een JWT (JSON Web Token) is uitdagender dan sessiegebaseerde authenticatie omdat JWTs statusloos zijn en niet ongeldig kunnen worden gemaakt zodra uitgegeven, tenzij specifieke strategieën worden geïmplementeerd. Veelvoorkomende methoden zijn:

• Korte vervaltijden: Stel een korte exp-claim in (bijv. 15 minuten) voor de JWT. Zodra deze verloopt, moet de gebruiker opnieuw authenticeren. Dit minimaliseert risico als een token gecompromitteerd is, aangezien de aanvaller het slechts voor een beperkte tijd kan gebruiken. Om een naadloze gebruikerservaring te behouden, kan een ververstoken worden gebruikt om het ongemak van opnieuw authenticeren te minimaliseren.
• Token blacklist: Voor kritieke gevallen (bijv. gebruiker uitloggen, wachtwoordwijzigingen), moet een blacklist van herroepen tokens worden onderhouden. De server controleert inkomende tokens tegen deze blokkadelijst en weigert eventuele overeenkomsten. Hoewel effectief, vereist deze benadering het bijhouden van herroepen tokens, wat indruist tegen de statusloze aard van JWTs en inefficiënt kan worden als de lijst te groot wordt.
• Herroepingsendpoint: Introduceer een herroepingsendpoint op de autorisatieserver waar tokens (bijv. ververstokens) kunnen worden ongeldig gemaakt. Zodra een ververstoken is herroepen, worden eventuele toegangstokens die daaruit zijn uitgegeven, niet meer verlengd. Deze methode werkt goed in OAuth2-stromen.

Voordelen van JWT-authenticatie#

• Snel en meer informatief: De zelfbeheerde aard van JWTs maakt cliëntzijdevalidatie sneller en efficiënter, zonder noodzaak voor serverinteractie. Ze kunnen ook aangepaste claims (bijv. gebruikersrollen of andere relevante data) binnen de token bevatten, waardoor servers rollen kunnen bepalen zonder een database te raadplegen.
• Verbeterde beveiliging: JWTs gebruiken ondertekenings- en versleutelingstechnieken, wat aanvallen moeilijker maakt.
• Ondersteuning voor meerdere domeinen: JWTs zijn perfect voor Single Sign-On (SSO) en authenticatie over meerdere domeinen. Ze stellen gebruikers in staat om over meerdere domeinen of diensten te authenticeren met dezelfde token.
• Mobielvriendelijk: JWTs werken geweldig voor mobiele applicaties die behoefte hebben aan statusloze authenticatie. Tokens kunnen aan de cliëntzijde worden opgeslagen en bij elk verzoek worden verzonden, wat de efficiëntie en het gebruiksgemak verbetert.

Nadelen van JWT-authenticatie#

• JWT wordt niet in real-time bijgewerkt

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

  Als de toegangsrechten van een gebruiker veranderen (meestal worden gedegradeerd), zal de gebruiker nog steeds toegang hebben tot de verwijderde bronnen totdat de JWT verloopt. Evenzo, als een JWT rol-gebaseerde autorisatie-informatie bevat, zal de nieuwe autorisatiescope pas effect hebben nadat de oude JWT verloopt. Met andere woorden, JWTs zijn niet geschikt voor herroeping in real-time en gebruikers kunnen een geschikte vervaltijd instellen om dit probleem te mitigeren.

• Meerdere apparaten en herroepingsdilemma

  Het is niet mogelijk om alle uitgegeven JWTs te valideren voordat ze verlopen om gebruikersherroeping van alle apparaten door te voeren. Hoewel het theoretisch mogelijk is om de ondertekeningssleutel in te trekken om de JWT ongeldig te maken, zou dit ook alle JWTs met die sleutel ongeldig maken, en zou het proces om cache-sleutels af te handelen deze benadering onpraktisch maken voor eenvoudige gebruikersherroepingshandelingen.

Sommige identiteitsproviders kunnen vooraf gebouwde 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 JWTs zijn twee populaire benaderingen voor het handhaven van authenticatie- en autorisatiecontext in een statusloze HTTP-wereld. Hoewel beide benaderingen hun voor- en nadelen hebben, bieden ze verschillende voordelen en nadelen.

Sessies, bieden sterkere garanties voor individuele verzoekauthenticatie en zijn eenvoudiger veilig te implementeren. Echter, hun afhankelijkheid van server-side database validatie introduceert latentieoverhead, wat een negatief effect kan hebben op de gebruikerservaring voor zeer responsieve toepassingen.

JWTs, aan de andere kant, zijn voordelig voor snellere authenticatie en interoperabiliteit met externe apps, maar vereisen meer ontwikkelingsinspanning om beveiligingscomplexiteiten aan te pakken. Bijvoorbeeld, we kunnen webhooks gebruiken om cliënten te informeren wanneer de toegang van de gebruiker is ingetrokken, zodat cliënten de in cache JWT kan wissen en de gebruiker kan dwingen opnieuw te authenticeren.

Aangezien op tokens gebaseerde authenticatie beter geschikt is om op te schalen met zijn nadelen nog beheersbaar, wordt het geadopteerd door steeds meer moderne applicaties.

Systeem versus JWT: De juiste methode kiezen#

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

Wanneer sessiegebaseerde authenticatie te gebruiken#

Sessiegebaseerde authenticatie werkt het beste wanneer je real-time sessiebeheer nodig hebt, gecentraliseerd beheer nodig is, of schaalbaarheid geen grote zorg is. Hier is waar het in uitblinkt:

• Webapplicaties met persistente sessies

  Voor platforms zoals online shopping-websites zijn sessies essentieel om gebruikers, winkelmandjes en voorkeuren tijdens hun bezoek bij te houden.

• Applicaties die real-time sessiebeheer vereisen

  Applicaties zoals bank- of financiële diensten profiteren van servergecontroleerde sessiegegevens, waarbij robuust toegangsbeheer en beveiliging worden gegarandeerd.

• Single-server of kleinschalige systemen

  Interne tools of kleinschalige apps zonder grote schaalbehoeften gedijen goed op eenvoudig sessiebeheer voor gebruiksgemak en betrouwbaarheid.

Wanneer JWT-authenticatie te gebruiken#

JWT-authenticatie is beter geschikt voor applicaties die schaalbaarheid, efficiëntie en gedistribueerde systemen prioriteren. Het is bijzonder nuttig voor statusloze interacties tussen cliënten en servers. Overweeg op tokens gebaseerde authenticatie voor het volgende:

• Single Sign-On (SSO)

  JWTs zijn perfect voor Single Sign-On, waarmee gebruikers eenmaal kunnen authenticeren en naadloos toegang krijgen tot meerdere diensten of applicaties met dezelfde token. Deel een gedetailleerde uitleg over beveiligde cloud-gebaseerde applicaties met OAuth 2.0 en OIDC, met JWT-formaat voor zowel access tokens als ID tokens.

• Mobiele applicaties

  Mobiele apps prefereren vaak JWTs voor authenticatie aangezien tokens veilig op het apparaat kunnen worden opgeslagen en met elke API-aanroep kunnen worden verzonden. Ontdek de snelle integratie van JWT-authenticatie voor Android / iOS.

• Microservices-architecturen

  In microservices-omgevingen staan JWTs elke service toe de token onafhankelijk te valideren zonder afhankelijkheid van een centrale sessiestore, waardoor schaalbaarheid en efficiëntie worden gegarandeerd.

• Cross-domein-authenticatie

  JWTs excelleren in scenario's die meerdere domeinen of subdomeinen omvatten (bijv. api.example.com, dashboard.example.com, en docs.example.com). In tegenstelling tot cookies, stellen JWTs authenticatie over domeinen toe zonder extra afhankelijkheden.

• APIs en webservices

  RESTful APIs en webservices gebruiken vaak JWTs voor authenticatie omdat ze lichtgewicht, draagbaar zijn en de noodzaak voor server-side sessiebeheer elimineren. Leer meer over machine-to-machine authenticatie voor scenario's waarin je app direct met bronnen moet communiceren.

Best practices 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 hindernissen te overwinnen, waardoor het een topkeuze is voor veilige en efficiënte authenticatie.

Omgaan met uitlogproblemen van gebruikers bij JWT#

Een veelvoorkomend probleem bij JWT-authenticatie is het waarborgen van een juiste gebruikersuitlogervaring. Logto vereenvoudigt dit proces met zijn out-of-the-box SDK.

• Door tokens en lokale sessies aan de cliëntzijde te wissen en gebruikers naar Logto's eindsessie-endpoint te sturen, kun je sessies eenvoudig beëindigen op zowel de cliëntapplicatie als de server.
• Bovendien ondersteunt Logto back-channel uitloggen, waarmee de AuthServer alle cliëntapplicaties die dezelfde sessie delen kan informeren wanneer een gebruiker zich afmeldt.

Dit zorgt voor consistent en veilig sessiebeheer in je ecosysteem. Leer meer over uitlogmechanismen en hoe je uitloggen implementeert.

Omgaan met wijziging in gebruikerspermissies#

Het beheren van real-time wijzigingen in gebruikerspermissies met JWT kan ook lastig zijn. Aangezien JWTs van nature statusloos zijn, kunnen eventuele bijgewerkte rechten of rollen pas effect hebben nadat de token verloopt. Logto biedt strategieën om dit effectief aan te pakken:

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

Deze oplossingen helpen permissies actueel te houden en zorgen voor een veiliger, responsiever systeem. Leer meer over het beheren van real-time wijzigingen in gebruikerspermissies.

Logto, dat een schaalbare identiteits- en toegangsbeheerinfra is, biedt een complete identiteitsoplossing met zowel een cloud dienst als open-source versie beschikbaar.