MMOS-67 - core.tknint.200 aanvullen met het gebruik van een refresh token
Probleem: core.tknint.200 beschrijft nog alleen het gebruik van een code en moet ook de beschrijving gaan bevatten van het gebruik van een refresh token.
Huidige tekst:
De parameters in de access token request worden als volgt gevuld:
parameter | vulling | toelichting |
---|---|---|
| conform verantwoordelijkheid core.autorisatie.205, core.autorisatie.206, core.autorisatie.207 en core.autorisatie.208 | Dit is het gevolg van verantwoordelijkheid core.autorisatie.201. |
| conform verantwoordelijkheid core.autorisatie.205, core.autorisatie.206, core.autorisatie.207 en core.autorisatie.208 | Zie de toelichting bij verantwoordelijkheid core.autorisatie.205, core.autorisatie.206, core.autorisatie.207 en core.autorisatie.208. |
| de hostname van de Node van de OAuth Client die de authorization request deed die de nu aangeboden authorization code opleverde | Het gebruik van client_id is verplicht. Conform de verantwoordelijkheden als beschreven in het hoofdstuk TLS en certificaten moet al het netwerk-verkeer beveiligd worden met TLS. In hoofdstuk 2 van RFC8705 staat beschreven aan welke eisen voldaan moet worden bij een combinatie van OAuth2 en mutual TLS. |
| dezelfde waarde als in de voorafgaande authorization request. De redirect_uri moet urlencoded zijn (conform RFC 3986). | NB: De redirect_uri MOET NIET dubbel encoded worden(!) |
Nieuwe tekst (nieuwe eis toevoegen):
De parameters in de access- token request naar het token endpoint worden bij het gebruik van een authorization code (token request) als volgt gevuld:
parameter | vulling | toelichting |
---|---|---|
| conform verantwoordelijkheid core.autorisatie.205, core.autorisatie.206, core.autorisatie.207 en core.autorisatie.208 | Dit is het gevolg van verantwoordelijkheid core.autorisatie.201. |
| conform verantwoordelijkheid core.autorisatie.205, core.autorisatie.206, core.autorisatie.207 en core.autorisatie.208 | Zie de toelichting bij verantwoordelijkheid core.autorisatie.205, core.autorisatie.206, core.autorisatie.207 en core.autorisatie.208. |
| de hostname van de Node van de OAuth Client die de authorization request deed die de nu aangeboden authorization code opleverde | Het gebruik van client_id is verplicht. Conform de verantwoordelijkheden als beschreven in het hoofdstuk TLS en certificaten moet al het netwerk-verkeer beveiligd worden met TLS. In hoofdstuk 2 van RFC8705 staat beschreven aan welke eisen voldaan moet worden bij een combinatie van OAuth2 en mutual TLS. |
| dezelfde waarde als in de voorafgaande authorization request. De redirect_uri moet urlencoded zijn (conform RFC 3986). | NB: De redirect_uri MOET NIET dubbel encoded worden(!) |
De parameters in de request naar het token endpoint worden bij het gebruik van een refresh token (refresh request) als volgt gevuld:
parameter | vulling | toelichting |
---|---|---|
| letterlijke waarde “refresh_token” | Conform hoofdstuk 6 van RFC6749 |
| het uitgegeven refresh_token | Conform hoofdstuk 6 van RFC6749 |
Uitzonderingen:
oude tekst:
nieuwe tekst:
8 |
| core.tknint.206 |
9 | OAuth Authorization Server en OAuth Client behandelen uitzonderingssituaties inzake het token interface volgens onderstaande tabel. | ||||||
---|---|---|---|---|---|---|---|
Nummer | Implementeert uitzondering | Uitzondering | Actie | Melding | Vervolg | ||
Token interface 1 | Verzamelen 3 Delen 2 | Authorization Server moet vanwege één van de in de OAuth 2.0-specificatie, par. 5.2, genoemde redenen de (acces of refresh) token request weigeren. | Authorization Server informeert DVP Server over deze uitzondering. DVP Server informeert daarop Persoon hierover. | met de conform OAuth 2.0-specificatie, par. 5.2, toepasselijke error code | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. | core.tknint.207 |
>Toelichting