ID-tokens en claims

Een JWT bestaat uit drie delen, gescheiden door punten (.):

• Header: Beschrijft het type token en het ondertekeningsalgoritme.
• Payload: Bevat de daadwerkelijke "claims" (identiteitsinformatie).
• Handtekening: Wordt gebruikt om te verifiëren dat er niet met de token is geknoeid.

Zowel de Header als de Payload zijn als Base64Url gecodeerde JSON-objecten. De Signature wordt gemaakt met de gecodeerde Header, Payload en een geheime sleutel.

Voor identiteit is de Payload het belangrijkste deel van de ID Token. Dit is een JSON-object met verschillende verklaringen over de gebruiker en de authenticatiegebeurtenis.

Deze verklaringen worden claims genoemd. Elke claim is een sleutel-waarde-paar, zoals "name": "Jane Doe". Ze geven je applicatie specifieke gegevens over de gebruiker.

Claims zijn gestandaardiseerd door OIDC, maar kunnen ook aangepaste informatie bevatten, afhankelijk van de OpenID-provider (OP).

Bepaalde claims zijn essentieel om een ID Token geldig en bruikbaar te maken:

• iss (Issuer): Identificeert de entiteit die de token heeft uitgegeven. Dit is meestal de URL van de OpenID-provider.
• sub (Subject): Een unieke identificatie voor de eindgebruiker. Dit is meestal een tekenreeks die binnen het systeem van de issuer uniek is voor de gebruiker.
• aud (Audience): Identificeert de ontvanger(s) waarvoor de JWT bedoeld is. Dit moet de client_id van je applicatie zijn.

ID Tokens bevatten ook belangrijke tijdgerelateerde claims:

• exp (Expiration Time): Het tijdstip waarna de ID Token NIET MEER mag worden geaccepteerd. Dit is een Unix-tijdstempel.
• iat (Issued At Time): Het tijdstip waarop de ID Token is uitgegeven. Ook dit is een Unix-tijdstempel.
• auth_time (Authentication Time): Het tijdstip waarop de eindgebruiker zich voor het laatst heeft geauthenticeerd. Dit is nuttig voor beleidsregels voor sessiebeheer.

Controleer altijd exp om te controleren of de token nog geldig is!

De claim nonce is een unieke waarde die eenmalig wordt gebruikt. Je clientapplicatie genereert deze waarde en stuurt hem naar de autorisatieserver.

Wanneer de ID Token wordt teruggestuurd, bevat deze dezelfde nonce. Je applicatie controleert vervolgens of de nonce in de token overeenkomt met de waarde die is verzonden.

Dit helpt herhalingsaanvallen te beperken en zorgt ervoor dat de ID Token niet door een kwaadwillende partij is onderschept en opnieuw gebruikt.

Naast de kernclaims bevatten ID Tokens vaak aanvullende gebruikersinformatie, die bekendstaat als "User Profile Claims". Deze worden meestal opgevraagd via scopes.

Veelvoorkomende voorbeelden zijn:

• name: De volledige naam van de gebruiker.
• given_name: De voornaam van de gebruiker.
• family_name: De achternaam van de gebruiker.
• email: Het e-mailadres van de gebruiker.
• picture: Een URL naar de profielfoto van de gebruiker.

Deze claims bieden je applicatie een uitgebreide gegevensset.

Wanneer je een ID Token ontvangt en decodeert, kan de payload er ongeveer zo uitzien (vereenvoudigde JSON):

{
  "iss": "https://accounts.coddykit.com",
  "sub": "user_id_xyz_789",
  "aud": "my_mobile_app_123",
  "exp": 1678886400,
  "iat": 1678882800,
  "auth_time": 1678882700,
  "nonce": "a1b2c3d4e5",
  "name": "Coddy User",
  "email": "coddy.user@example.com"
}

Elk sleutel-waarde-paar is een specifieke claim die identiteitsgegevens bevat.

Goed gedaan! Je hebt de kern van OpenID Connect verkend: de ID Token en de bijbehorende claims.

• ID Tokens zijn JWT's die identiteitsgegevens bevatten.
• Ze bevatten een Header, Payload (claims) en Signature.
• Belangrijke claims zoals iss, sub, aud, exp, iat en nonce zijn essentieel.
• User Profile Claims zoals name en email verrijken de identiteit.

Vervolgens gaan we dieper in op de verschillende OIDC-flows die deze tokens gebruiken!