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
`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
`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
`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 ~~Verzamele~~~~n 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