...
| Waarom is deze RFC nodig? | De OAuth2 specificaties doen geen (harde) uitspraak over of/hoe urls die als parameter in een Oauth2 request of response worden meegegeven, moeten worden encoded. Dit kan potentieel tot problemen leiden wanneer bij het verwerken van een request/response een url 'dubbel' of 'anders' geencodeerd wordt en daarna niet correct meer kan worden verwerkt. Denk bijvoorbeeld aan de redirect_uri. De ruimte die OAuth laat, heeft tot nu toe nog niet in de praktijk geleid tot problemen. Wel is ontstond recent een probleem in de tooling van Acceptatie, waarbij een proxy automatisch url's encodeerde. Om problemen te voorkomen dat toekomstige ontwikkelomgevingen en tools ook een 'automagische encoding' toepassen zal een eenduidige afspraak worden toegevoegd aan het AS. Voorstel is om alle redirect_uri's verplicht te url_encoden |
|---|---|
| Oplossingsrichting | In het Afsprakenstelsel een expliciete uitspraak opnemen (bovenop de OAuth2 specificatie) die de wijze van encodering voorschrijft. |
| Aanpassing van | Afsprakenstelsel |
| Impact op rollen | DVP, DVZA (gezien het feit dat er tot nu toe geen problemen zijn opgetreden, is de impact waarschijnlijk klein) |
| Impact op beheer | Geen |
| Impact op RnA | Geen |
| Impact op Acceptatie | Ja, aanpassingen aan scripts waar url's voorkomen in aanroepen. Uitbreiden testen met controle op encodering op voorgeschreven manier. |
| PIA noodzakelijk | |
| Gerelateerd aan (Andere RFCs, PIM issues) | |
| Eigenaar | Arjan van Krimpen Casper van der Harst|
| Implementatietermijn | 1.5 |
| Motivatie verkorte RFC procedure (patch) | Nvt |
...
In MedMij wordt in het OAuth2 protocol de redirect_uri alleen statisch toegepast om beveiligingsredenen (conform https://tools.ietf.org/html/rfc6819#section-5.2.3.3). Daarnaast mag conform OAuth2 geen fragment worden toegepast.
https://willekeurigpgo.nl/over/there?srvr=hst0#frgmnt
\_____/ \_________________/\__________/ \_________/ \_____/
| | | | |
scheme authority path query fragment
...
Dit betekent in de praktijk dat een redirect_uri binnen MedMij (waarschijnlijk) alleen MedMij zal zijn opgebouwd uit een scheme, authority/domein, path en path query deel :
- Conform OAuth2 mag er geen fragment gebruikt worden
- Omdat binnen MedMij de url statisch wordt gebruikt, (b)lijkt het query deel geen toegevoegde waarde. (Een scan van de OCL bevestigd dat dit in ieder geval op dit moment zo is. )
Een tweede reden om geen query toe te staan op de redirect_uri is om te voorkomen dat hier 'status'-informatie wordt opgeslagen. OAuth2 heeft hier juist de 'state'-parameter voor bedoelt in het request.
Door binnen MedMij het query deel van de redirect_uri niet langer te gebruiken en te verbieden, is er geen noodzaak meer om de redirect_uri te encoden.
...
- de redirect_uri MOET een absolute URI zijn, zoals gedefinieerd in RFC 3986, Sectie 4.3.
- de redirect_uri MAG een query bevatten, zoals beschreven in RFC 3986, Sectie 3.4. Deze query moet geformatteerd zijn volgens de principes van application/x-www-form-urlencoded Media Type. (Overigens leert een scan van de ZAL dat er nog geen deelnemers zijn die het query deel toepassen.)
RFC 6749, Appendix B zegt dat
- de namen en waardes in de query UTF-8 geformatteerd MOETEN zijn volgens het encoding scheme. Zie RFC 3629.
- Als alles UTF-8 geformatteerd is MOETEN namen en waardes moet geformatteerd worden volgens de principes van W3c.REC-html401-19991224.
Dit betekent dat de in ieder geval het query deel URLEncoded MOET zijn.
Om eenduidig gebruik te garanderen zou binnen het Afsprakenstels daarom de volgende eis toegevoegd moeten worden:
- in het authorization request MOET de redirect_uri NIET te encoden (of niet anders dan URL_ENCODE)urlencoded worden
- in het token request request MOET de redirect_uri NIET te encoden (of niet anders dan URL_ENCODE)
Dit betekent dat DVP's encoding moeten verwijderen uit hun codebase en dat DVZA's er van uit kunnen gaan dat de redirect_uri niet encoded is.
...
- urlencoded worden
- url_encoding moet conform https://datatracker.ietf.org/doc/html/rfc3986 (in praktijk zouden standaardimplementaties deze specificatie moeten volgen)
Op pagina Authorization interface toevoegen:
redirect_uri
- zodanig dat de erin opgenomen hostname gelijk is aan de
client_iden er geen poortnummer is opgenomen- de
redirect_urimoet volledig zijn en verwijzen naar eenhttps-beschermd endpoint- de redirect_uri moet urlencoded zijn (conform https://datatracker.ietf.org/doc/html/rfc3986)
Zie verantwoordelijkheden 1 en 2a op de pagina Interfaces.
De tweede eis is een maatregel tegen beveiligingsrisico's 4.1.5, 4.2.4, 4.4.1.1, 4.4.1.5 en 4.4.1.6 in RFC 6819. Zie bovendien Token interface, de toelichting onder verantwoordelijkheid 4.
Op pagina Token interface toevoegen:
redirect_uri
- dezelfde waarde als in het voorafgaande authorization request
- de redirect_uri moet urlencoded zijn (conform https://datatracker.ietf.org/doc/html/rfc3986
NB: De redirect_uri MOET NIET dubbel encoded worden(!)
Er is geen impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )
Risico's
Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.
| Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
|---|---|---|---|---|
| DVZA kan authorization of token request niet verwerken door encode url in request. | L | H | In Acceptatie controleren op correct gebruik redirect_uri in requests. | |
| Afwijkende implementatie van url_encoding in verschillende ontwikkelplatforms kan tot problemen leiden | L | H | In Acceptatie controleren op correct gebruik redirect_uri in requests. |
Bijlagen
| Attachments |
|---|