Support OAuth DPoP

[hickford]

Is anyone working on OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) support? RFC 9449 https://datatracker.ietf.org/doc/html/rfc9449 was published 2023.

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens

Of course, the API will have to go through the Go change proposal process. (If it helps anyone, here's an example of a previous oauth2 proposal golang/go#58126.)

[hickford]

Go clients are confidential

@theadell You can use this library for confidential or public clients. A client is confidential if it can keep the secret confidential. So server-side web apps are confidential clients. Native apps such as desktop apps are public clients.

[theadell]

Native apps such as desktop apps are public clients.

That's right. I overlooked that use case.

[bnewbold]

Hi! Just wanted to chime in to voice more support for this, as the request hasn't been updated in some time.

One emerging use-case for DPoP is with dynamically-configured clients, for example in the AT Protocol and SOLID protocol ecosystems. In these contexts, there is no existing relationships between the developers or operators of the "home server" and "client apps". DPoP is used for both "confidential" and "public" clients.

In terms of most useful implementation details for AT Protocol (which I work on), generating and validating DPoP headers on individual resources requests and token requests would be the most helpful, both for clients and servers. Managing nonces would be very helpful.

Parsing Auth Server metadata and "negotiating" use of DPoP algorithm values would be helpful, but only happens during the authorization flow and could potentially be done by calling code?