Disclaimer: Deze pagina’s worden regelmatig bijgewerkt zodat ze altijd de meeste recente informatie bevatten. Aarzel niet om feedback te geven mochten er aanpassingen nodig zijn.
Vanuit Mijn Burgerprofiel maken we gebruik van het Vlaams Toegangsbeheer om authenticatie te faciliteren. Deze component voorziet automatisch single sign-on functionaliteit zodat een burger zich niet telkens opnieuw moet aanmelden in verschillende applicaties.
Deze functionaliteit is gebonden aan enkele beperkingen:
SSO heeft een beperkte levensduur;
Aanmelden moet gebeuren in dezelfde browser instantie;
Geen garantie dat gebruiker context bewaart blijft tussen verschillende applicaties;
Single Sign-on via token
Gebruik maken van deze functionaliteit is enkel mogelijk indien de te koppelen applicatie beschikt over een OpenID Connect integratie met het Vlaams Toegangsbeheer.
Om een aantal beperkingen op te lossen rond de klassieke manier waarop Single Sign-on werkt maken we gebruiken van Token Exchange om een OAuth Access Token te generen die gebruikt kan worden door Mijn Burgerprofiel applicatie om een sessie op te starten.
Vereisten
Applicatie dient een trust aan te vragen voor de Mijn Burgerprofiel Client ID (zie Bijlage - Mijn Burgerprofiel Client ID);
Applicatie beschikt over ondersteuning voor Token Exchange grant type;
Applicatie beschikt over ondersteuning voor Client Credential grant type;
Implementatie
Single Sign-on vanuit een applicatie begint door het verkrijgen van een OpenID Connect Access Token (hierna afgekort als OIDC Access Token) via de authorization code grant. Eenmaal de applicatie beschikt over een OIDC Access Token kan de uitwisseling via Token Exchange beginnen om een OAuth Access Token te generen welke door Mijn Burgerprofiel applicatie verwerkt kan worden.
Opmerking: de maximum duur van de Mijn Burgerprofiel applicatieve sessie is gekoppeld aan de resterende tijdsduur van het OIDC Access Token. Om er voor te zorgen dat de user journey voor een gebruiker zo lang mogelijk is kan men best eerst een refresh uitvoeren.
Token Exchange
Eenmaal de applicatie beschikt over een OIDC Access Token kan er gestart worden om een OAuth Access Token te verkrijgen. Hiervoor maken we gebruik van delegatie volgens de Token Exchange RFC. Dit betekent dat men steeds subject en actor token moet meegeven tijdens de Token Exchange.
POST /op/v1/token HTTP/1.1 Host: authenticatie-ti.vlaanderen.be Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &audience=<MBP-CLIENT-ID> &subject_token=<OIDC-ACCESS-TOKEN> &subject_token_type=urn:ietf:params:oauth:token-type:access_token &actor_token=<OIDC-ACCESS-TOKEN> &actor_token_type=urn:ietf:params:oauth:token-type:access_token &client_id=<APP-CLIENT-ID> &client_secret=<APP-CLIENT-SECRET>
Naam | Beschrijving |
---|---|
<MBP-CLIENT-ID> | Bevat de Mijn Burgerprofiel Client ID (zie Bijlage - Mijn Burgerprofiel Client ID). |
<OIDC-ACCESS-TOKEN> | OpenID Connect Access Token verkregen door gebruik te maken van authorization code grant of via uitvoeren van refresh. |
<APP-CLIENT-ID> | Client ID van de applicatie (zie Client Authenticatie voor alternatieven). |
<APP-CLIENT-SECRET> | Client Secret van de applicatie (zie Client Authenticatie voor alternatieven). |
Opmerking: in ons code voorbeeld maken we gebruik van een Client ID en Secret. Echter kan deze informatie ook als Basic Authentication toegevoegd worden.
In geval van een asymmetrisch sleutelpaar dient men gebruik te maken van client assertion.
Zie documentatie Client Authenticatie voor meer informatie en voorbeelden.
Na het succesvol uitvoeren van de Token Exchange zal de applicatie onderstaand antwoord verkrijgen.
HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store { "issued_token_type":"urn:ietf:params:oauth:token-type:access_token", "access_token": "ZC5-A1AkXUzXRKb71sAIHBl9F87F18anzEaQy6G6KFD", "expires_in": 3600, "scope": "profile rrn", "token_type": "Bearer" }
Doorgeven van gebruikerscontext aan Mijn Burgerprofiel
Om gebruikercontext door te geven aan Mijn Burgerprofiel dient men het OAuth Access Token verkregen via voorgaande Token Exchange operatie door te geven. Gezien de gevoeligheid van het OAuth Access Token dient deze steeds via een server-to-server operatie te verlopen.
Opmerking: het tijdelijk token dat men verkrijgt via de API endpoint kan slecht eenmalig gebruikt worden. Daarnaast heeft deze ook een heel korte levensduur (ca 2 min) voordat het vervalt.
Als laatste dient men vervolgens het tijdelijk token door te geven als query parameters van de Mijn Burgerprofiel URL. Onderstaand alvast enkele voorbeelden van zo een URLs:
TNI:
https://burgerprofiel.tni-vlaanderen.be/?token=<MBP-TEMP-TOKEN>
https://burgerprofiel.tni-vlaanderen.be/meldingen?token=<MBP-TEMP-TOKEN>
Productie:
https://www.burgerprofiel.be/?token=<MBP-TEMP-TOKEN>
https://www.burgerprofiel.be/meldingen?token=<MBP-TEMP-TOKEN>
Bijlage - Mijn Burgerprofiel Client ID
Client ID | Omgeving | URL |
---|---|---|
80689076-8c4a-4bef-abc4-82805e17988d | TNI | |
88f04968-d331-4ae0-99d9-c6efb845841f | Productie |