Scopes & claims

Bij het Authenticatie verzoek stuurt de Client de gewenste scopes mee en de ACM IDP voorziet de voorziene claims voor deze scope in het ID-token

Het gebruik van de scope “openid” bij het Authenticatie verzoek is verplicht voor een OpenID Connect authenticatie.

Welke scopes en claims aan een Client toegekend kunnen worden, kan zeer grannulair bepaald worden bij de ACM IDP. Welke specifieke scopes voor de Client mogelijk zijn, kan dus niet weergegeven worden in de Discovery URL die publieke info bevat voor alle Clients.

Het opvragen van een scope die niet toegestaan is voor deze Client zal ervoor zorgen dat het Authenticatie Request meteen negatief beantwoord zal worden (zonder dat de gebruiker zich dient te authenticeren in ACM).

Voorbeelden:

scope claim Omschrijving
openid sub PersoonsID van de gebruiker (= unieke identifier binnen ACM die deze gebruiker identificeert)
profile given_name voornaam van de gebruiker
profile family_name naam van de gebruiker
rrn rrn rijksregisternummer van de gebruiker
vo vo_id unieke VO IDM ID van de gebruiker
vo vo_doelgroepcode de code van de doelgroep (GID, EA, LB, OV, BUR)
vo vo_orgcode de code van de gekozen organisatie (KBO-nummer, OVO-code, OV-instellingsnummer)
vo vo_orgnaam de naam van de gekozen organisatie
wettelijkvertegenwoordiger wv_orgcode gekozen organisatie als wettelijk vertegenwoordiger
mijntoepassing mijntoepassing_rol_3d WebIDM 3D-rol van de gebruiker voor deze toepassing
ssm_mandaat ssm_mandaatgever organisatiecode van de SSM-mandaatgever

setbyapi

Een API heeft de mogelijkheid om een claim te koppelen op een specifieke client. Wanneer de API een token, dat door die client werd aangevraagd, ontvangt zullen deze claims zichtbaar worden voor de API bij introspectie van dat token (zie valideer Access Token).

Deze claims zullen steeds beginnen met de naam setbyapi_ en zijn niet zichtbaar voor de client zelf. Het zijn dus als het ware claims van de client, die door de API werden gedefinieerd in het beheerportaal.

API gateways

Deze attributen worden gekoppeld op de relatie tussen een API en zijn client. Het systeem herkent beide partijen aan de hand van de authenticatie op het introspection endpoint (= de API) enerzijds en de client waaraan het token werd afgeleverd (= de client) anderzijds.

In een scenario waarbij een API gateway gebruikt wordt, zal de API gateway echter de introspectie van het token uitvoeren en is het niet mogelijk om de relatie tussen de de client en de api niet langer te identificeren op basis van de authenticatie van op het introspection endpoint. Voor dergelijke usecases kan een API gateway een request header X-Forwarded-Audience toevoegen met als waarde de client_id van de API of een resource_uri die aan de API werd gekoppeld.