Require DPoP at token endpoint but issue Bearer access tokens (DPoP-bound refresh tokens only)

[rasander]

Hi all,

We use Duende IdentityServer with multiple OIDC clients and many APIs. We’re gradually improving security, with a current focus on our native mobile apps (public clients).

We’re evaluating DPoP. We control the mobile apps, so adding DPoP in the clients would be fairly easy, but adding DPoP verification to every API is difficult and time-consuming (some backends are run by external partners).

So we are considering following

• Require DPoP at the token endpoint for our public clients (both the authorization_code and refresh_token grants), so the refresh token is DPoP-bound to the client’s key.
• Still issue Bearer access tokens (no cnf claim), so our existing APIs can continue to accept standard bearer JWTs while we roll out DPoP verification incrementally on the resource servers/backend systems.

As I read RFC 9449, this setup is explicitly allowed:

“An authorization server MAY elect to issue access tokens that are not DPoP bound, which is signaled to the client with a value of Bearer in the token_type parameter of the access token response (per RFC 6750). For a public client that is also issued a refresh token, this has the effect of DPoP-binding the refresh token alone, which can improve the security posture even when protected resources are not updated to support DPoP.”

Questions

1. Is this configuration supported in Duende IdentityServer?

2. If yes, what is the recommended way to configure it?

   • Per-client setting to require DPoP at /connect/token (for code and refresh)
   • But issue access tokens as Bearer (i.e., no cnf/DPoP binding), while keeping the refresh token DPoP-bound.

If it requires code changes, any pointers or sample snippets would be much appreciated.

Thanks!

[wcabus]

At the moment, there is no toggle switch to only apply DPoP-binding to refresh tokens while generating unbound bearer access tokens.
I'm also wondering if this would be a client setting, or maybe even a resource-based one: if you request an access token for a specific resource which doesn't support DPoP yet, you could then indicate that on the resource settings.

We're going to discuss this issue with the product team to gather their thoughts on the matter.

[rasander]

@wcabus Hi. Thanks for fast reply. For us, I think a client setting would be sufficient.

Looking forward to hear if this is something that will be supported in future.

[AndersAbel]

I think this should be configurable both on the client and API side. Enabling DPoP requires both the client and the API to be aware of it, so it should be possible to disable it for both the case when the API doesn't support DPoP and when the client doesn't. Then it's up to the API if it should accept bearer (non-DPoP) tokens or not. Allowing configuration per API/resource would make it a bit complicated though if some resources require DPoP and there are other where it isn't even supported. The situation should be similar if different resources indicate different signing algorithms, so we could see how it's solved there.

[josephdecock]

The fundamental challenge here is that the APIs are out of your control. There's going to have to be some place where you determine if an API supports DPoP or not.

Options to control if DPoP is used:

• Metadata from the API itself. RFC 9728 is the standard for this, but it is even newer than DPoP. If an API supported that standard, you could use it to determine if DPoP was required though. If supported by the APIs, this is the best option (but probably not available).
• The client could be responsible for managing this. You could do this via configuration (the Foo API always gets a bearer token), or through some sort of fallback process (try DPoP first, and if that falls, try a Bearer token. Then remember this behavior for some amount of time, to reduce chatter). In this case, you may not need to obtain DPoP and bearer tokens, and could just always obtain a DPoP token. When APIs don't support DPoP, you can send the DPoP token as a bearer token. APIs that don't know about sender constrained tokens in some cases would just ignore the cnf claim.
• IdentityServer could take the requested resource (if you're using resource indicators) into account when issuing a token, and send the client the appropriate token that was either sender constrained or not. This would involve some custom logic in the token request validation pipeline in IdentityServer. Implement ICustomTokenRequestValidator and register it in DI, and IdentityServer will automatically run your logic. What your logic needs to do is, look at the incoming resource indicators and determine if you want to use DPoP or not. In the validator's ValidateAsync method, you can get at the incoming resources via context.Result.ValidatedRequest.ValidatedResources and compare them to what you expect, driven by your data/config/etc. You can then control if the token generated will be a DPoP or Bearer token by setting request.ValidatedRequest.ProofType to either OidcConstants.TokenResponse.DPoPTokenType or OidcConstants.TokenResponse.BearerTokenType.