Waarom JWT in de meeste OAuth 2.0-diensten

OAuth 2.0 wordt tegenwoordig veel gebruikt. Als een kernstructuur voor autorisatiediensten is een van de belangrijkste verantwoordelijkheden van OAuth 2.0 het uitgeven van toegangstokens voor gebruikers. We hebben opgemerkt dat veel OAuth-dienstverleners op de markt toegangstokens in JWT-formaat uitgeven.

In dit artikel zullen we uitleggen wat JWT is en waarom het op grote schaal wordt aangenomen als het formaat voor toegangstokens die door OAuth 2.0 worden uitgegeven.

Inleiding tot JWT#

JWT staat voor JSON Web Token, en het wordt gedefinieerd door RFC 7519 als volgt:

JSON Web Token (JWT) is een compact, URL-veilig middel om claims tussen twee partijen over te dragen.

Deze definitie maakt duidelijk dat JWT een token is dat wordt gebruikt om claims tussen verschillende partijen door te geven.

Omdat JWT's worden doorgegeven tussen meerdere partijen, worden ze ondertekend om de integriteit en authenticiteit van de gegevens te waarborgen.

Een ondertekende JWT heeft het volgende formaat:

Het bestaat uit drie delen, gescheiden door ., namelijk de header, de payload en de handtekening.

Hier is een voorbeeld van een real-world JWT:

Je kunt het proberen te parsen op https://jwt.io:

Zoals in de afbeelding te zien is, bevat het header-onderdeel van de JWT informatie over het gebruikte ondertekeningsalgoritme en het type van het token. Het payload-gedeelte bevat de claims die de JWT draagt, en de handtekening wordt gebruikt om de integriteit van de JWT te verifiëren.

Nu we begrijpen wat JWT is en de betekenis van de verschillende onderdelen ervan, laten we uitleggen waarom veel OAuth-autorisatiediensten JWT als hun toegangstoken kiezen.

Voordelen van het gebruik van JWT#

De belangrijkste verschillen tussen JWT en traditionele tokens gebaseerd op willekeurig gegenereerde tekenreeksen zijn dat JWT's informatie kunnen dragen en kunnen worden gevalideerd door decodering. Deze verschillen brengen twee belangrijke voordelen met zich mee:

• Resource-efficiëntie: JWT's kunnen informatie over de gebruiker of sessie dragen, waardoor de behoefte aan frequente databaselooksups wordt geëlimineerd. Deze efficiëntie kan het middelenverbruik van diensten verminderen.
• Verbeterde beschikbaarheid en schaalbaarheid: JWT's verminderen de afhankelijkheid van server-side statusbeheer. Dit maakt het mogelijk dat diensten meer stateless zijn, waardoor hun beschikbaarheid en schaalbaarheid worden verbeterd.

Bij het gebruik van traditionele tokens gebaseerd op willekeurige tekenreeksen is het typische proces voor verificatie en authenticatie als volgt:

Zoals te zien is in het diagram, wanneer een systeem veel gebruikers en veel verschillende resourceservers heeft, kan dit resulteren in talrijke validatieverzoeken voor tokens aan de Auth Server.

Na verloop van tijd, naarmate het systeem groeit, kan de Auth Server gemakkelijk een knelpunt worden en een uitdaging vormen voor de algehele beschikbaarheid van de dienst.

Echter, wanneer JWT's worden geïntroduceerd, verandert het validatieproces naar:

