# use_dpop_nonce

Retry the UserInfo request with the nonce sent in the DPoP-Nonce header (401).

## Meaning

The server requires a server-issued nonce in DPoP proofs, and the proof had none or
a stale one. The response carries a fresh nonce in `DPoP-Nonce` (RFC 9449 §9). This
is a normal protocol round trip, not a failure.

## Impact

The first request after a nonce rotates costs one extra round trip. A client that
never retries with the nonce never gets claims.

## Diagnosis

A nonce challenge is not recorded as a refusal. A proof whose nonce is missing or
stale shows as cause `dpop_nonce_missing` or `dpop_nonce_stale` where it is
recorded. Check that the client reads `DPoP-Nonce` and puts it in the next proof.

## Mitigation

- As a client developer: on this answer, build a new proof with the `nonce` claim
  set to the `DPoP-Nonce` value and repeat the request once. Keep the latest nonce
  for later requests.

## Escalation

Escalate when a retry with the nonce just received is answered the same way again.
Open an issue with both request ids and the server version.

---

[Problem code runbooks](https://www.nauthera.io/docs/v1/runbooks/problems) · Generated from [`internal/runbook/problems.yaml`](https://github.com/nauthera/nauthera-server/blob/main/internal/runbook/problems.yaml) in nauthera-server.