Hi VJ, I just realised this didn't get a conclusive response, so hopefully this helps:
What you're proposing by using PAR is already possible, where the PAR request accepts a dpop_jkt parameter and automatically returns a DPoP-Nonce header, per section 10.1: https://www.rfc-editor.org/rfc/rfc9449.html#name-dpop-with-pushed-authorizat So I don't think there's anything new to add, unless I'm missing something about your proposal? The only constraint is that the token request would need to be made within the validity window of the DPoP-Nonce, otherwise you will get back use_dpop_nonce errors which will require the retry. As an example, in AT Protocol's reference PDS implementation we support this with the DPoP Nonce being valid for 1 minute but we accept the nonce's at -1 minute, now, +1 minute. Yours, Emelia > On 19 Aug 2026, at 12:04, vj <[email protected]> wrote: > > Dear OAuth Working Group, > > I would like to propose an idea for discussion around DPoP nonce handling, > particularly in OAuth flows using PAR (Pushed Authorization Requests) and > CIBA (Client-Initiated Backchannel Authentication). > > The main goal is simple: > > Can the Authorization Server provide a DPoP nonce to the client before the > first DPoP-protected token request, so that the client does not have to make > an initial request that fails with 400 use_dpop_nonce? > > 1. Current DPoP nonce flow > > When an Authorization Server requires a DPoP nonce, the client may initially > send: > > Client → Authorization Server > > POST /token > DPoP: <proof without nonce> > The Authorization Server responds: > > HTTP/1.1 400 Bad Request > DPoP-Nonce: ABC123 > The client then has to retry: > > Client → Authorization Server > > POST /token > DPoP: <proof containing nonce ABC123> > So the initial flow becomes: > > /token > Client ────────→ AS > ←──────── > 400 + nonce > > /token again > Client ────────→ AS > ←──────── > Access Token > This is secure and intentional, but it introduces an additional round trip > purely for nonce discovery. > > 2. Proposed idea > > I propose that the Authorization Server could pre-provision a DPoP nonce > through an existing back channel, such as PAR. > > The nonce would simply be: > > generated by the Authorization Server > cryptographically random > short-lived > usable in a subsequent DPoP proof > not necessarily required to be cryptographically bound to the PAR request > itself > The DPoP key binding would continue to be handled independently through the > existing DPoP mechanisms. > > 3. Using PAR as the nonce bootstrap channel > > PAR already provides a direct client-to-AS back channel. > > The proposed flow would be: > > Client Authorization Server > | | > |-------- POST /par -------------->| > | | > |<------- 201 Created -------------| > | request_uri | > | DPoP-Nonce: ABC123 | > | | > | | > |-------- /authorize ------------->| > | request_uri | > | | > |<------- authorization code ------| > | | > |-------- POST /token ------------>| > | DPoP proof | > | nonce = ABC123 | > | | > |<------- access token ------------| > The important difference is that the client already has the nonce before > calling /token. > > Therefore: > > Current: > > /token → 400 + nonce → /token again > > > Proposed: > > /par → nonce → /authorize → /token → success > This avoids the initial failed request. > > 4. Why PAR is interesting for this > > One challenge with returning the nonce from the normal authorization response > is that the authorization response normally passes through the > browser/user-agent. > > For example: > > HTTP/1.1 302 Found > Location: https://client.example/callback?code=ABC > DPoP-Nonce: XYZ > The browser receives the response header, but the OAuth client application > cannot necessarily access that header. > > Putting the nonce directly into the authorization response parameters would > also introduce additional considerations around URL exposure, logging, > browser history, response modes, etc. > > With PAR, however: > > Client ←→ AS > is already a direct back-channel interaction. > > Therefore, PAR appears to provide a natural place for nonce pre-provisioning. > > 5. Does the nonce need to be bound to PAR? > > My initial assumption is that the nonce does not necessarily need to be > cryptographically bound to the PAR request. > > The nonce can simply represent: > > “This is a fresh value generated by the Authorization Server and currently > accepted for a DPoP proof.” > > The security responsibilities would remain separate: > > DPoP private key + signature > ↓ > Proof of possession > > > DPoP nonce > ↓ > Server-controlled freshness > Existing DPoP key-binding mechanisms such as dpop_jkt can continue to provide > the relationship between the authorization request/code and the DPoP key. > > The nonce therefore doesn’t necessarily need to establish the client’s > identity or key ownership. > > 6. Possible nonce lifecycle > > A simple model could be: > > PAR > ↓ > AS generates nonce N1 > ↓ > Client receives N1 > ↓ > User authenticates > ↓ > Authorization code > ↓ > Client creates DPoP proof containing N1 > ↓ > /token > ↓ > AS validates N1 > ↓ > Access token > The nonce could have a short lifetime and/or appropriate replay protections. > > For example: > > Nonce: > Random > Short-lived > Server-generated > Valid for DPoP proof > The exact lifetime and reuse rules would obviously need to be defined. > > 7. CIBA provides another interesting use case > > A similar concept seems particularly relevant to CIBA (Client-Initiated > Backchannel Authentication). > > CIBA already separates the user authentication interaction from the client > through a back channel: > > Client > | > | Authentication request > ↓ > Authorization Server > | > | User authentication > ↓ > User's device > | > | Approve > ↓ > Authorization Server > | > | Result > ↓ > Client > Unlike the traditional browser-based Authorization Code flow, CIBA already > has a direct communication channel between: > > Client ↔ Authorization Server > Therefore, the AS could potentially provide a DPoP nonce as part of the > back-channel authentication transaction. > > Conceptually: > > Client → AS > | > | CIBA request > ↓ > User authentication > | > ↓ > AS → Client > authentication result > + DPoP nonce > | > ↓ > Client → /token > DPoP(nonce) > | > ↓ > Access Token > Again, the purpose would simply be to eliminate the initial: > > /token → 400 use_dpop_nonce > challenge. > > 8. PAR and CIBA comparison > > The idea can therefore apply to two different back-channel scenarios: > > Flow > > Possible nonce bootstrap > > Normal Authorization Code + PAR > > AS provides nonce in PAR response > > CIBA > > AS provides nonce through the back-channel authentication interaction > > The common principle is: > > Existing secure back channel > ↓ > AS generates DPoP nonce > ↓ > Client receives nonce > ↓ > First token request already contains nonce > 9. Security model > > The proposal does not attempt to replace DPoP’s proof-of-possession mechanism. > > The validation would still be approximately: > > DPoP Proof > | > ┌──────────┴──────────┐ > ↓ ↓ > Signature valid? Nonce valid? > | | > ↓ ↓ > Key ownership Freshness > | | > └──────────┬──────────┘ > ↓ > Continue OAuth > The nonce is therefore an additional freshness mechanism rather than a > replacement for the DPoP key binding. > > 10. Main benefit > > The primary benefit is reducing the number of network requests. > > Current approach > > 1. /token > 2. 400 + nonce > 3. /token again > 4. Access token > Proposed approach > > 1. PAR > 2. /authorize > 3. /token + pre-provisioned nonce > 4. Access token > The first token request can already contain a valid DPoP proof. > > This could be particularly valuable in high-latency environments and > distributed systems where an additional round trip has a measurable impact. > > 11. Questions for the Working Group > > I would appreciate feedback on whether this approach could be considered as a > future extension/profile of DPoP. > > In particular: > > Can PAR be used as a nonce bootstrap mechanism for DPoP? > Does the nonce need to be bound to the PAR request, authorization code, or > DPoP key? > Could a short-lived server-generated nonce simply be issued by the AS and > used in the subsequent DPoP proof? > Should the nonce be returned using the existing DPoP-Nonce response header, > or would a new PAR response parameter be more appropriate? > Could a similar mechanism be defined for CIBA? > What replay and lifetime requirements would need to be specified? > Would this require an extension to RFC 9449, an extension/profile of PAR, or > a separate specification? > Are there existing OAuth WG discussions or proposals addressing DPoP nonce > pre-provisioning that I may have missed? > Summary > > The proposal can be summarized in one sentence: > > Use an existing OAuth back channel such as PAR or CIBA to pre-provision a > short-lived, server-generated DPoP nonce, allowing the client’s first token > request to contain a valid DPoP proof and avoiding the initial 400 > use_dpop_nonce challenge. > > I would be very interested in feedback on whether this provides a meaningful > optimization while preserving the security properties and intended semantics > of DPoP. > > > > Thanks & Regards, > Vijay > Programmer | Cyber Security > Email: [email protected] <mailto:[email protected]> > > On Fri, 16 Jan 2026 at 11:27 PM, Will Bartlett <[email protected] > <mailto:[email protected]>> wrote: >> I envisioned nonce mostly encoding one of two pieces of data: >> A timestamp, to prevent a compromised client from forward dating requests. >> A request hash, to get a signature for a specific request. >> >> Microsoft's PoP implementation (which is not quite DPoP, but close enough >> for this conversation) uses nonces as secure timestamps and has dedicated >> endpoints for retrieving nonces (though these predate the DPoP-Nonce header, >> so I'm not sure that we would build them today, given that we already have >> DPoP-Nonce). With this implementation, there's no security problem that I >> know of. Nonces are returned in 200s mostly as an optimization - to return a >> fresh signed timestamp at 80% of the expiration of the current nonce. A >> client might still hit a 401 if its nonce expires due to the client making >> no requests in the last 20% of the nonce lifetime. >> >> I guess my two cents would be that nonce expiration isn't so different from >> token expiration / revocation, and really shouldn't be a problem. When you >> use OAuth, sometimes your tokens will fail randomly (from the perspective of >> the application developer) with a 401 because the user e.g. changed their >> password in another tab or on another device, and some sort of backend >> revocation occurred. The client reacts to the 401 by returning to the OAuth >> authorization or token server to obtain a fresh refresh or access token, >> potentially showing the user some UI first. There's nothing inherently >> problematic about 401s occurring - the client just needs to handle them. >> >> Thanks, >> Will >> >> From: vj <[email protected] <mailto:[email protected]>> >> Sent: Wednesday, January 7, 2026 3:42 AM >> To: [email protected] <mailto:[email protected]> <[email protected] >> <mailto:[email protected]>> >> Subject: [EXTERNAL] [OAUTH-WG] Question: Improving DPoP Nonce Provisioning >> Without ERROR Responses >> >> You don't often get email from [email protected] >> <mailto:[email protected]>. Learn why this is important >> <https://aka.ms/LearnAboutSenderIdentification> >> Hello OAuth Working Group, >> I’m currently implementing DPoP (RFC 9449) and have encountered a practical >> UX challenge related to the way DPoP nonces are issued by authorization >> servers. >> >> Per the current standard, when a client sends a DPoP request that requires a >> nonce, the authorization server responds with a 400 Bad Request (or 401 >> Unauthorized from a resource server) including a DPoP-Nonce header and a >> use_dpop_nonce error code. The client is then expected to retry the request >> with the supplied nonce in the DPoP proof’s nonce claim. IETF >> <https://www.ietf.org/rfc/rfc9449.html?utm_source=chatgpt.com> >> In many implementations today, this leads to visible error responses in >> client logs or user interfaces before the retry occurs. This behavior — >> although correct per the spec — sometimes confuses customers or developers >> because an error response is served before the nonce exchange completes. >> >> Questions / Suggestions: >> >> Is there any recommended best practice for provisioning a nonce outside of a >> 400/401 error response? >> For example, could a dedicated endpoint be defined for clients to fetch the >> current nonce from the authorization server prior to a token or resource >> request? >> >> While the spec allows nonces to be supplied in a 200 OK response header >> instead of via challenge responses, that behavior is optional. If used >> consistently, it could avoid initial error responses entirely. Are there >> guidelines or recommendations on when servers should prefer this 200 OK >> mechanism? IETF >> <https://www.ietf.org/rfc/rfc9449.html?utm_source=chatgpt.com> >> If introducing an endpoint solely to serve a current nonce is not advisable >> for security or protocol correctness reasons, could the group clarify the >> intended UX pattern for nonces in high-frequency or browser environments? >> >> We’d appreciate any clarification or guidance the working group can provide. >> >> -- >> Thanks & Regards, >> Vijay >> Programmer | Cyber Security >> Email: [email protected] >> <mailto:[email protected]>_______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
