| Info | ||
|---|---|---|
| ||
Op deze pagina staan alleen de verantwoordelijkheden inzake het token interface die nog niet genoemd staan in de OAuth 2-specificatie. |
...
parameter | vulling | toelichting |
|---|---|---|
| letterlijke waarde "authorization_code" | Dit is het gevolg van verantwoordelijkheid 4 op de Applicatielaag. |
| conform verantwoordelijkheid 8a-d op de Applicatielaag | Zie de toelichting bij verantwoordelijkheid 8a-d op de Applicatielaag. |
| de hostname van de Node van de OAuth Client die de authorization request deed die de nu aangeboden authorization code opleverde | De OAuth 2.0-specificatie stelt deze parameter niet verplicht indien de OAuth Client zich authenticeert, hetgeen in het MedMij Afsprakenstelsel gebeurt door middel van mutual TLS. En de noodzaak van het gebruik ervan wordt beperkt door verantwoordelijkheid 4 op deze pagina, die borgt dat het access token alleen wordt verstrekt aan de OAuth Client aan wie de OAuth Resource Owner toestemming heeft verleend. In hoofdstuk 2 van een Internet-Draft ter zake wordt echter gesteld dat de |
| dezelfde waarde als in de voorafgaande authorization request |
...
| Info | ||
|---|---|---|
| ||
Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden. |
2. De parameters in de access token response worden als volgt gevuld:
...
| Info | ||
|---|---|---|
| ||
Dit is een maatregel tegen beveiligingsrisico's 4.4.1.3, 4.4.1.5 en 4.4.1.7 uit RFC 6819 (zie Applicatie-laag, verantwoordelijkheid 18). Met het oog op de parameters client_id en redirect_uri in de authorization request en de access token request geldt dat:
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 136414228 wordt helemaal niet geredirect; die speelt zich geheel op het backchannel af. |
...