oauth 2.0oidc

Opaque token

Een opaque token is een type token waarvan het formaat wordt bepaald door de issuer (uitgever), meestal verschijnend als een reeks tekens of cijfers, en vereist validatie door de issuer in plaats van alle nodige informatie te bevatten voor directe validatie.

Wat is een token?

Voordat we opaque tokens introduceren, is het belangrijk te begrijpen wat een token is:

Tokens worden gebruikt om veilige informatie tussen partijen te vertegenwoordigen en over te dragen, en ze ondersteunen het overgrote deel van de authenticatie (认证, Authentication) en autorisatie (authorization) processen die achter de schermen op het internet plaatsvinden. De twee meest populaire soorten tokens in webservices zijn RFC 7519: JSON Web Tokens (JWT) en opaque tokens.

Wat is een opaque token?

Opaque tokens zijn tokens in een propriëtair formaat dat je niet kunt benaderen en bevatten doorgaans een enkele identificator naar informatie in de permanente opslag van een server.

Een opaque token is een vorm die een token kan aannemen, en access tokens en refresh tokens kunnen bestaan als opaque tokens. Het formaat van een opaque token wordt bepaald door zijn issuer (uitgever), en is meestal een reeks cijfers en/of tekens die de issuer helpt om bepaalde informatie op te halen en te identificeren in een database. Hier is een voorbeeld van een opaque token:

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

Aan de andere kant is JWT een ander gangbaar tokenformaat. Het is een JSON-string die alle claims en informatie bevat, samen met een handtekening van de issuer. Standaard is het niet versleuteld, hoewel het kan worden versleuteld met de JSON Web Encryption (JWE) standaard. Hoewel JWT meestal niet versleuteld is, doet dit geen afbreuk aan de veiligheid — de aanwezigheid van de handtekening waarborgt de integriteit van de inhoud van het token, waardoor volledige vertrouwen in de gegevens binnen de JWT mogelijk is.

In tegenstelling tot JWT, dat alle informatie bevat die nodig is om direct bij de beschermde bron gevalideerd te worden, kunnen opaque tokens niet direct door de bron gevalideerd worden. In plaats daarvan vereisen ze validatie door de issuer van het opaque token (meestal de authorization server). Dit validatieproces wordt doorgaans token introspection genoemd.

Wat is JWT?

In tegenstelling tot opaque tokens is een JWT een zelfgecontroleerd, stateless token dat informatie draagt in een gestructureerd en leesbaar formaat.

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

Hier is een voorbeeld van een JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

De header bevat informatie over het type token en het algoritme dat gebruikt is voor ondertekening. Bijvoorbeeld, {"alg": "HS256", "typ": "JWT"}.
De payload sectie bevat claims — stukjes informatie over de gebruiker of de authorisatie — 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 de configuratie van de authorization server, kunnen verschillende claims in de payload worden opgenomen. Dit geeft het token zijn zelfgecontroleerde aard. Bijvoorbeeld, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
De signature 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 ervoor te zorgen dat het niet is gewijzigd.

JWT’s worden vaak gebruikt omdat ze lokaal door de client of een service kunnen worden geverifieerd, zonder interactie met de authorization server nodig te hebben. Dit maakt JWT’s bijzonder efficiënt voor gedistribueerde systemen, waar meerdere services mogelijk de authenticiteit van het token onafhankelijk moeten verifiëren.

Echter, deze gemakken brengen ook de verantwoordelijkheid met zich mee om ervoor te zorgen dat de claims in het token niet overmatig blootgesteld worden, omdat ze zichtbaar zijn voor iedereen die toegang tot het token heeft. Ook zijn JWT’s doorgaans van korte duur, en de vervaltijd is opgenomen in de claims van het token om ervoor te zorgen dat het token niet oneindig geldig is.

Opaque access token validatie

Een opaque access token wordt gevalideerd door het terug te sturen naar de authorization server voor verificatie. De authorization server bewaart de status van uitgegeven tokens en kan de geldigheid van het token bepalen op basis van zijn interne opslag.

