| 1. | 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 Token interface, de toelichting onder verantwoordelijkheid 4. | scope
| Voor "verzamelen": - één of meerdere, door een enkele spatie van elkaar gescheiden, aanbieder-gegevensdienst-combinaties, waarbij de Aanbiedernaam telkens dezelfde moet zijn.
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: "eenofanderezorgaanbieder~42", voor het eenmalig afnemen van Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij;"eenofanderezorgaanbieder~42 eenofanderezorgaanbieder~48", voor het eenmalig afnemen van Gegevensdiensten 42 en 48 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. | | Anchor |
|---|
| core.authint.200 |
|---|
| core.authint.200 |
|---|
|
core.authint.200
|
| 2. | 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
|
| 3. | 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 v.2 Authorization interface < Interfaces, Core core.authint.207. | | Anchor |
|---|
| core.authint.202 |
|---|
| core.authint.202 |
|---|
|
core.authint.202
|
| 4. | Vervolgens verifieert de Authorization Server dat: - alle gevraagde GegevensdienstId's voorkomen op de OAuth Client List, bij de betreffende
client_id en voor de gehanteerde Interfaceversie; - zij namens deze Aanbieder, voor de gehanteerde Interfaceversie, deze Gegevensdienst(en) ontsluit, in overeenstemming met de gepubliceerde Aanbiederslijst;
- indien in de scope meerdere GegevensdienstId's zijn opgenomen:
- alle Gegevensdiensten betrekking hebben op de functie Verzamelen;
- 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 v.2 Authorization interface < Interfaces, Core 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
|
| 5. | Tijdens de afhandeling van een authorization request laat de Authorization Server, in zijn rol als Authorization 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
|
| 6. | Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid v.2 Authorization interface < Interfaces, Core 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 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
|
| 7. | 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
|
| 8. | 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 User Agent over deze uitzondering. Authorization Server voert geen redirect naar de Client uit, ook niet met een foutmelding. 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 na geïnformeerd te zijn 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 deze uitzondering. DVP Server informeert Persoon daarover.
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, zo specifiek mogelijke, toepasselijke error code HTTP 302 'invalid_request'
| | Authorization interface 2 | Authenticeren 1 | Authorization Server kan de identiteit van de Persoon niet vaststellen. | Authorization Server informeert DVP Server over deze uitzondering. DVP Server informeert Persoon dat diens verzoek geen voortgang kan vinden, maar laat de oorzaak daarvan helemaal in het midden.
Authorization Server informeert de Persoon dat diens verzoek geen voortgang kan vinden en noemt daarbij behorende reden. | conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Access denied."
| | Authorization interface 3 | Autoriseren 1
Verzamelen 2 | Authorization Server stelt tijdens de afhandeling van de authorization request vast dat: - in geval van de functie Verzamelen: van Persoon bij Aanbieder voor geen van de gevraagde Gegevensdiensten gezondheidsinformatie beschikbaar is;
- in geval van de functie 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 Persoon dat diens verzoek geen voortgang kan vinden, maar laat de oorzaak daarvan helemaal in het midden. | conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Access denied." | | Authorization interface 5 | Autoriseren 3 | Authorization Server kan de autorisatie niet vaststellen. | Authorization Server informeert DVP Server over deze uitzondering. DVP Serverinformeert daarop Persoon hierover. | 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 Verzamelen en 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
|
