Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

server_error

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program

The server hit an unexpected condition and could not complete the request (RFC 6749 §4.1.2.1).

Meaning

The server's own failure. At /authorize it is redirected to the client when the session, consent or code could not be read or written, and answered directly when the client registry or a pushed request could not be read. At /token it is sent when a DPoP nonce could not be issued, or when the replay store for DPoP proofs or client assertions does not answer; other faults at /token are a generic 500 problem document. /end_session sends it when a session could not be revoked.

Impact

Sign-ins or token requests fail while the fault lasts; the user sees the application's error, or the server's error page with a Reference ID. A logout answered this way did not take effect: the user is still signed in.

Diagnosis

  1. Look the request up by X-Request-ID on the Troubleshooting page. The record has outcome errored and reason internal_error; a DPoP or replay-store failure also names the step that failed.
  2. Read the server's error log for the same request id; the cause is logged there and never returned.
  3. Check Redis (codes, DPoP nonces and replay caches live there) and the database.

Mitigation

  • As a client developer: retry later; the request itself was not refused.
  • As an operator: fix the dependency the log names. See the common problems.
  • As a user: try again; if signing out failed, sign out again before leaving the device.

Escalation

Any server_error with healthy dependencies is a bug. Open an issue with the request id, the server version and the log lines for that request id. Never attach tokens, codes or secrets.

OAuth error runbooks · Generated from internal/runbook/oauth.yaml in nauthera-server.