Google OAuth Consent Screen Errors: redirect_uri_mismatch, access_denied, admin_policy_enforced and What Each One Really Means (2026)
Most Google OAuth errors are not bugs. They are configuration decisions, policy decisions, or verification decisions surfacing at the worst possible moment — usually in front of a customer. The screen says Error 400 or Error 403, but the string underneath it is what matters, and each string points at a different owner: your code, your Cloud project, the user, or their Workspace administrator.
Read the string, not the banner
Google names its authorization errors by string — redirect_uri_mismatch, access_denied, admin_policy_enforced, disallowed_useragent, org_internal, invalid_request. The big HTTP-status banner is only the wrapper. Teams that debug the banner spend days on the wrong layer.
Below is what Google documentation actually says each one means, and — more usefully — who has to move for it to go away.
The six errors that stop launches
redirect_uri_mismatch
The redirect_uri sent in the authorization request does not exactly match an authorized redirect URI on the OAuth client. It also fires when the request still uses the deprecated out-of-band (OOB) flow. Owner: your code and your Cloud console client.
access_denied
The user did not approve the request. Google documents this as the response when consent is declined — not as a defect to fix. Owner: the user, or the consent screen you are showing them.
admin_policy_enforced
The Google Account cannot authorize one or more requested scopes because of their Google Workspace administrator policies. No code change helps. Owner: the customer Workspace admin, who must grant access to your OAuth client ID.
disallowed_useragent
The authorization endpoint is being displayed inside an embedded user-agent that Google OAuth policies disallow — classically a WKWebView on iOS. Owner: your app shell. Embedded webviews are not fixable by configuration.
org_internal
The OAuth client belongs to a project that limits access to Google Accounts in one Cloud Organization, and the user is outside it. Owner: your project audience setting — Internal versus External user type.
invalid_request
The request was malformed, missing required parameters, or used an authorization method Google does not support. Owner: your integration — and Google explicitly asks you to verify you are using a recommended integration method.
The rules people learn the hard way
- Redirect URIs must match exactly. Google states the value must exactly match one of the authorized redirect URIs on the client. Not a prefix, not a pattern.
- HTTPS is required; localhost is the exception. Redirect URIs must use the HTTPS scheme, not plain HTTP. Localhost URIs, including localhost IP addresses, are exempt from this rule.
- Raw IP addresses are not allowed as hosts — again with the localhost exemption.
- Wildcards are not allowed. Redirect URIs cannot contain wildcard characters. Also excluded: userinfo subcomponents, path traversal, open redirects and fragment components.
- Changes are not instant. Google warns that it may take 5 minutes to a few hours for changes to these client settings to take effect. Many redirect_uri_mismatch reports are simply people testing too early.
- Testing mode has a hard cap. Projects with a Testing publishing status are limited to 100 test users, and a test user consumes that quota once added. Authorizations by a test user expire seven days after consent.
- The unverified-app screen has its own cap. Apps that present the unverified app screen are limited to 100 new users in total — and Google states that cap applies over the entire lifetime of the project and cannot be reset or changed.
How these get diagnosed properly
Separate configuration from policy
redirect_uri_mismatch, invalid_request and disallowed_useragent are yours to fix. admin_policy_enforced and access_denied are not. org_internal sits in between. Knowing which bucket an error lives in decides who you escalate to.
Check what your scopes actually trigger
Google displays the unverified apps warning when a project OAuth client requests scopes considered sensitive or restricted before verification is complete for those scopes. The error is a symptom; the scope list is the cause.
Confirm the audience and publishing status
Internal versus External user type, Testing versus In production, and whether the user is inside your Cloud Organization. These three settings explain most errors that look like code bugs.
Then — and only then — look at verification
If your app needs certain user data it must complete a verification process. The app name and logo only appear on the consent screen after verification. Our Google OAuth verification guide covers the sensitive and restricted scope review in detail.
The exact remediation for each error — the audience change, the scope reduction, the verification submission, the security assessment when restricted scopes are involved — depends on what your app actually does with the data. That assessment is the work, and it is deliberately not generalised here.
Why this quietly blocks revenue
- The 100-user lifetime cap is permanent. An app shipping behind the unverified app screen can onboard 100 users, ever. Google states it cannot be reset or changed.
- Seven-day expiry breaks trials. Test-user authorizations expire seven days after consent, so a pilot that looked stable last week is broken this week.
- admin_policy_enforced blocks entire enterprise accounts. One admin policy can stop every user at a customer, and no amount of engineering fixes it. See why the Workspace approval path is different.
- The unverified app warning costs conversions. Users abandon at a scary screen. Removing it means submitting a verification request — see what the warning means and how to remove it.
If a launch is blocked on OAuth verification, scope reduction, or an unverified-app screen you cannot get past, that is exactly the kind of submission we prepare and support.
Frequently asked questions
Why do I still get redirect_uri_mismatch after adding the URI?
Two common reasons. The URI does not exactly match what your code sends — Google requires an exact match — or the change has not propagated. Google states it may take 5 minutes to a few hours for changes to these settings to take effect.
Is access_denied a bug in my app?
Usually not. Google documents access_denied as the response when the user does not approve the request. If it is happening constantly, the problem is the consent screen — too many scopes, an unverified app warning, or an app name and logo that do not appear because verification is incomplete.
Can I fix admin_policy_enforced from my side?
No. The error means the user Google Workspace administrator policies prevent authorizing one or more requested scopes. The administrator has to explicitly grant access to your OAuth client ID.
Do all apps have to be verified?
No. Apps requesting only name, email and profile scopes, or using Sign in with Google, do not need users on a test list, show no warning, and their authorizations do not expire after seven days. Verification is triggered by sensitive and restricted scopes — and by wanting your name and logo on the consent screen.
Facts here are based on Google official documentation — Using OAuth 2.0 for Web Server Applications, Manage OAuth Clients, Manage App Audience, Manage OAuth App Branding, and the Unverified apps support article — reviewed July 2026. The Error 400 and Error 403 wording is browser banner text; Google names these errors by string. This is technical implementation guidance, not legal advice, and is not affiliated with or endorsed by Google LLC. Google makes all verification and enforcement decisions independently; no specific outcome or timeline can be guaranteed. Blocked on an OAuth verification or a consent-screen error? Reach out through the contact options in the footer.