One point of clarification on RFC 9449, per https://www.rfc-editor.org/rfc/rfc9449.html#section-5-11, access and refresh tokens are *not* bound to the same key material for the confidential clients (those having established authentication credentials with the authorization server). And a client with a backend service should be a confidential client.
On Tue, Oct 14, 2025 at 4:45 PM Yaroslav Rosomakho <yrosomakho= [email protected]> wrote: > Dear Oauth enthusiasts, > > We'd like to bring to your attention a proposal to separate DPoP Bindings > for Access and Refresh Tokens. > > This draft specifies a lightweight extension to OAuth 2.0 DPoP that allows > refresh tokens to be bound to a different proof-of-possession key than > access tokens. > > In RFC 9449, both access and refresh tokens are bound to the same key > material, which can be limiting in deployments where tokens are managed in > separate security domains (refresh tokens and their keys stored by a > backend service often backed by HSMs and access tokens used by an ephemeral > front-end instance). > > The draft introduces a new HTTP header, DPoP-RT and an optional > DPoP-RT-Nonce mechanism that enable independent key binding and > proof-of-possession for refresh tokens, while preserving full backward > compatibility with existing DPoP behaviour. > > We are very much looking forward to your feedback and suggestions! > > Best regards, > Yaroslav and Loren > > ---------- Forwarded message --------- > A new version of Internet-Draft draft-rosomakho-oauth-dpop-rt-00.txt has > been > successfully submitted by Yaroslav Rosomakho and posted to the > IETF repository. > > Name: draft-rosomakho-oauth-dpop-rt > Revision: 00 > Title: Separating DPoP Bindings for Access and Refresh Tokens > Date: 2025-10-14 > Group: Individual Submission > Pages: 17 > URL: > https://www.ietf.org/archive/id/draft-rosomakho-oauth-dpop-rt-00.txt > Status: https://datatracker.ietf.org/doc/draft-rosomakho-oauth-dpop-rt/ > HTML: > https://www.ietf.org/archive/id/draft-rosomakho-oauth-dpop-rt-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-rosomakho-oauth-dpop-rt > > > Abstract: > > This document defines an extension to OAuth 2.0 Demonstrating Proof- > of-Possession at the application level (DPoP, RFC 9449) that allows > refresh tokens to be bound to a different proof-of-possession key > than access tokens. In the existing specification, a single DPoP > proof is used to bind both tokens to the same key material. However, > in many deployments, refresh tokens and access tokens are stored and > managed in different security contexts. To support this operational > separation, this document introduces a new HTTP header field, DPoP- > RT, and corresponding DPoP-RT-Nonce mechanism, enabling independent > proof-of-possession for refresh token use while preserving > compatibility with existing DPoP-bound access tokens. > > > > The IETF Secretariat > > > > > This communication (including any attachments) is intended for the sole > use of the intended recipient and may contain confidential, non-public, > and/or privileged material. Use, distribution, or reproduction of this > communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your system. > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
