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.

[theadell]

I'm excited to see the discussion around introducing DPoP support into the x/oauth2 package and I would love to start working on a prototype but I have a few questions and thoughts about the proposal that I hope you could help clarify @hickford

• Applicability of DPoP in Golang's Context: Go clients are confidential, where the refresh tokens are constrained to the client (by client authentication using simple client_id and client_secret or other methods). In this context, how do you view the benefits of the DPoP mechanism? While DPoP is primarily designed for public clients, could there be significant advantages for this library's use cases? (access tokens are not constrained but they are short-lived and stored securely on the server side)
• Scope of Implementation: How extensively does this proposal aim to implement the DPoP draft? Would the initial focus be on basic DPoP functionalities like generating and sending DPoP proofs, or does it extend to more advanced features? For instance, would there be an effort to inspect the OAuth 2.0 Authorization Server Metadata to determine the authorization server's DPoP support, specifically checking for the _dpop_signing_alg_valuessupported parameter?
• Resource and Authorization Server-Provided Nonce Support: The DPoP draft suggests optional support for a nonce provided by both authorization and resource servers. How should we approach these features? Would they be considered for an initial implementation or added later as extensions? should they be handled implicitly by the prototype or should the end developer manually retrieve them and pass them when making calls
• Resource Server Support: Given that this package is sometimes used by clients who also act as resource servers, would adding a method to validate DPoP-constrained tokens be considered?

Your insights would be greatly appreciated.

[hickford]

Go clients are confidential

@adel-habib 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?