Handle OAuth access_denied Errors Safely
access_denied means the authorization request was not approved. Preserve transaction security, explain the outcome, and identify whether a user or policy denied it.
Validate the error callback
Process the callback through the same trusted redirect endpoint as a successful authorization. Validate the state value against the initiating browser session before trusting or displaying transaction details. Keep any provider error description as diagnostic input, not safe HTML. Never log codes, state values, cookies, tokens, PKCE verifiers, or client secrets.
Separate user choice from policy denial
A user may decline consent or close an account-selection flow. The authorization server can also deny an application because of tenant policy, administrator consent requirements, application assignment, account type, risk controls, disabled access, or requested resource. Capture a correlation ID and documented non-secret error subcode to distinguish these causes.
Review requested permissions
Ask only for scopes required by the current feature. A broad or administrator-only scope can turn a normal login into a policy failure. Use incremental authorization when the provider supports it: request basic access first, then ask for an additional permission when the user invokes the related feature. Do not silently downgrade permissions if the application would then behave incorrectly.
Check client and tenant configuration
Confirm the client registration is enabled for the intended tenant and account types. Verify redirect URI, grant type, application assignment, publisher or verification status, consent configuration, and requested API resource. Use the provider's administrative audit or sign-in logs with the callback correlation ID. Avoid telling every user to ask an administrator when the client request itself is wrong.
Design a clear recovery path
Return the user to a stable application page that explains that access was not granted and no account connection was completed. Offer a deliberate retry, alternate account, reduced-permission feature when valid, or administrator instructions when policy is confirmed. Do not create an automatic redirect loop that immediately starts authorization again after denial.
Treat denial as a normal outcome
Users must be able to refuse authorization. Do not label a user cancellation as a system outage or repeatedly pressure for consent. Clean up the pending login transaction, retain only necessary security events, and keep the existing signed-in session separate from the failed external connection.
Retest each path
Test user cancel, missing consent, wrong tenant, denied scope, state mismatch, and a successful authorization. Confirm sensitive values never enter URLs beyond the provider protocol or application logs. Inspect safe callback encoding with the URL Encoder/Decoder.
Frequently Asked Questions
Does access_denied mean Cancel?
Not always; policy and configuration can deny authorization too.
Should the app retry automatically?
No. Explain the outcome and let the user choose.
Must state be validated on errors?
Yes. The error belongs to the same protected transaction.