how to troubleshoot OAuth "access denied" for users

TL;DR

OAuth fails closed, so a wrong account, a revoked grant, and an admin block all show the same generic access denied. Work the list in order: confirm which account is signed in on the consent screen, check whether the app grant still exists, then check for an admin-approval block. Most tickets resolve at step one or two, and the clean re-auth in step 4 fixes the rest.

The query

how to troubleshoot OAuth "access denied" for users

Use this when

• A user cant connect a third-party integration and sees access denied
• The OAuth consent screen errors instead of asking for permission
• Login via Google, Microsoft, or another provider fails at the grant step
• You need to tell a user-side problem from an admin-side block

Not for

• Plain password login failures
• SSO provisioning or SCIM sync issues
• Building or debugging your own OAuth integration
• API credential errors on the server side

Steps

1. Capture the exact error and where it appears

Ask for a screenshot. Access denied on the consent screen, after redirect back to the app, and inside the app are three different failures. Note the provider (Google, Microsoft, GitHub, other) and the exact wording, paraphrases hide the useful detail.

Expected output: the provider, the screen where it fails, and the verbatim message.

2. Check which account is signed in

The top cause: the user is signed into the wrong account in that browser, often a personal account when they need the work one. Have them look at the account name or avatar shown on the consent screen itself, not the account they think is signed in.

Expected output: the consent screen shows the intended work account, or the mismatch is found.

3. Check whether the app grant still exists

Have the user open their provider's connected-apps page (Google account settings, Microsoft my apps, GitHub authorized apps) and look for your app. If it is missing or was removed, the grant is gone. Password changes and security reviews silently revoke grants, which surprises people.

Expected output: a confirmed live grant, or a confirmed missing one.

4. Walk the clean re-auth

Remove the app from the provider's connected-apps page, then connect fresh from your app in a private window. One clean attempt beats three confused retries, and the private window dodges the wrong-account problem from step 2.

Expected output: a fresh grant completes the redirect back to your app.

5. Check for an admin-approval block

If the error mentions admin approval, consent, or policy, the user's IT admin has to approve the app first. This is common on Google Workspace and Microsoft Entra. The user cant fix it themselves: give them the app name and publisher to forward to their admin.

Expected output: the ticket is correctly routed to the customer's IT admin with what to ask for.

Ready-to-use reply

That error usually means the connection grant is missing or was made
with the wrong account. Can you try this: open a private window, go to
[your provider] connected apps, remove [app name] if it is listed, then
connect fresh from inside [your product]. If you see anything about
admin approval instead, your IT admin needs to approve the app first,
I can give you the exact name to send them.

Variant phrasings

oauth consent screen says access denied

Steps 2 and 5. The consent screen itself denying usually means wrong account or admin policy.

third party app not authorized by user

Steps 3 and 4. The grant is missing or stale, remove and reconnect.

user cannot grant access to an integration

Step 5 first. Cant-grant is the signature of an admin-approval block.

Why it happens

OAuth is a three-way handshake between your app, the provider, and the user's account, and every party can veto. The protocol returns the same blunt denial for a wrong account, a revoked grant, an expired session, or an admin policy, because saying which one would leak information. Support's job is to re-derive which veto fired, and the order above goes from most common to least.

Edge cases

• Admin approved the app but one user still fails: that user likely has a conditional-access policy (location, device compliance). Their admin has to check.
• Works in one browser, fails in another: a stale session cookie in the failing browser. Clear provider cookies or use the private window from step 4.
• Access denied right after a password change: the provider revoked grants as a security measure. Re-auth fixes it.
• The app was removed by the vendor: the grant page shows nothing to remove and reconnect fails. Check your status page before blaming the user.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hlEavEqG7AygjvxBnDAwTA