Proof of Possession / Certificate bound tokens

[ronaldkoster]

Ik ben Ronald Koster en werkzaam als developer aan het project NLX. Wij zijn op het moment druk bezig om de software die ontwikkeld is als onderdeel van dat project om te zetten naar een standaard genaamd Federated Service Connectivity(FSC). In deze standaard willen wij gebruik maken van access tokens en voldoen aan OAuth 2.0. Nu lopen wij tegen iets aan waar we niet uitkomen.

Voor access tokens uitgegeven binnen FSC is proof of possesion nodig daarom schrijft FSC certificate bound access tokens voor volgens RFC 8705. Wij weten niet wat wij moeten gebruiken als token_type. In zowel het OAuth NL Profiel en RFC 8705 wordt er niks over token_types gezegt in het geval van tokens waar proof of possession voor nodig is. Online vind ik verschillende voorbeelden waar, in het geval van certificate bound tokens, het token_type Bearer wordt gebruikt maar dit is volgens mij onjuist.

De definitie van een Bearer token is volgens RFC 6750:

Bearer Token
      A security token with the property that any party in possession of
      the token (a "bearer") can use the token in any way that any other
      party in possession of it can.  Using a bearer token does not
      require a bearer to prove possession of cryptographic key material
      (proof-of-possession).

Hebben jullie hier een mening over? Kunnen wij het token_type Bearer gebruiken of zijn er andere opties?

[jarichypma]

Dag Ronald,

Volgens mij staat het antwoord op je vraag in de RFC 8705 specificatie toegelicht: https://www.rfc-editor.org/rfc/rfc8705#name-mutual-tls-client-certifica. Hierin wordt ook de relatie met de de bearer-token spec (RFC 6750) gelegd.

Ik zie hier zo geen tegenstrijdigheid, maar wellicht dat iemand van het FSC-team dit verder kan toelichten.

[ronaldkoster]

Hoi Jarich,

Ik zie die relatie inderdaad staan en tijdens het lezen van RFC 6750 zag in sectie 1.2 het volgende staan bij de definitie van een Bearer token "Using a bearer token does not
require a bearer to prove possession of cryptographic key material
(proof-of-possession)". Dit precies wat je juist wel gaat doen met certificate bound token. Vandaar mijn vraag.

[mrtn78]

hi Jarich en Ronald,

Het NL Gov oAuth profiel stelt:
Clients SHOULD send bearer tokens passed in the Authentication header as defined by [[rfc6750](https://publicatie.centrumvoorstandaarden.nl/api/oauth/#bib-rfc6750)] . Clients MAY use the form-parameter method in [[rfc6750](https://publicatie.centrumvoorstandaarden.nl/api/oauth/#bib-rfc6750)] . Authorized requests MUST be made over TLS, and clients MUST validate the protected resource server's certificate.
zie ook: https://publicatie.centrumvoorstandaarden.nl/api/oauth/#requests-to-the-protected-resource

in Paragraaf 3.1.10 (zie: https://publicatie.centrumvoorstandaarden.nl/api/oauth/#token-response)
staat expliciet dat het Token_type mandatory is. 'The type for a JWT Bearer token is Bearer...'

RFC 8750 stelt dat This document describes an additional mechanism of client authentication utilizing mutual-TLS certificate-based authentication that provides better security characteristics than shared secrets.

mijnsinziens is RFC 8750 dus aanvullend op RFC 6750 en blijft het token_type Bearer.

conform rfc 6750 is het inderdaad niet required dat je als eigenaar van het bearer token ook proof of possesion van de private key moet overleggen. echter voegt RFC 8750 dit wel toe aan de werking van de flow.

Verder merk ik op dat de flow in essentie niet wijzigt. de interactie tussen client, authorization server en resource blijft identiek. Er wordt een aanvulling gedaan op:

1. de content van het JWT (toevoeging van de hash van het certificaat in de JWT)
2. de werking van de authorization server (uitlezen van het verstrekte certificaat en deze data als hash opnemen in de JWT)
3. de werking van de resource (extra controles om na te gaan of het gebruikte certificaat voor de mTLS connectie gelijk is aan het cert wat is gebruikt voor de communicatie met de authorization server).

[mrtn78]

Hebben jullie hier een mening over? Kunnen wij het token_type Bearer gebruiken of zijn er andere opties?

kortom: ja gebruik het token_type Bearer, Nee ik zie geen andere opties en ook geen noodzaak hiervoor.

[ronaldkoster]

Dan gaan wij het token_type Bearer gebruiken. Bedankt voor het uitzoeken!