De client vraagt een access token aan bij de authorization server.
De authorization server geeft een opaque token uit.
De client stuurt de resource access request met het opaque token in de header.
De resource provider stuurt een token introspection ( RFC 7662: OAuth 2.0 Token Introspection ) verzoek naar de authorization server om het token te valideren.
De authorization server reageert met de tokeninformatie.

JWT access token validatie (offline)

Een JWT access token kan offline worden gevalideerd door de client of een dienst die toegang heeft tot de publieke sleutel van het token.

De resource provider haalt vooraf de public key van de authorization server op van het OIDC discovery endpoint. De public key wordt gebruikt om de handtekening van het token te verifiëren en de integriteit ervan te waarborgen.
De client vraagt een access token aan bij de authorization server.
De authorization server geeft een JWT token uit.
De client stuurt de resource access request met het JWT token in de header.
De resource provider decodeert en valideert het JWT token met behulp van de public key verkregen van de authorization server.
De resource provider verleent toegang op basis van de geldigheid van het token.

Gebruik van opaque tokens en JWTs in OIDC

In de context van OIDC (OpenID Connect) dienen opaque tokens en JWT’s verschillende doelen en worden ze in verschillende scenario’s gebruikt.

Opaque tokens

Gebruikersprofiel ophalen:

Standaard, wanneer een client een access token aanvraagt zonder een resource te specificeren en de openid scope bevat, geeft de authorization server een opaque access token uit. Dit token wordt voornamelijk gebruikt voor het ophalen van gebruikersprofielinformatie van het OIDC /oidc/userinfo endpoint. Bij ontvangst van een verzoek met het opaque access token controleert de authorization server zijn interne opslag om de bijbehorende autorisatie-informatie op te halen en de geldigheid van het token te verifiëren voordat hij reageert met de gebruikersprofielgegevens.

Refresh token uitwisseling:

Refresh tokens zijn ontworpen om alleen uitgewisseld te worden tussen de client en de authorization server, zonder dat ze gedeeld hoeven te worden met resource providers. Om deze reden worden refresh tokens doorgaans uitgegeven als opaque tokens. Wanneer het huidige access token verloopt, kan de client het opaque refresh token gebruiken om een nieuw access token te verkrijgen, waardoor continue toegang mogelijk is zonder de gebruiker opnieuw te authenticeren.

JWTs

ID token:

In OIDC is het ID token een JWT die gebruikersinformatie bevat en wordt gebruikt om de gebruiker te authenticeren. Meestal uitgegeven naast het access token, stelt het ID token de client in staat om de identiteit van de gebruiker te verifiëren. Bijvoorbeeld:

// Gedecodeerde payload van een ID token
{
  "iss": "<https://logto.io>",
  "sub": "1234567890",
  "aud": "client_id",
  "exp": 1630368000,
  "name": "John Doe",
  "email": "[email protected]",
  "picture": "<https://example.com/johndoe.jpg>"
}

De client kan het ID token valideren om de identiteit van de gebruiker te waarborgen en gebruikersinformatie te extracten voor personalisatie of autorisatie doeleinden. Het ID token is slechts voor eenmalig gebruik en mag niet gebruikt worden voor toegang tot API resources.

API resource toegang (met gebruik van access token):

Wanneer een client een access token aanvraagt met een specifieke resource indicator, geeft de authorization server een JWT access token uit, bedoeld voor toegang tot die resource. De JWT bevat claims die de resource provider kan gebruiken om de toegang van de client te autoriseren. Bijvoorbeeld:

// Gedecodeerde payload van een JWT access token
{
  "iss": "<https://dev.logto.app>",
  "sub": "1234567890",
  "aud": "<https://api.example.com>",
  "scope": "read write",
  "exp": 1630368000
}

De resource provider kan het verzoek valideren door de claims te controleren:

iss: Bevestigt dat het token is uitgegeven door een vertrouwde authorization server.
sub: Identificeert de gebruiker geassocieerd met het token.
aud: Zorgt ervoor dat het token bedoeld is voor de specifieke resource.
scope: Verifieert de verleende permissies aan de gebruiker.

Zie ook

JSON Web Token (JWT)