Inleiding

Op deze pagina staan de diagrammen behorende bij de functie Authenticeren. De diagrammen tonen alleen de situatie waarin alle acties slagen tot en met dat de Persoon zich heeft laten authenticeren (de zogenaamde happy flow). De oranje banen horen (conform de MedMij-huisstijl) tot het Persoonsdomein, de blauwe tot het Aanbiedersdomein en de grijze tot externe domeinen.

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de genoemde rollen.

• De Dienstverlener aanbieder laat de Persoon zich authenticeren.
• Wanneer de Persoon de authenticatie heeft afgebroken toont de Dienstverlener aanbieder de Persoon een scherm met de melding dat het authenticatieproces is afgebroken door de Persoon. De Dienstverlener aanbieder biedt hierna de mogelijkheid alsnog te authentiseren of de flow af te breken.

Uitzonderingen op de Happy flow van de functie Authenticeren

In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbieder ontdekt. 

Applicatielaag

Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, waar de uitzonderingen bij de functies zijn genoemd.

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.

De flow kent de volgende stappen:

1. de  User Agent stuurt een authorization request naar de Authorization Server. Het adres van het authorization endpoint komt uit de  Aanbiederslijst. De redirect_uri geeft aan waarnaartoe de Authorization Server de User Agent verderop moet redirecten (met de authorization code). Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten.
   

   Toestemming voor meerdere Gegevensdiensten van een Aanbieder

   In een authorization request mogen meerdere Gegevensdiensten van eenzelfde Aanbieder worden gecombineerd wanneer:

   1. de gegevensdiensten worden aangeboden binnen één zelfde interfaceversie, EN
   2. de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen AuthorizationEndpoints met elkaar overeenkomen, EN
   3. de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen TokenEndpoints met elkaar overeenkomen.
2. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
3. De Authorization Server vraagt de Persoon via zijn User Agent om credentials.
4. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de User Agent naar de Authentication Server te redirecten, onder meegeven van een redirect_uri, die aangeeft waarnaartoe de Authentication Server straks de User Agent moet terugsturen, na het inloggen van de  Persoon.
5. De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.
6. Wanneer deze juist zijn, redirect de Authentication Server de User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken toont de Authorization Server de Persoon de melding waaruit op te maken valt dat het authenticatieproces is afgebroken en biedt het alsnog de mogelijkheid via zijn User Agent in te loggen.
7. Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.