De authorization interface hoort bij de hoofdfunctie Regie.

Op deze pagina staan alleen de verantwoordelijkheden inzake de authorization interface die nog niet genoemd staan in de OAuth 2-specificatie.

1

De OAuth Client voegt bij het versturen van een Authorization request twee HTTP Header Fields toe, de eerste met de naam MedMij-Request-ID, de tweede met de naam X-Correlation-ID. Het MedMij-Request-ID moet een willekeurige waarde bevatten en dient uniek te zijn voor ieder request binnen het MedMij netwerk. De waarde bestaat uit een UUID. Het X-Correlation-ID moet een willekeurige waarde bevatten en dient uniek te zijn voor ieder authorization request binnen het MedMij netwerk. De waarde bestaat uit een UUID.

core.authint.208

2

De parameters in de authorization request worden als volgt gevuld:

parameter	vulling	toelichting
`response_type`	letterlijke waarde `code`	Dit is het gevolg van verantwoordelijkheid core.autorisatie.201.
`client_id`	de hostname, die in de OAuth Client List is opgenomen, van de Node van de OAuth Client die de authorization request doet
`redirect_uri`	zodanig dat de erin opgenomen hostname gelijk is aan de `client_id` en er geen poortnummer is opgenomen de `redirect_uri` moet volledig zijn en verwijzen naar een `https`-beschermd endpoint de redirect_uri moet urlencoded zijn (conform RFC 3986)	Zie verantwoordelijkheden core.adressering.200, core.adressering.201 en core.adressering.202. De tweede eis is een maatregel tegen beveiligingsrisico's 4.1.5, 4.2.4, 4.4.1.1, 4.4.1.5 en 4.4.1.6 in RFC 6819. Zie bovendien (v3.0.1) Token interface, de toelichting onder verantwoordelijkheid 4.
`scope`	Voor "verzamelen": MedMij-naam van de Aanbieder Voor "delen": één aanbieder-gegevensdienst-combinatie. Een aanbieder-gegevensdienst-combinatie bestaat uit: één Aanbiedernaam, ontdaan van de suffix `@medmij` gevolgd door een tilde (`~`) gevolgd door één GegevensdienstId van een Gegevensdienst uit de Gegevensdienstnamenlijst.	Er worden geen andere scopes of onderdelen van scopes opgenomen dan de genoemde. Voorbeelden van syntactisch juiste scopes zijn: Verzamelen: `"eenofanderezorgaanbieder"`, voor het uitwisselen van gegevens met `eenofanderezorgaanbieder@medmij`; Delen: `"eenofanderezorgaanbieder~53"`, voor het eenmalig afnemen van Gegevensdienst `53` bij `eenofanderezorgaanbieder@medmij`; `"eenofanderezorgaanbieder~53 eenofanderezorgaanbieder~57`, voor het eenmalig afnemen van Gegevensdiensten `53 en 57` bij `eenofanderezorgaanbieder@medmij.`
`state`	conform sectie 4.1.1. van RFC 6749.	Hiermee geeft de OAuth Client informatie mee aan de OAuth Authorization Server, waaraan eerstgenoemde later, bij de redirect, kan afleiden bij welk verzoek de authorization code hoort. Deze informatie is verder betekenisloos voor de OAuth Authorization Server. De state MOET een minimale lengte hebben van 128 karakters (Voldoende lang om niet raadbaar te zijn). een maximale lengte hebben van 512 karakters (Praktische grens, rekening houdend met standaard libraries en maximale lengte uri's).

Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden.

core.authint.200

3

De OAuth Client zorgt ervoor dat voor het authorization request de http-methode GET wordt gebruikt, niet POST.

Toelichting

In de OAuth-specificatie, sectie 3.1 wordt de OAuth Authorization Server verplicht gesteld GET te accepteren en wordt POST optioneel gehouden. Omdat GET de verreweg meest in het MedMij Afsprakenstelsel passende http-methode is voor de authorization request, geldt, om de OAuth Authorization Server niet voor onnodige implementatiekosten te plaatsen, deze verantwoordelijkheid. Hoewel deze verantwoordelijkheid een verantwoordelijkheid van de OAuth Client is, omdat deze onder de verantwoordelijkheid van een MedMij-deelnemer valt, wordt de request uiteindelijk door de User Agent uitgevoerd.

core.authint.201

4

Na ontvangst van een authorization request verifieert de Authorization Server dat:

de betreffende client_id voorkomt op de OAuth Client List;
de redirect_uri geldig is en voorkomt bij de betreffende client_id op de OAuth Client List.

Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1a volgens verantwoordelijkheid core.authint.207.

core.authint.202

5

Vervolgens verifieert de Authorization Server dat:

bij de functie Verzamelen:
- zij namens deze Aanbieder, voor de gehanteerde Interfaceversie, Gegevensdienst(en) ontsluit, in overeenstemming met de gepubliceerde Aanbiederslijst;
bij de functie Delen:
- alle gevraagde GegevensdienstId's voorkomen op de OAuth Client List, bij de betreffende client_id en voor de gehanteerde Interfaceversie;
- indien in de scope meerdere GegevensdienstId's zijn opgenomen:
  - alle Gegevensdiensten betrekking hebben op de functie Delen;
  - de hostnames van de AuthorizationEndpoints, waarop de Gegevensdiensten worden aangeboden, met elkaar overeenkomen;
  - de hostnames van de TokenEndpoints, waarop de Gegevensdiensten worden aangeboden, met elkaar overeenkomen.

Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid core.authint.207.

Toelichting

Zo voorkomt de Authorization Server dat gevolg wordt gegeven aan een verzoek dat blijkens de OAuth Client List of Aanbiederslijst niet is toegestaan.

core.authint.203

6

Tijdens de afhandeling van een authorization request laat de Authorization Server, in zijn rol als Authentication Client, voordat hij de Persoon om OAuth-autorisatie vraagt, de Persoon authenticeren door de Authentication Server.

Toelichting

Conform stroomdiagram onder 1. De Aanbieder in het Aanbiedersdomein, en dus BSN-domein, is verplicht bij het verstrekken van gegevens vanuit een gezondheidsdossier de identiteit van de persoon te verifiëren aan de hand van het BSN.

Het MedMij Afsprakenstelsel brengt het gebruik van de Authentication Server onder in de OAuth-flow, onder operationele verantwoordelijkheid van de Authorization Server. Laatstgenoemde handelt in dezen onder verantwoordelijkheid van individuele Aanbieders, want die zijn het waarvoor de Persoon zich authenticeert.

De directe interactie van de Persoon met de Authorization Server is bedoeld om de DVP Server te autoriseren om de Resource Server aan te spreken. Die levert de uiteindelijke Gegevensdienst pas.

core.authint.204

7

Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid core.authint.204, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Persoon om een Toestemmingsverklaring (in het geval van Verzamelen) of een Bevestigingsverklaring (in het geval van (v3.0.1) Delen), volgens het daaromtrent bepaalde op de pagina User interface (Autorisatieserver), volgens de standaard OAuth 2.0, op de wijze waarop deze in het MedMij Afsprakenstelsel wordt toegepast.

core.authint.205

8

Voorafgaand aan uitgifte van een authorization code via de in de authorization request opgenomen redirect_uri, administreert de OAuth Authorization Server die authorization code en de daarvoor gebruikte redirect_uri.

Toelichting

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.3, 4.4.1.5 en 4.4.1.7 uit RFC 6819 (zie verantwoordelijkheid core.beveiliging.205). Zie ook verantwoordelijkheid core.tknint.206.

core.authint.206

9

Authorization Server en DVP Server behandelen uitzonderingssituaties inzake het authorization interface af volgens onderstaande tabel.

Nummer	Implementeert uitzonderingen	Uitzondering	Actie	Melding	Vervolg
Authorization interface 1a	Verzamelen 1 Delen 1	Authorization Server ontvangt een authorization request zonder (geldige) `redirect_uri` en/of zonder een (geldige) `client_id`.	Authorization Server informeert de Persoon over de technische fout, zonder de Persoon automatisch te redirecten.	conform OAuth 2.0-RFC 6749, par. 4.1.2.1	Allen stoppen de flow van de functies Verzamelen/Delen onmiddellijk nadat de Persoon geïnformeerd is over de uitzondering.
Authorization interface 1b	Verzamelen 1 Delen 1	Authorization Server ontvangt een ongeldige authorization request, anders dan uitzondering 1.	Authorization Server informeert DVP Server over de technische fout. DVP Server informeert Persoon.	conform OAuth 2.0-specificatie, par. 4.1.2.1, met de daar genoemde HTTP 302 'invalid_request'.
Authorization interface 2	Authenticeren 1	Authorization Server kan de identiteit van de Persoon niet vaststellen.	Authorization Server informeert de Persoon dat diens verzoek geen voortgang kan vinden en noemt daarbij behorende reden.
Authorization interface 3	Autoriseren 1 Verzamelen 2	Authorization Server stelt tijdens de afhandeling van de authorization request vast dat: in geval van de functie (v3.0.1) Verzamelen: van Persoon bij Aanbieder voor geen van de gevraagde Gegevensdiensten gezondheidsinformatie beschikbaar is; in geval van de functie (v3.0.1) Delen: Aanbieder niet ontvankelijk is voor die Gegevensdienst van Persoon; Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.
Authorization interface 4	Autoriseren 2	De autorisatievraag wordt ontkennend beantwoord.	Authorization Server informeert DVP Server over deze uitzondering. DVP Server informeert daarop Persoon hierover.	conform OAuth 2.0-specificatie, par. 4.1.2.1, error `access denied`, met in de error description "`Access denied`."
Authorization interface 5	Autoriseren 3	Authorization Server kan de autorisatie niet vaststellen.		conform OAuth 2.0-specificatie, par. 4.1.2.1, error code `access denied`, met in de error description "`Authorization failed.`"

Toelichting

De uitzonderingssituaties kunnen gezien worden als de implementatie-tegenhangers van de uitzonderingen van de functies (v3.0.1) Verzamelen en (v3.0.1) Delen. Op de Applicatielaag zijn deze echter per interface geordend. Alle uitzonderingen worden door de Authorization Server ontdekt. In deze versie van het MedMij Afsprakenstelsel is bepaald dat zij altijd leiden tot het zo snel mogelijk afbreken van de flow door alle betrokken rollen. Daartoe moeten echter eerst nog de andere rollen geïnformeerd worden. Om te voorkomen dat de DVP Server informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven, moet het onderscheid tussen de uitzonderingen 2, 3 en 4 niet te maken zijn door de DVP Server.

Deze tabel bevat alleen die uitzonderingssituaties ten aanzien waarvan het MedMij afsprakenstelsel eigen eisen stelt aan de implementatie. In de specificatie van OAuth 2.0 staan daarnaast nog generiekere uitzonderingssituaties, zoals de situatie waarin de redirect URI ongeldig blijkt. Ook deze uitzonderingssituaties moeten geïmplementeerd worden.

core.authint.207

Browser not supported