1. | De parameters in de access token request worden als volgt gevuld: Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden. | Anchor |
---|
| core.tknint.200 |
---|
| core.tknint.200 |
---|
| core.tknint.200
|
2. | De parameters in de access token response worden als volgt gevuld: parameter | vulling | toelichting |
---|
access_token | Het hiermee uitgegeven access token. |
| token_type | letterlijke waarde "Bearer" |
| expires_in
| 900 | Conform verantwoordelijkheid core.autorisatie.204 | refresh_token
| niet gebruikt | Conform verantwoordelijkheid core.autorisatie.204
| scope | Conform sectie 5.1 van de OAuth 2.0-specificatie. In toevoeging daarop: verplicht indien het authorization request verzocht om Verzamelen van meerdere Gegevensdiensten en hiervan niet alle Gegevensdiensten beschikbaar bleken voor Persoon. In dat geval is de scope -parameter gelijk aan die in de betreffende authorization request, met daaruit weggelaten de niet-beschikbare aanbieder-gegevensdienst-combinaties. |
|
| Anchor |
---|
| core.tknint.201 |
---|
| core.tknint.201 |
---|
| core.tknint.201
|
3. | De OAuth Client biedt een, via de in de authorization request opgenomen redirect_uri ontvangen authorization code, slechts aan de Authorization Server aan indien:- de waarde van de, in de authorization response ontvangen, state overeenkomt met de door de OAuth Client zelf gegenereerde state, die werd verzonden in het authorization request.
| Anchor |
---|
| core.tknint.202 |
---|
| core.tknint.202 |
---|
| core.tknint.202
|
4. | De OAuth Client biedt een zekere authorization code maximaal eenmaal aan aan de Authorization Server. | Anchor |
---|
| core.tknint.203 |
---|
| core.tknint.203 |
---|
| core.tknint.203
|
5. | De Authorization Server voert een authorization code af, wanneer het eenmaal door een OAuth Client is aangeboden.
Expand |
---|
| Dit is een maatregel tegen beveiligingsrisico 4.1.1 uit RFC 6819 (zie toelichting bij verantwoordelijkheden core.beveiliging.202, core.beveiliging.203, core.beveiliging.204). Het afvoeren van een authorization code houdt in dat de Authorization Server van een eenmaal uitgegeven authorization code bijhoudt of die al eens gebruikt is voor het verkrijgen van een access token. Mocht een authorization code voor een tweede of volgende keer worden aangeboden ter verkrijging van een access token, dan zal de Authorization Server dat weigeren en de flow afbreken. Als de Client aan wie die geweigerd wordt te kwader trouw was, is hiermee een gevaar afgewend. Was hij wel te goeder trouw en handelde hij conform het MedMij Afsprakenstelsel, dan was hij niet degene die al eerder dezelfde authorization code aanbood en blijkt er dus sprake geweest te zijn van een security breach. |
| Anchor |
---|
| core.tknint.204 |
---|
| core.tknint.204 |
---|
| core.tknint.204
|
6. | De OAuth Authorization Server draagt geen access token over als in de token request geen redirect_uri is opgenomen, en evenmin als er in de token request wel een redirect_uri is opgenomen, maar deze niet identiek is aan de redirect_uri die de OAuth Authorization Server, bij uitreiking, verbonden heeft aan de authorization code die in de token request wordt aangeboden. Expand |
---|
| 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). Met het oog op de parameters client_id en redirect_uri in de authorization request en de access token request geldt dat: - de client_id in de authorization request overeen moet komen met de hostname van de redirect_uri in diezelfde authorization request (verantwoordelijkheid 1 bij Authorization interface);
- de redirect_uri in de access token request overeen moet komen met de redirect_uri in de authorization request (deze verantwoordelijkheid).
In de access token request speelt de redirect_uri dan niet de rol van adressering van de response, zoals in de authorization request wel, maar enkel als terugverwijzing naar de redirect_uri van het Authorization interface. Bij de afhandeling van het Token interface wordt helemaal niet geredirect; die speelt zich geheel op het backchannel af. |
| Anchor |
---|
| core.tknint.205 |
---|
| core.tknint.205 |
---|
| core.tknint.205
|
7. | Na ontvangst van een access token request, in de functies Verzamelen of Delen, zal de OAuth Authorization Server, indien in antwoord daarop een access token dient te worden uitgegeven, na maximaal tien (10) seconden dit acces token ter beschikking stellen aan de OAuth Client. Dit gedrag van de OAuth Authorization Server is gedurende minimaal 99,5% van de tijd beschikbaar. | Anchor |
---|
| core.tknint.206 |
---|
| core.tknint.206 |
---|
| core.tknint.206
|
8. | OAuth Authorization Server en OAuth Client behandelen uitzonderingssituaties inzake het token interface volgens onderstaande tabel.
Expand |
---|
| De uitzonderingssituaties kunnen gezien worden als de implementatie-tegenhangers van de uitzonderingen van de functies Verzamelen en de 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. 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.tknint.207 |
---|
| core.tknint.207 |
---|
| core.tknint.207
|