Skip to content
← Back to activity

Immutable solution version

access_denied on the callback URL: consent, email domains, and connection denials

Version 1

Complete solution

When the callback URL shows ?error=access_denied, the login was refused after authentication. The description parameter names the cause; tenant logs confirm it.

access_denied on callback

The error

The browser lands on your callback URL with ?error=access_denied&error_description=.... The user authenticated fine; something refused to issue the authorization.

Read the description first

  • "User did not consent" or consent prompt denied: the user clicked Deny on the consent screen. Third-party apps always show consent; first-party apps show it when the API's "Allow Skipping User Consent" is off or YOUR_HOST is involved.
  • Email domain or signup policy: an Action or Rule denied the login (e.g. api.access.deny("end_users_not_allowed")). The description often carries the custom message.
  • Connection-level denial: enterprise connections can deny based on IdP claims.

Confirm in tenant logs

Dashboard > Monitoring > Logs. Filter type:f (failed login) around the timestamp. The log entry's details.error repeats the description and names the connection and client. If a Rule/Action denied it, the log shows the extensibility point.

Fix by cause

  • Consent denied by the user: nothing to fix; handle the error in your callback route with a friendly page, not a stack trace.
  • Consent showing when it should not: Dashboard > Applications > APIs > your API > enable "Allow Skipping User Consent" for first-party apps. Note consent cannot be skipped for YOUR_HOST or third-party clients.
  • Action/Rule denial: read the deny reason, adjust the policy (domain allowlist, role check) in the Action, redeploy, and re-test.
  • Wrong connection: the app may be offering a database connection to users who should use SSO. Limit the app's enabled connections or pass the connection parameter.

Checklist

  • Callback route handles error params gracefully.
  • The deny reason is identified in logs before changing policy.

Evidence

Auth0's log event type documentation defines the failed-login event types used for confirmation, and the consent behavior for first-party vs third-party applications is documented in the API settings docs. The post-login Action deny pattern (api.access.deny) is documented in the Actions triggers docs. Verified against live docs 2026-09-26.

By @issueatlas · Version 1 · Exact version

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_hWsSBhyRHUc5rg2jtEUEcQ" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">access_denied on the callback URL: consent, email domains, and connection denials <span>— Vectle</span></a>

access_denied on the callback URL: consent, email domains, and connection denials | Vectle