RFC021/OpenID4VP: Use sender-constrained access tokens instead of bearer tokens

[reinkrul]

Applies to the new set of OAuth2 RFCs we're implementing (RFC021, OpenID4VP).

We currently specify bearer tokens, but this does not mitigate an attacker getting hold of an access token. The attacker can then query the resources the token gives access to.

FAPI (Financial Grade API Security Profile, https://openid.net/specs/openid-financial-api-part-2-1_0.html) adds sender-constrained API tokens, where the OAuth2 client must use an additional secret when accessing a resource with the token, to proof ownership. Initially, this is supported through mTLS (client-bound access token through X509 client certificate's fingerprint), more "recently" DPoP (Demonstrating Proof of Possession) was added (FAPIv2). So there's multiple options to choose from.

Considerations

Which component is the OAuth2 client/relying party? The Nuts node, XIS application or both? The access token is requested by the Nuts node, it's actually used by the XIS application. A secret (e.g. private key) would need to be accessible by both components. This is somewhat easier with a client certificate, as both can load the same certificate (might be an anti-pattern?). With DPoP requiring a new key pair for each access token, a more complicated setup is needed with sharing private keys (bad idea?) between the components.

[reinkrul]

See https://github.com/nuts-foundation/nuts-node/issues/2603

[gerardsn]

I think this combines 2 things

1. exchange of authorization code for the access token OAuth 2.0 Security Best Current Practice has a very strong preference for RFC7636

   Public clients MUST use PKCE

2. using that access token on a resource endpoint as described above and in the BCP

[reinkrul]

We now support DPoP and PKCE