I envisioned nonce mostly encoding one of two pieces of data: 1. A timestamp, to prevent a compromised client from forward dating requests. 2. 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]> Sent: Wednesday, January 7, 2026 3:42 AM To: [email protected] <[email protected]> Subject: [EXTERNAL] [OAUTH-WG] Question: Improving DPoP Nonce Provisioning Without ERROR Responses You don't often get email from [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: 1. 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? 2. 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> 3. 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]
