RFC 8705; OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens en PKI-Overheid certificaten

Logius-standaarden / OAuth-NL-profiel

Kennisplatform API's Nederlands profiel OAuth

https://logius-standaarden.github.io/OAuth-NL-profiel/

15 stars 5 forks source link

RFC 8705; OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens en PKI-Overheid certificaten #35

Open martinborgman opened 6 months ago

martinborgman commented 6 months ago

Bij ons laatste overleg werd RFC 8705 genoemd als optie bij de client credentials flow. Wat mij opvalt bij genoemde RFC is dat men in 2.1.2 zeer expliciet is in welke certificaat subject attributen gebruikt worden bij de authenticatie van de client. In onze situatie met PKI-Overheid certificaten is volgens mij alleen tls_client_auth_subject_dn van toepassing. Dit gaat mogelijk in tegen Digikoppeling Identificatie en Authenticatie

fterpstra commented 6 months ago

We gaan kijken of DPOP een alternatief kan zijn of wellicht moeten we identificatie en authenticatie van digikoppeling aanpassen. RFC8705 lijkt namelijk wel een belangrijke rol in de volgende iGov versie te spelen.

hhudig commented 5 months ago

Hi Martin,

Zie paragraaf 2.2: je kunt een jwks_uri registereren waar het juiste certificaat mee op te halen is. Ook bij private_key_jwt kun je gebruik maken van een jwks uri. Dit werkt voor direct access en full clients.

In een mobiele app in het lastig om een jwks_uri te benaderen maar beschikt de OP vaak over een geldig (niet verlopen) certificaat met de juiste gegevens (bijv. DN), door het dynamic registration process en de mobile bootstrap componenten die daar vaak voor zitten.