Ondoorzichtig token vs JWT

In Logto, als een op OIDC gebaseerde uitgebreide CIAM-platform, spelen autorisatietokens een cruciale rol in het beveiligen van gebruikersinteracties en het beheren van toegang tot bronnen. Onder de verschillende soorten tokens die worden gebruikt voor autorisatie, zijn ondoorzichtige tokens en JWT's (JSON Web Tokens) de belangrijkste.

We hebben verschillende vragen ontvangen van onze gemeenschap, zoals: Wat is het verschil tussen een ondoorzichtig token en een JWT? Waarom kan ik het toegangstoken dat ik ontvangen heb niet decoderen, en waarom lijkt de tokenlengte kort? Dit blogbericht is bedoeld om deze concepten te verduidelijken en je te helpen de verschillen tussen ondoorzichtige tokens en JWT's, hun gebruiksscenario's en waarom je verschillende gedragingen kunt tegenkomen bij het werken met hen, te begrijpen.

Wat is een ondoorzichtig token?#

Een ondoorzichtig token is een type toegangstoken dat, zoals de naam al aangeeft, ondoorzichtig of niet-transparant is voor de client of een externe partij. Dit betekent dat het token zelf geen leesbare informatie over de gebruiker of de verleende autorisatie bevat.

Wanneer je een ondoorzichtig token ontvangt, lijkt het vaak op een schijnbaar willekeurige reeks tekens, en proberen het te decoderen zal geen betekenisvolle gegevens opleveren.

Hier is een voorbeeld van een ondoorzichtig token:

Aangezien de daadwerkelijke inhoud van het token alleen bekend is bij de autorisatieserver die het heeft uitgegeven, moet de client het terugsturen naar de server om een ondoorzichtig token te valideren, die vervolgens de authenticiteit verifieert en de bijbehorende machtigingen bepaalt. Deze aanpak zorgt ervoor dat gevoelige informatie verborgen blijft, waardoor een extra beveiligingslaag wordt geboden, maar het vereist ook extra servercommunicatie om het token te valideren.

Voordelen:

• Veilig: Ondoorzichtige tokens onthullen geen gevoelige informatie aan de client. De inhoud van het token is alleen bekend bij de autorisatieserver.
• Herroepbaar: Aangezien het token op de server is opgeslagen en de enige manier om het te valideren is via het introspectie-eindpunt op de autorisatieserver, kan de server het token gemakkelijk intrekken indien nodig en ongeautoriseerde toegang voorkomen.
• Kleine omvang: Ondoorzichtige tokens zijn typisch korter dan JWT's, wat voordelig kan zijn voor prestaties en opslagoverwegingen.

Nadelen:

• Stateful: Ondoorzichtige tokens vereisen dat de autorisatieserver staat behoudt om het token te valideren, wat extra complexiteit en overhead kan introduceren.
• Prestaties: De noodzaak van extra servercommunicatie om het token te valideren, kan de prestaties beïnvloeden, vooral in scenario's met veel verkeer.

Wat is een JWT?#

In tegenstelling tot ondoorzichtige tokens is een JWT (JSON Web Token) een zelf-bevattend, stateloos token dat informatie bevat in een gestructureerd en leesbaar formaat.

Een JWT bestaat uit drie delen: een header, een payload en een handtekening, elk gecodeerd in Base64URL.

Hier is een voorbeeld van een JWT:

• De header bevat informatie over het type token en het gebruikte algoritme voor ondertekening. Bijvoorbeeld, {"alg": "HS256", "typ": "JWT"}.
• De payload sectie bevat claims—informatie over de gebruiker of de autorisatie—zoals gebruikers-ID, vervaltijd en scopes. Omdat deze gegevens zijn gecodeerd maar niet versleuteld, kan iedereen die het token heeft, het decoderen om de claims te zien, hoewel ze het niet kunnen wijzigen zonder de handtekening ongeldig te maken. Afhankelijk van de specificatie en configuratie van de autorisatieserver kunnen verschillende claims in de payload worden opgenomen. Dit geeft het token zijn zelf-bevattende aard. Bijvoorbeeld, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• De handtekening wordt gegenereerd door de header, payload en een geheime sleutel te combineren met behulp van het gespecificeerde algoritme. Deze handtekening wordt gebruikt om de integriteit van het token te verifiëren en te zorgen dat het niet is aangetast.

