oauth 2.0oidc

Wat is Opaque token?

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

Wat is een token?

Voordat we opaque tokens introduceren, is het belangrijk om 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 internet plaatsvinden. De twee meest populaire soorten tokens in webservices zijn JSON Web Token (JWT) en opaque tokens.

Wat is een opaque token?

Opaque tokens zijn tokens in een eigen formaat dat je niet kunt openen en bevatten meestal een identificator naar informatie in de persistente 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 de issuer (uitgever), en het is meestal een reeks cijfers en/of tekens die de issuer helpt bepaalde informatie in een database op te halen en te identificeren. Hier is een voorbeeld van een opaque token:

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

Aan de andere kant is JWT een ander veelvoorkomend 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 beveiliging ervan — de aanwezigheid van de handtekening zorgt voor de integriteit van de inhoud van het token, waardoor er volledig vertrouwen is in de gegevens binnen de JWT.

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

Wat is JWT?

In tegenstelling tot opaque tokens is een JWT een zelfvoorzienend, 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 wordt gebruikt voor ondertekening. Bijvoorbeeld, {"alg": "HS256", "typ": "JWT"}.
Het payload gedeelte bevat claims — stukjes 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 authorization server kunnen verschillende claims in de payload worden opgenomen. Dit geeft het token zijn zelfvoorzienende 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 kunnen worden geverifieerd door de client of een service, zonder interactie met de authorization server. Dit maakt JWT’s bijzonder efficiënt voor gedistribueerde systemen, waar meerdere services mogelijk onafhankelijk de authenticiteit van het token moeten verifiëren.

Deze gemak brengt echter ook de verantwoordelijkheid met zich mee om ervoor te zorgen dat de claims van het token niet overmatig worden blootgesteld, omdat ze zichtbaar zijn voor iedereen die toegang heeft tot het token. Bovendien zijn JWT’s meestal van korte duur, en de vervaltijd is opgenomen in de claims van het token om ervoor te zorgen dat het token niet onbeperkt geldig is.

Validatie van opaque access token

Een opaque access token wordt gevalideerd door het terug te sturen naar de authorization server voor verificatie. De authorization server onderhoudt 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 het resource access verzoek met het opaque token in de header.
De resource provider stuurt een token introspectie verzoek naar de authorization server om het token te valideren.
De authorization server reageert met de tokeninformatie.

Validatie van JWT access token (offline)

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

De resource provider haalt vooraf de publieke sleutel van de authorization server op via de OpenID Connect (OIDC) Discovery . De publieke sleutel 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 het resource access verzoek met het JWT token in de header.
De resource provider decodeert en valideert het JWT token met behulp van de publieke sleutel verkregen van de authorization server.
De resource provider verleent toegang op basis van de geldigheid van het token.

Gebruiksscenario’s in OIDC

In de context van OIDC ( OpenID Connect (OIDC) ) 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 opneemt, geeft de authorization server een opaque access token uit. Dit token wordt voornamelijk gebruikt om gebruikersprofielinformatie op te halen van de 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 verifieert de geldigheid van het token voordat het reageert met de gebruikersprofielgegevens.

Refresh token uitwisseling:

Refresh tokens zijn ontworpen om alleen tussen de client en de authorization server te worden uitgewisseld, zonder dat ze met resource providers hoeven te worden gedeeld. Daarom worden refresh tokens meestal 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 wordt gegarandeerd zonder de gebruiker opnieuw te authenticeren.

JWT’s

ID token:

In OIDC is het ID token een JWT dat 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://auth.wiki>",
  "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 extraheren voor personalisatie of autorisatiedoeleinden. Het ID token is alleen voor eenmalig gebruik en mag niet worden gebruikt voor API resource autorisatie.

API resource toegang (met access token):

Wanneer een client een access token aanvraagt met een specifieke Resource-indicator , geeft de authorization server een JWT access token uit dat bedoeld is 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://auth.wiki>",
  "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 die aan het token is gekoppeld.
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)