(MedMij Afsprakenstelsel 2.2.1) Token interface
Controle van door DVP ondersteunde gegevensdiensten bij uitgeven van access-tokens
Gewijzigde pagina’s:
Authorization interface
Token interface
Eerder werd op de authorization interface gecontroleerd of de gegevensdiensten die in de scope stonden ook op de OCL aanwezig waren. Doordat de gegevensdiensten niet langer worden opgenomen in de scope was het niet mogelijk deze te verifiëren aan de OCL. Met deze wijziging is deze verificatie verplichting uit de authorization interface gehaald en in andere vorm opgenomen in de token interface.
Op deze pagina staan alleen de verantwoordelijkheden inzake het token interface die nog niet genoemd staan in de OAuth 2-specificatie.
1 | De OAuth Client voegt bij het versturen van een Token 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 heeft dezelfde waarde als het veld X -Correlation-ID dat bij het Authorization request is gebruikt, of indien gebruikgemaakt wordt van langdurige toestemming een nieuw unieke UUID. | core.tknint.208 | ||||||||||||||||||
2 | De parameters in het request naar het token endpoint worden bij het gebruik van een authorization code (token request) als volgt gevuld:
Het onderstaande voorbeeld dient als toelichting hoe het token request opgevuld zou moeten worden: Token interface TYPE REQUEST: POST https://authorization-server.com/token?grant_type=authorization_code &code=jhgRtYbFpO12D3qR5tU9 &client_id= medmij.deenigeechtepgo.nl &redirect_uri= https://medmij.deenigeechtepgo.nl CUSTOM HEADERS: X-Correlation-ID: c0e7b545-9606-4eef-bea7-75d8addaa54b MedMij-Request-ID: 57510be1-73e6-4a75-9db8-ee005cced48f Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden. | core.tknint.200 | ||||||||||||||||||
3 | De parameters in het request naar het token endpoint worden bij het gebruik van een refresh token (refresh request) als volgt gevuld:
Het onderstaande voorbeeld dient als toelichting hoe het token request opgevuld zou moeten worden indien er gebruik wordt gemaakt van een refresh token: Token interface TYPE REQUEST: POST https://authorization-server.com/token?grant_type=refresh_token &refresh_token=tGzv3JOkF0XG5Qx2TlKWIA &client_id= medmij.deenigeechtepgo.nl CUSTOM HEADERS: X-Correlation-ID: c0e7b545-9606-4eef-bea7-75d8addaa54b MedMij-Request-ID: 57510be1-73e6-4a75-9db8-ee005cced48f Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden. |
core.tknint.209 | ||||||||||||||||||
4 | De parameters in de access token response worden als volgt gevuld:
Het onderstaande voorbeeld dient als toelichting hoe het token response opgevuld zou moeten worden: { "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "token_type": "Bearer", "expires_in": 900, "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA", "scope": "51 52" } | core.tknint.201 | ||||||||||||||||||
5 | Voor het bepalen van de scope van het access-token verifieert de Authorization Server:
Als een verificatie niet slaagt, wordt een gegevensdienst niet toegevoegd aan de scope van het access-token. |
core.tknint.210 | ||||||||||||||||||
6 | De OAuth Client biedt een, via de in de authorization request opgenomen redirect_uri ontvangen authorization code, slechts aan de Authorization Server aan indien:
| core.tknint.202 | ||||||||||||||||||
7 | De OAuth Client biedt een zekere authorization code maximaal eenmaal aan aan de Authorization Server. | core.tknint.203 | ||||||||||||||||||
8 | De Authorization Server voert een authorization code af, wanneer het eenmaal door een OAuth Client is aangeboden. | core.tknint.204 | ||||||||||||||||||
9 | 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. Bij het inwisselen van een refresh token voor een access token wordt de parameter redirect_uri niet gebruikt. | core.tknint.205 | ||||||||||||||||||
10 |
| core.tknint.206 | ||||||||||||||||||
11 | OAuth Authorization Server en OAuth Client behandelen uitzonderingssituaties inzake het token interface volgens onderstaande tabel.
| core.tknint.207 |