Skip to main content
Skip table of contents

Authenticeren


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. 

nr.uitzonderingactievervolg
Authenticeren 1Dienstverlener aanbieder kan de identiteit van de Persoon niet vaststellen.Dienstverlener aanbieder informeert persoon dat verzoek niet wordt ingewilligd.

Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.

Authenticeren 2Persoon annuleert het inloggen.Dienstverlener aanbieder presenteert een annuleringspagina met de melding waaruit op te maken valt dat het authenticatieproces is afgebroken door de Persoon en biedt Persoon de optie om toch in te loggen.Indien Persoon kiest niet in te willen loggen, kan het scherm gesloten worden. Hiermee wordt de flow gestopt. Persoon kan er ook voor kiezen toch in te loggen. In dat geval vraagt Dienstverlener aanbieder weer om credentials.

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.

  2. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  3. De DVAuthn toont de Persoon een inlogpagina voor de authenticatie.

  4. De Authorization Server vraagt de Persoon via zijn User Agent om credentials.
  5. 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.
  6. De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.
  7. 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.
  8. Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.


JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.