MMOS-259, SR - Verheldering scope core.tknint.201
- Ibrahim Benyahya
Omschrijving Changelog, met daarin:
| Verheldering scope core.tknint.201 https://afsprakenstelsel.medmij.nl/asoptioneel/mmoptioneel/token-interface In core.tkint.201 is het verschil in scope tussen het authorization request en het token response verhelderd. |
Impact op: | DVP DVA Geen van beiden |
Te informeren Stakeholders | Acceptatie R&A beheer Regie CCDA Security Relatiebeheer Communicatie MM Loket Stichting MM |
Moeten afbeeldingen/mockups aangepast worden? | Ja Nee |
Aan te passen versies afsprakenstelsel | Optioneel |
Classificatie | Patch Minor Major |
Implementatie Termijn | 9 januari |
Gerelateerde tickets (o.a. ticket van deze ticket) | |
Status | Staat klaar voor release in afsprakenstelsel Verwerkt in afsprakenstelsel |
Uitwerking
Zet bij de locatie (en indien van toepassing bij de “In te voegen links (optioneel)”) de link naar de confluence space (bijv. MedMij Afsprakenstelsel 2), zet hier niet de link naar scroll view pagina. Is het een tabel benoem dan bij de locatie ook de rij.
Kopieer voor de oude en de nieuwe tekst ook de regel voor en na de aan te passen zin.
In de kolom “Oude tekst”, maak de verwijderde of gewijzigde stukken rood en streep ze door
In de kolom “Nieuwe tekst”, geef de nieuwe stukken hebben deze blauwige/groenige kleur.
Wil je een link toevoegen maak het woord paars in de kolom “Nieuwe tekst” en zet de link in de kolom “In te voegen links (optioneel)”.
Door te voeren wijzigingen
Locatie
Oude tekst
De parameters in de 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 |
|---|---|---|
grant_type | letterlijke waarde “refresh_token” | Conform hoofdstuk 6 van RFC6749 |
refresh_token | het uitgegeven refresh_token | Conform hoofdstuk 6 van RFC6749 |
Conform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden.
Nieuwe tekst
De parameters in de 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(!) |
Onderstaande voorbeeld dient als toelichting hoe het token request opgevuld zou moeten worden:
Token interface
TYPE REQUEST: GET
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-ee005cced48fDe parameters in de request naar het token endpoint worden bij het gebruik van een refresh token (refresh request) als volgt gevuld:
grant_type | letterlijke waarde “refresh_token” | Conform hoofdstuk 6 van RFC6749 |
refresh_token | het uitgegeven refresh_token | Conform hoofdstuk 6 van RFC6749 |
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: GET
https://authorization-server.com/token?grant_type=refresh_token
&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&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-ee005cced48fConform de OAuth 2- specificatie moeten overige parameters die meegestuurd worden in het request genegeerd worden.
In te voegen links
Locatie
Oude tekst
De parameters in de access token response worden als volgt gevuld:
parameter | vulling | toelichting |
|---|---|---|
| Het hiermee uitgegeven access-token. |
|
| letterlijke waarde |
|
| 900 | Conform verantwoordelijkheid |
| Het hiermee uitgegeven refresh-token. | Conform verantwoordelijkheid core.autorisatie.211 |
| Conform sectie 5.1 van de OAuth 2.0-specificatie. In toevoeging daarop: verplicht voor de functie Verzamelen. De scope bevat de gegevensdiensten (nummers) die op het moment van uitgeven van het access-token voldoen aan de volgende voorwaarden:
|
|
Nieuwe tekst
De parameters in de access token response worden als volgt gevuld:
parameter | vulling | toelichting |
|---|---|---|
| Het hiermee uitgegeven access-token. |
|
| letterlijke waarde |
|
| 900 | Conform verantwoordelijkheid |
| Het hiermee uitgegeven refresh-token. | Conform verantwoordelijkheid core.autorisatie.211 |
| Conform sectie 5.1 van de OAuth 2.0-specificatie. In toevoeging daarop: verplicht voor de functie Verzamelen. De scope bevat de gegevensdiensten (nummers) die op het moment van uitgeven van het access-token voldoen aan de volgende voorwaarden:
Omdat er hier sprake is van een acces token response bevat de scope de gegevendienstIDs. Dit is dus anders dan bij het authorization request, waarbij de zorgaanbieder in de scope staat. In de functie Verzamelen is er dus een verschil in de scope tussen het authorization request en het acces token response. |
|
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"
}In te voegen links
Review
Zijn de volgende acties uitgevoerd?