JWT's worden vaak gebruikt omdat ze lokaal kunnen worden gevalideerd door de client of een service, zonder dat interactie met de autorisatieserver nodig is. Dit maakt JWT's bijzonder efficiënt voor gedistribueerde systemen, waar meerdere services mogelijk de authenticiteit van het token onafhankelijk moeten verifiëren.

Echter, dit gemak brengt ook de verantwoordelijkheid met zich mee om ervoor te zorgen dat de claims in het token niet te veel worden blootgesteld, aangezien ze zichtbaar zijn voor iedereen die toegang tot het token heeft. Ook zijn JWT's doorgaans kortstondig geldig, en de verstreken tijd is opgenomen in de claims van het token om ervoor te zorgen dat het token niet voor onbepaalde tijd geldig is.

Voordelen:

• Stateless: JWT's zijn zelf-bevattend en vereisen geen server-side staat om te valideren.
• Cross-service compatibiliteit: JWT's kunnen eenvoudig worden gedeeld en gevalideerd tussen verschillende services, waardoor ze ideaal zijn voor gedistribueerde systemen.
• Uitbreidbaar: De payload van een JWT kan aangepaste claims bevatten, wat flexibel autorisatie en informatie-uitwisseling mogelijk maakt.
• Standaard: JWT token volgen een goed gedefinieerde standaard (RFC 7519), waardoor ze breed ondersteund en interoperabel zijn.

Nadelen:

• Blootstelling: De claims in een JWT zijn zichtbaar voor iedereen die toegang heeft tot het token, dus gevoelige informatie moet niet in de payload worden opgenomen.
• Grote omvang: JWT's kunnen groter zijn dan ondoorzichtige tokens vanwege de extra informatie die ze bevatten, wat de prestaties en opslagoverwegingen kan beïnvloeden. De claims in een JWT-token moeten tot een minimum worden beperkt om de omvang van het token te verkleinen.
• Herroepingscomplexiteit: Aangezien JWT's stateloos zijn, zijn ze doorgaans voor een korte periode geldig, en is er geen ingebouwd mechanisme om tokens in te trekken voordat ze verlopen, wat betekent dat een gecompromitteerd token geldig kan blijven totdat het verloopt.

Validatie van ondoorzichtige toegangstokens#

Een ondoorzichtig toegangstoken wordt gevalideerd door het terug te sturen naar de autorisatieserver voor verificatie. De autorisatieserver behoudt de staat van uitgegeven tokens en kan de geldigheid van het token bepalen op basis van zijn interne opslag.

1. De client vraagt een toegangstoken aan bij de autorisatieserver.
2. De autorisatieserver geeft een ondoorzichtig token uit.
3. De client stuurt de verzoek om toegang tot de bron met het ondoorzichtige token in de header.
4. De resourceprovider stuurt een tokenintrospectieverzoek naar de autorisatieserver om het token te valideren.
5. De autorisatieserver reageert met de tokeninformatie.

Validatie van JWT-toegangstoken (offline)#

Een JWT-toegangstoken kan offline worden gevalideerd door de client of een service die toegang heeft tot de openbare sleutel van het token.

