Switch identiteit
De werkwijze om een “switch identiteit” aan te vragen is vrijwel identiek aan een login. Het volstaat om een login te doen en een extra parameter mee te geven die aangeeft dat de gebruiker een switch van identiteit wil doen. Wanneer de gebruiker nog een actieve sessie heeft, zal deze niet opnieuw moeten inloggen. Het systeem weet in dat geval nog wie je bent, en zal de gebruiker laten kiezen uit de identiteiten die toegang geven tot de toepassing waar je op wil aanloggen. Indien slechts één identiteit toegang heeft, zal de gebruiker geen interactieve keuze moeten doen, maar kiest het systeem de enige optie.
Indien de gebruiker geen actieve sessie meer heeft op het Vlaams toegangsbeheer zal voor de keuze van de identiteit aangemeld moeten worden. De gebruikerservaring is in dat geval identiek aan de gebruikerservaring bij een “gewone aanmelding”.
- doe een lokale logout op de toepassing (om geen verwarring te krijgen met de identiteit in de huidige sessie in de toepassing)
- start een nieuwe authenticatie met de extra request parameter login_hint met als waarde eyJzd2l0Y2hfaWQiOiB0cnVlfQ== (dit geeft aan dat je wil wisselen van identiteit.
Volgende parameters dienen als query-parameters meegegeven te worden:
| Parameter | Omschrijving | |
|---|---|---|
| login_hint | VERPLICHT | De waarde eyJzd2l0Y2hfaWQiOiB0cnVlfQ== geeft aan dat je wil wisselen van identiteit |
| client_id | VERPLICHT | de ClientID van de toepassing waarvoor de switch identiteit gevraagd werd |
| redirect_uri | VERPLICHT | redirect URI waarnaar de Authorization Code gestuurd zal worden: deze moet op voorhand gedefinieerd worden op de OpenID Connect Provider: deze wordt URL-encoded |
| response_type | VERPLICHT | geeft aan welke flow er gevolgd wordt en het gedrag voor het terugsturen van tokens: in ons geval MOET dit steeds “code” zijn |
| scope | VERPLICHT | de scope “openid” moet minimaal aanwezig zijn. Andere scope waarden zijn optioneel en enkel de claims die horen bij de aangevraagde scopes zullen uitgeleverd worden. Check het integratiedossier wat voorzien werd. Meerdere scopes worden door een spatie gescheiden en nadien URL-encoded |
| state | OPTIONEEL | AANBEVOLEN een waarde die de status bewaart tussen het request en de callback: dit kan enerzijds gebruikt worden als bescherming tegen Cross-Site Request Forgery (CSRF, XSRF): dit kan door de waarde van deze parameter cryptografisch te koppelen aan een browser cookie. Anderzijds kan dit gebruikt worden als een sessie-status: in dat geval zou dit dan een waarde moeten zijn waar niets uit op te maken is waarvan de integriteit door de toepassing gevalideerd kan worden. (bvb geen links of parameters gebruiken) |
| nonce | OPTIONEEL | AANBEVOLEN een waarde om een Client Sessie te koppelen aan het ID-token om “replay attacks” te mitigeren. De waarde die meegestuurd wordt in het Authenticatie Request wordt ongewijzigd terug gestuurd in het ID-token. Voorzie voldoende entropie voor deze waarde om te vermijden dat aanvallers de waarde kunnen raden |
| response_mode | OPTIONEEL | bepaalt de methode via de welke de Authorization Code teruggestuurd wordt: zie de details omtrent response_mode |
| acr_values | OPTIONEEL | de gevraagde “Authentication Context Class Reference” waarden: zie de details omtrent de authenticatiemiddelen |
| acr | OPTIONEEL | zorgt ervoor dat de geselecteerde “Authentication Context Class Reference” (zijnde de URN van het gekozen authenticatiemiddel) zal meegestuurd worden in de “acr” claim van het ID-token: zie de details omtrent de authenticatiemiddelen |
De gebruiker wordt in de ACM IDP enkel afgemeld voor die ene toepassing, maar hij hoeft zich niet meer opnieuw binnen ACM te authenticeren.
Voorbeeld:
GET /op/v1/auth?
client_id=28358814-5c20-4c13-bbff-db5dd8c4ae93&
redirect_uri=https%3A%2F%2Fmijntoepassing.vlaanderen.be%2Fcallback&
response_type=code&
scope=openid%20vo%20profile&
state=Fheue34eg2hjsdehfk839ed83azz&
nonce=FJEkzudnsiz34kzlDzl82pzod21sjsy922jdSaq&
login_hint=eyJzd2l0Y2hfaWQiOiB0cnVlfQ==
Host: authenticatie.vlaanderen.be