DPoP Support for Thunder (RFC 9449)

[nandhu-kumar]

DPoP Support for Thunder (RFC 9449)

1. Problem Summary

Thunder currently issues bearer access tokens and refresh tokens. Bearer tokens can be used by any party that possesses them, making them vulnerable to token theft, replay, and exfiltration attacks. RFC 9449 (Demonstrating Proof of Possession) defines an application-level mechanism to sender-constrain tokens by binding them to a client's public/private key pair, so stolen tokens alone are unusable.

2. Scope

This document identifies the areas of Thunder affected by DPoP, highlights design questions and edge cases, and surfaces decisions that need to be made before implementation.

3. RFC 9449 Summary

DPoP works by having the client:

1. Generate a public/private key pair
2. Attach a signed DPoP proof JWT (via a DPoP HTTP header) to token requests
3. The AS binds the issued token to the client's public key (via a jkt thumbprint in the token's cnf claim)
4. On resource access, the client sends both the bound token and a new DPoP proof; the RS verifies the key binding

Key RFC sections relevant to Thunder:

• Section 4 - DPoP proof JWT structure and validation
• Section 5 - Token endpoint changes (issuing DPoP-bound tokens)
• Section 6 - Public key confirmation (cnf.jkt in JWT tokens, introspection)
• Section 7 - Protected resource access (DPoP auth scheme, Bearer compatibility)
• Section 8/9 - Server-provided nonces (AS and RS)
• Section 10 - Authorization code binding (dpop_jkt parameter)

4. Affected Areas in Thunder

Area	Files	Impact
Token endpoint	token/handler.go, token/service.go	Parse DPoP header, validate proof, bind tokens
Grant handlers	granthandlers/ (all grant types)	Pass DPoP key binding through to token creation
JWT access token builder	tokenservice/builder.go	Add cnf.jkt claim to issued JWTs
Token introspection	introspect/handler.go, introspect/service.go	Return cnf.jkt and token_type: DPoP in responses
Authorization endpoint	authz/handler.go, authz/service.go	Accept dpop_jkt authorization request parameter
Resource server middleware	security/jwt_authenticator.go, security/middleware.go	Validate DPoP proof + key binding on protected resources
Discovery/metadata	discovery/model.go, discovery/service.go	Advertise dpop_signing_alg_values_supported
Client registration (DCR)	dcr/handler.go, dcr/service.go	Support dpop_bound_access_tokens client metadata
PAR (if/when implemented)	Not yet implemented	Must support both dpop_jkt param and DPoP header per Section 10.1

5. Open Questions

5.1 Scope of Implementation

• Q1: Should DPoP be supported for all grant types (authorization_code, refresh_token, client_credentials, token_exchange), or only a subset initially?
• Q2: Should DPoP binding apply only at the token endpoint (binding the access token via cnf.jkt), or should the authorization code also be bound to dpop_jkt (Section 10)? Token-level binding alone leaves a window where a stolen authorization code can be exchanged without the private key, which is especially risky for public clients.
• Q3: How should public clients be handled?
• Q4: If neither the deployment nor the client configuration mandates DPoP, should Thunder still honor a voluntarily sent DPoP header and bind the authorization code/access token to the client's key?

5.2 Token Format and Storage

• Q5: Where the dpop_jkt will be stored when the dpop header comes in authorize/par request.

5.3 DPoP Proof Validation

• Q6: What should the acceptable time window for iat validation be? The RFC recommends seconds to minutes. Should this be configurable?

5.4 Nonce Mechanism

• Q7: Should Thunder implement AS-provided nonces (Section 8)? This significantly improves security against proof pre-generation but adds complexity and an extra round trip on first request.
• Q8: For nonce storage in multi-instance deployments, is shared state (Redis) required, or can stateless nonces (signed/HMAC'd) suffice?

5.5 Refresh Token Binding

• Q9: The RFC says refresh tokens for public clients can be DPoP-bound, but refresh tokens for confidential clients are NOT bound (they are already sender-constrained via client authentication). Does Thunder's current refresh token handling distinguish between public and confidential client refresh tokens? Do we need dpop_bound refresh_tokens?

5.6 Client Registration and Enforcement

• Q10: Should dpop_bound_access_tokens be a per-application setting in Thunder? If true, token requests without a DPoP proof are rejected.
• Q11: Is there a migration concern for existing applications/clients if DPoP is enabled globally vs. per-client?

5.7 Key Management

• Q12: Should Thunder validate the key size/strength (e.g., reject RSA keys < 2048 bits)?
• Q13: Which signing algorithms should be supported for DPoP proofs? The RFC requires asymmetric algorithms only. Minimum set: ES256. Should we also support PS256, RS256?

[sacrana0]

Nonce support is descoped from first implementation of DPOP rfc in Thunder.