Demonstrating Proof Of Possession (DPoP)

[dbfr3qs]

Recently, the IETF released RFC9449, a proposed internet standard that describes a method for constraining access tokens to devices through the use of public key cryptography.

The idea is for the client to generate a cryptographic key pair, and use this to sign requests to the authorisation server for access tokens/refresh tokens, and then on subsequent requests to resources with said access tokens/refresh tokens. These signatures are referred to as "proofs" and are supplied in an additional request header. The spec also allows for optionally constraining authorisation codes, so that the entire end to end process is constrained and there's no chance anything can be used outside of the client.

In the frontend, this could be particularly useful because there's no secure method to store tokens, opening up vectors for token exfiltration, for example through XSS or other means (e.g. supply chain, CDN cache pollution). DPoP may provide a way to eliminate certain attack vectors which seek to exfiltrate tokens out of the browser to be used by separate systems owned by bad actors, though it would not protect against attacks where a compromised browser is used directly by a bad actor.

To prevent leaking/exfiltration of the key material used to generate the DPoP proofs in the browser, we can make use of the browser's SubtleCrypto api to generate cryptographic keys that are not extractable. From there, we can store the CryptoKeyPair object using indexedDB, and use that object to generate DPoP proofs. This provides a way to securely store key material without the possibility of exfiltration, though I am not sure it would prevent a motivated bad actor who had gain full control of a user's machine or was proxying requests through a compromised browser.

As cookie based authentication becomes more and more restricted by browsers, and refresh tokens become more standard to keep sessions alive, it is my opinion that constraining tokens will become essential, particularly in pure frontend clients.

Is this something that is worth considering adding to the library?

I've provided a PR with an implementation that covers most of the spec, and uses the native SubtleCrypto api and indexedDB as described above. I have left out a few areas that I don't think are relevant to the use cases oidc-client-ts addresses. If this is something worth considering, please take a look.

[pamapa]

Thanks for providing this, i need some time to read through this. Looks interesting.

[dbfr3qs]

Cool - I realise it's quite a lot to take in so keen to collaborate and contribute further if you think it's worthwhile functionality.

[uvdsl]

I'd like second DPoP support in this library. Would be really useful.