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

access_denied

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

The user or the server refused the request (RFC 6749 §4.1.2.1, RFC 8628 §3.5).

Meaning

Sent when the user refuses: by /authorize, redirected to the client, after the user declined on the consent screen, and by /token to a polling device after the user denied it on the /device screen. /register and /register/{client_id} send it with 403 when the token lacks the nauthera.clients:register scope, or the client was not registered dynamically.

Impact

After a user's refusal it is normal flow: the application should say the user declined. At /register it is a misconfigured registrar token.

Diagnosis

  1. A consent refusal is an oauth.consent.decided record with approved false; a device denial is oauth.device.decided, and the poll that followed is recorded under oauth.token.issued with cause authorization_denied.
  2. At /register, the client.registration.attempted record has cause insufficient_scope or operator_managed_client.

Mitigation

  • As a client developer: show a clear message and let the user try again. For /register, get an initial access token with nauthera.clients:register; see Getting an initial access token.
  • As an operator: clients registered through the AdminService or the operator are changed there, not through /register/{client_id}.
  • As a user: start again in the application if you declined by mistake.

Escalation

If users are refused without having declined, open an issue with the request id and the server version.

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