0. De resourceprovider haalt vooraf de openbare sleutel van de autorisatieserver op van het OIDC-ontdekkings-eindpunt. De openbare sleutel wordt gebruikt om de handtekening van het token te verifiëren en de integriteit ervan te garanderen.
1. De client vraagt een toegangstoken aan bij de autorisatieserver.
2. De autorisatieserver geeft een JWT-token uit.
3. De client stuurt de bron-toegangsverzoek met het JWT-token in de header.
4. De resourceprovider decodeert en valideert het JWT-token met behulp van de openbare sleutel verkregen van de autorisatieserver.
5. De resourceprovider verleent toegang op basis van de geldigheid van het token.

Gebruiksscenario's in OIDC#

In de context van OIDC (OpenID Connect) dienen ondoorzichtige tokens en JWT's verschillende doeleinden en worden ze gebruikt in verschillende scenario's.

Ondoorzichtige tokens#

1. Opvragen van gebruikersprofiel:

Standaard, wanneer een client een toegangstoken aanvraagt zonder een bron op te geven en de openid scope opneemt, geeft de autorisatieserver een ondoorzichtig toegangstoken uit. Dit token wordt voornamelijk gebruikt om gebruikersprofielinformatie op te halen van het OIDC /oidc/userinfo-eindpunt. Bij het ontvangen van een verzoek met het ondoorzichtige toegangstoken, controleert de autorisatieserver zijn interne opslag om de bijbehorende autorisatie-informatie op te halen en verifieert de geldigheid van het token voordat het reageert met de gebruikersprofielgegevens.

2. Veranderen van ververstoken:

Vervestoken zijn ontworpen om alleen tussen de client en de autorisatieserver te worden uitgewisseld, zonder dat ze met resourceproviders gedeeld hoeven te worden. Als zodanig worden ververstoken meestal uitgegeven als ondoorzichtige tokens. Wanneer het huidige toegangstoken verloopt, kan de client het ondoorzichtige ververstoken gebruiken om een nieuw toegangstoken te verkrijgen, zodat er continu toegang mogelijk is zonder de gebruiker opnieuw te authenticeren.

JWT's#

1. ID-token:

In OIDC is het ID-token een JWT dat gebruikersinformatie bevat en wordt gebruikt om de gebruiker te authentiseren. Typisch uitgegeven naast het toegangstoken, staat het ID-token de client toe om te verifiëren de gebruiker\u0027s identiteit. Bijvoorbeeld:

De client kan het ID-token valideren om de identiteit van de gebruiker te waarborgen en gebruikersinformatie te extraheren voor personalisatie of autorisatiedoeleinden. Het ID-token is bedoeld voor eenmalig gebruik en mag niet worden gebruikt voor API-bontoegangsauthorisatie.

2. API-Hulpmiddelen toegang:

Wanneer een klant een toegangstoken aanvraagt met een specifieke hulpmiddelenindicator, geeft de autorisatieserver een JWT-toegangstoken uit die is bedoeld voor toegang tot die hulpmiddelen. Het JWT bevat claims die de leverancier van middelen kan gebruiken om de toegang van de klant te autoriseren. Bijvoorbeeld,:

De resourceprovider kan het verzoek valideren door de claims te controleren:

• iss: Bevestigt dat het token is uitgegeven door een vertrouwde autorisatieserver.
• sub: Identificeert de gebruiker die geassocieerd is met het token.
• aud: Zorgt ervoor dat het token bedoeld is voor de specifieke bron.
• scope: Verifieert de permisies verleend aan de gebruiker.

Conclusie#

Samenvattend, ondoorzichtige tokens en JWT's hebben verschillende doelen in op OIDC-gebaseerde systemen, waarbij ondoorzichtige tokens een veilige en stateful benadering van autorisatie bieden en JWT's een zelf-bevattende en stateloze alternatieve bieden. Het begrijpen van de verschillen tussen deze token-typen en hun gebruiksscenario's is essentieel voor het ontwerpen van veilige en efficiënte authenticatie- en autorisatiemechanismen in jouw toepassingen.

Ontdek meer toegangstoken functies in Logto:

• Gebruik RBAC om je API te beschermen
• Toegangstoken van de organisatie
• Aangepaste JWT-claims