| 1 | De OAuth Client voegt bij het versturen van een Authorization request twee HTTP query parameters 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. | | Anchor |
|---|
| core.authint.208 |
|---|
| core.authint.208 |
|---|
|
core.authint.208
|
| 2 | De onderstaande parameters in de authorization request zijn verplicht en moeten als volgt gevuld worden. | 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 (MedMij Afsprakenstelsel 2.1.0B) 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:
Delen: | 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).
|
Het onderstaande voorbeeld dient als toelichting hoe het authorization request opgevuld zou moeten worden in het geval van de functie Verzamelen: | Code Block |
|---|
| Authorisatie interface
TYPE REQUEST: GET
https://authorization-server.com/auth?response_type=code
&client_id= medmij.deenigeechtepgo.nl
&redirect_uri= https://medmij.deenigeechtepgo.nl
&scope=eenofanderezorgaanbieder
&state=xcoivjuywkdkhvusuye3kch
CUSTOM HEADERS:
X-Correlation-ID: c0e7b545-9606-4eef-bea7-75d8addaa54b
MedMij-Request-ID: 57510be1-73e6-4a75-9db8-ee005cced48f |
In het geval van de functie Delen verandert de scope naar: | Code Block |
|---|
| &scope=eenofanderezorgaanbieder~53 |
Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden. | | Anchor |
|---|
| core.authint.200 |
|---|
| core.authint.200 |
|---|
|
core.authint.200
|
| 3 | De OAuth Client zorgt ervoor dat voor het authorization request de http-methode GET wordt gebruikt, niet POST. | Expand |
|---|
| 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. |
| | Anchor |
|---|
| core.authint.201 |
|---|
| core.authint.201 |
|---|
|
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. | | Anchor |
|---|
| core.authint.202 |
|---|
| core.authint.202 |
|---|
|
core.authint.202
|
| 5 | Vervolgens verifieert de Authorization Server dat: Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid core.authint.207. | Expand |
|---|
| Zo voorkomt de Authorization Server dat gevolg wordt gegeven aan een verzoek dat blijkens de OAuth Client List of Aanbiederslijst niet is toegestaan. |
| | Anchor |
|---|
| core.authint.203 |
|---|
| core.authint.203 |
|---|
|
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. | Expand |
|---|
| 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. |
| | Anchor |
|---|
| core.authint.204 |
|---|
| core.authint.204 |
|---|
|
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 Persoonom een Toestemmingsverklaring (in het geval van Verzamelen) of een Bevestigingsverklaring (in het geval van (MedMij Afsprakenstelsel 2.1.0B) 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. | | Anchor |
|---|
| core.authint.205 |
|---|
| core.authint.205 |
|---|
|
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.
| | Anchor |
|---|
| core.authint.206 |
|---|
| core.authint.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 | 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: 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 Serverinformeert 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." |
| Expand |
|---|
| De uitzonderingssituaties kunnen gezien worden als de implementatie-tegenhangers van de uitzonderingen van de functies (MedMij Afsprakenstelsel 2.1.0B) Verzamelen en (MedMij Afsprakenstelsel 2.1.0B) 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. |
| | Anchor |
|---|
| core.authint.207 |
|---|
| core.authint.207 |
|---|
|
core.authint.207
|
