(v0.2) 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

parameter	vulling	toelichting
`grant_type`	conform verantwoordelijkheid core.autorisatie.205, core.autorisatie.206, core.autorisatie.207 en core.autorisatie.208	Dit is het gevolg van verantwoordelijkheid core.autorisatie.201.
`code`	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.
`client_id`	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.
`redirect_uri`	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

parameter	vulling	toelichting
`grant_type`	conform verantwoordelijkheid core.autorisatie.205, core.autorisatie.206, core.autorisatie.207 en core.autorisatie.208	Dit is het gevolg van verantwoordelijkheid core.autorisatie.201.
`code`	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.
`client_id`	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.
`redirect_uri`	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

parameter	vulling	toelichting
`grant_type`	letterlijke waarde “refresh_token”	Conform hoofdstuk 6 van RFC6749
`refresh_token`	het uitgegeven refresh_token	Conform hoofdstuk 6 van RFC6749

Uitzonderingen:

oude tekst:

nieuwe tekst:

8

Na ontvangst van een access token request of een refresh request in de functies Verzamelen, zal de OAuth Authorization Server, indien in antwoord daarop een access token en refresh token dienen te worden uitgegeven, na maximaal tien (10) seconden dit acces token en refresh token ter beschikking stellen aan de OAuth Client. Bij het gebruik van een refresh request wordt het oude refresh-token ingetrokken en een nieuwe uitgegeven. Dit gedrag van de OAuth Authorization Server is gedurende minimaal 99,5% van de tijd beschikbaar.
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.

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