Dankzij de mogelijkheid van JWT's om validatie door middel van decodering mogelijk te maken, kan de resourceserver de integriteit van JWT's verifiëren en gebruikersinformatie eruit halen zonder interactie met de Auth Server (voor details over de decodering en validatie van JWT's kun je verwijzen naar de Logto-documentatie).

Beperkingen van JWT#

Hoewel JWT's aanzienlijke voordelen bieden in moderne software-architecturen, hebben ze ook beperkingen waarmee rekening moet worden gehouden.

Gemakkelijk af te luisteren payload#

Zoals eerder vermeld, bestaat een JWT uit drie delen: de header, payload en handtekening. Hoe worden deze componenten gegenereerd? Laten we het JWT uit het vorige voorbeeld nemen en het genereren ervan demonstreren:

Zoals te zien is in de bovenstaande code, worden de header en payload van de JWT gewoon gecodeerd als base64-tekenreeksen.

Dit betekent dat zolang iemand toegang heeft tot het token, hij gemakkelijk de base64-tekenreeks van de JWT-payload kan decoderen en toegang kan krijgen tot de informatie die het draagt. Omgekeerd is het ook relatief eenvoudig om een payload te vervalsen en de originele JWT-payload te vervangen door een gemanipuleerde.

Hoewel het waar is dat de payload van een JWT relatief eenvoudig kan worden vervalst, is het belangrijk op te merken dat het deel van de handtekening van de JWT niet kan worden vervangen door vervalste inhoud, aangezien het de geheime ondertekeningssleutel vereist. Zonder de juiste handtekening kan de JWT dus niet door de validatie komen.

Dus, bij het gebruik van JWT's, is het belangrijk om de volgende overwegingen in gedachten te houden:

1. Altijd SSL gebruiken: Om ervoor te zorgen dat JWT-informatie niet tijdens de transmissie wordt gelekt, is het essentieel om SSL (Secure Sockets Layer) of de opvolger, TLS (Transport Layer Security), te gebruiken om de gegevens tijdens het transport te versleutelen.
2. Vermijd het opslaan van gevoelige gegevens: Het wordt niet aanbevolen om gevoelige gegevens in de JWT-payload op te slaan. De payload kan gemakkelijk worden gedecodeerd, zoals eerder vermeld, en zou voornamelijk niet-gevoelige, relevante claims moeten bevatten.
3. Valideer JWT's: Voordat je vertrouwt op de informatie in een JWT, zorg ervoor dat deze een geldig en veilig validatieproces heeft doorstaan, inclusief verificatie van de handtekening en controle van tokenverval. Dit helpt het gebruik van vervalste of ongeautoriseerde tokens te voorkomen.

Moeilijk om in te trekken#

Over het algemeen hebben toegangstokens meestal een vervaltijd. Als het toegangstoken wordt weergegeven als willekeurige tekenreeksen zonder enige informatie, kunnen we controleren of het token is ingetrokken tijdens elke validatie in de Auth Server.

Wat betreft JWT's, vanwege het feit dat JWT's verstrijken informatie in zichzelf bevatten, en het feit dat JWT-validatie niet afhankelijk is van de Auth Server, wordt het onmogelijk om de status van het token tijdens het gebruik te wijzigen zodra een Auth Server een toegangstoken in JWT-formaat uitgeeft.

Nadat een JWT-token natuurlijk verloopt, kunnen we een nieuwe JWT verkrijgen van de autorisatieserver met behulp van een verfrissingstoken (u kunt verwijzen naar Logto's blog voor informatie over verfrissingstokens).

Echter, in bepaalde situaties, zoals wanneer een gebruiker de autorisatie intrekt of hun wachtwoord wijzigt, en u een al uitgegeven maar nog niet verlopen token moet intrekken, is er geen directe oplossing beschikbaar.

Er zijn twee gangbare benaderingen om de impact van tokenintrekking halverwege te beperken:

1. Stel een kortere vervaltijd in voor het toegangstoken en vertrouw op het tokenverversingsmechanisme om de status van het token tijdig te verversen.

Omdat het toegangstoken een kortere vervaltijd heeft, wanneer een gebruiker ontdekt dat het toegangstoken is verlopen, kan hij een nieuw toegangstoken aanvragen via een verfrissingstoken van de autorisatiedienst. Op deze manier kan de status van het token aan de kant van de gebruiker zo snel mogelijk worden gesynchroniseerd met de backend. Deze benadering gaat echter gepaard met extra overhead, waarmee gebruikers rekening moeten houden.

2. Onderhoud een intrekkingslijst voor toegangstokens en controleer of het token op de lijst staat tijdens elke validatie.

Deze methode heeft bepaalde beperkingen. Een van de voordelen van JWT is dat het de server niet vereist om statusinformatie op te slaan, en JWT's zijn doorgaans stateloos. Het onderhouden van een intrekkingslijst vereist echter effectieve opslag en onderhoud, afhankelijk van extra opslagmechanismen. Dit offert in wezen de voordelen van JWT op en kan mogelijk leiden tot prestatieproblemen. Daarom moet het mechanisme voor het intrekken van tokens door ontwikkelaars worden geïmplementeerd op een manier die geschikt is voor hun specifieke gebruikssituaties.

Samenvatting#

In dit artikel hebben we een korte inleiding gegeven tot JWT, met de nadruk op zijn voordelen en beperkingen. Inmiddels zou je een dieper begrip moeten hebben van JWT en de scenario's waarin het vaak wordt gebruikt. Hoewel JWT zijn uitdagingen heeft, wegen de voordelen die het biedt wanneer het wordt gebruikt als het tokenformaat in OAuth 2.0-diensten ruimschoots op tegen de nadelen.

Logto, als een snelgroeiende identiteitsauthenticatiedienst, maakt ook gebruik van JWT als het formaat voor zijn toegangstokens. Het volgt strikt verschillende autorisatie- en authenticatieprotocollen, waardoor het buitengewoon eenvoudig is om identiteitsauthenticatiediensten in je producten te integreren. Logto heeft zijn SaaS-dienst officieel gelanceerd, en je kunt het vandaag gratis proberen.