LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Outlook
Google Calendar
Join Slack CommunityGoogle OAuth Consent Screen: Setup, Fixes & Why It's Not Showing (2026)
The google oauth consent screen moved in 2024. It now lives under Google Auth Platform in the Cloud Console - not where you used to find it. This guide shows you exactly where to go, how to configure it step by step, and how to fix the most common issues (including when it refuses to show up).
Where is it? Since 2024, the google oauth consent screen is located under APIs & Services > Google Auth Platform in the Cloud Console - not the old "OAuth consent screen" menu item. The settings are now split into three tabs: Branding (app name, logo, domains), Audience (Internal/External user type, test users), and Clients (OAuth Client IDs). If the menu doesn't appear at all, your project hasn't enabled any OAuth-compatible API yet, or your account lacks the Owner or Editor role.
Where is the OAuth consent screen in 2026?
If you followed a tutorial written before 2024 and can't find "OAuth consent screen" in the left sidebar, you're not imagining things. Google renamed and restructured the entire section. It now lives under a new name: Google Auth Platform. This is the most common reason developers report that the google oauth consent screen is "not showing" - it's still there, just in a different place.
Step 1: Go to console.cloud.google.com and make sure you have the correct project selected in the top project picker. Many "not showing" issues are simply caused by being in the wrong project.
Step 2: In the left sidebar, click APIs & Services.
Step 3: Look for Google Auth Platform in the sub-menu (previously called "OAuth consent screen"). If you see it, click it. If you don't, see the troubleshooting section below.
Step 4: You will land on the Google Auth Platform dashboard. The three tabs - Branding, Audience, and Clients - replace the old single-page consent screen form.
The Audience tab in Google Auth Platform (formerly "OAuth consent screen") - this is where you choose Internal or External user type and manage test users.
OAuth consent screen not showing or keeps redirecting: how to fix it
The google oauth consent screen can fail to appear or behave unexpectedly for several distinct reasons. Below is each error pattern with its exact cause and the fix - formatted to be as fast to scan as possible.
The Google Cloud Console UI changed in 2024. The old "OAuth consent screen" menu item was renamed to "Google Auth Platform". Older tutorials still reference the old name.
In the left sidebar under APIs & Services, scroll until you see "Google Auth Platform". If you still don't see it, you may need to enable at least one Google API on your project first (the section only appears once an OAuth-compatible API is enabled).
Your Google account does not have the Owner or Editor IAM role on the project. Viewer-role accounts cannot edit consent screen settings.
Ask the project Owner to grant you the Editor role (or higher) via IAM & Admin > IAM. If you created the project yourself, check that you are logged in with the correct Google account - the project picker sometimes shows projects you have read-only access to.
You have not selected a user type (Internal vs External) yet. In the new UI, the "Get Started" button on the Google Auth Platform overview page expects you to first complete the Audience step.
On the Google Auth Platform overview page, click "Get Started" if prompted, then navigate to the Audience tab and choose either Internal or External. Once a user type is saved, the full Branding configuration form becomes available.
Your app is in Testing status (or the publishing status is "In testing") and you are requesting sensitive or restricted scopes. Google shows the "unverified app" interstitial before the actual consent screen.
For development: add the test user's email to your test users list (Audience tab). For production: submit your app for Google's OAuth verification. Users who are listed as test users will still see a warning but can proceed by clicking "Advanced > Go to [App name]". The warning disappears once your app is verified and published.
This is expected behavior. Once a user grants consent, Google remembers the grant and skips the screen on subsequent logins. The consent screen only re-appears if the user revokes access or if you request new scopes.
To force re-display for testing, add prompt=consent to your authorization URL parameters. In production, only use prompt=consent on the first authorization call (to receive the refresh_token) - not on every login.
access_denied error instead. Internal apps are restricted to users within your Google Workspace organization by design. Switch to External if you need to support non-Workspace users.Unipile's pre-verified OAuth key removes these error scenarios from your setup - no consent screen configuration on your end, as an independent technical intermediary acting on behalf of each authenticated user.
How to set up the OAuth consent screen step by step
This section covers the full consent screen configuration - the part you need to complete after creating a Google Cloud project and enabling a Google API. If you haven't done those steps yet, see the full Google OAuth guide which covers project creation and API activation first.
In the Audience tab, the first decision is whether your app serves users inside your Google Workspace organization or any Google account holder:
- Internal: only users within your Google Workspace organization. No verification required. Ideal for internal tools, admin panels, or enterprise apps used by your own employees only. Not available if your project is attached to a personal Gmail account (only Workspace accounts).
- External: any Google account holder. Apps start in "Testing" mode with a 100-user cap. Sensitive or restricted scopes require Google's verification process before the app can be published to all users.
Audience tab: choose Internal (Workspace-only) or External (any Google account). This decision affects your verification requirements.
Tip: you can change from Internal to External later, but you cannot change from External back to Internal once users have authorized your app. Choose carefully.
In the Branding tab, fill in the following fields. These are what users see on the google oauth consent screen when they authorize your app:
- App name: the name displayed prominently at the top of the consent screen. Use your product name, not a technical identifier.
- User support email: displayed on the consent screen as a contact for users who have questions about your app's access request. Use a monitored alias or distribution list - not a personal email.
- App logo: a square PNG or JPG, minimum 120x120px. Appears on the consent screen and in the Google account's list of authorized apps. Optional but strongly recommended for user trust.
Branding tab - App information: fill in the app name, logo, and support email exactly as you want them shown to users on the consent screen.
Still in the Branding tab, the App Domain section requires the following links:
- Application homepage URL: the public homepage of your app or product. Must be a live, accessible URL (not a login page).
- Privacy Policy link: required for all External apps requesting scopes beyond basic sign-in. Must explicitly mention the Google scopes you are requesting and how data is used. Google's verification team checks this carefully - a missing or vague privacy policy is the most common rejection reason.
- Terms of Service link: optional but recommended for production apps.
App Domain: provide live URLs for your homepage, privacy policy, and terms of service. All URLs must be publicly accessible before you submit for verification.
The Authorized Domains section (below App Domain) controls which domains can be used in your OAuth redirect URIs and in the app domain links above. Add the root domain of your application (e.g. yourapp.com).
Authorized Domains: add your root domain. Only redirect URIs and app URLs from this domain will be accepted by Google.
Tip: authorized domains and redirect URIs (set in the Clients tab) must be consistent. If your redirect URI is https://app.yourapp.com/callback, you need to authorize yourapp.com here, not app.yourapp.com.
Also in the Branding tab, provide a developer contact email. This is the address Google uses to send:
- Verification status updates (approval, rejection, or clarification requests)
- Policy compliance notices
- Notifications about changes to your app's OAuth status
Developer contact: use a monitored distribution list. Critical Google verification emails may be filtered as spam - check the spam folder during your review window.
Important: use a distribution list or shared inbox, not a personal email. Google's verification team may send emails during business hours in a different timezone. If you miss the response window, your verification can be delayed by weeks.
Scopes define what data your app can access on behalf of the user. In the new Google Auth Platform UI, scopes may be configured per OAuth client (under the Clients tab > select a client > Scopes). Click "Add or Remove Scopes" to open the scope selector.
Scope categories that affect your verification path:
- Non-sensitive scopes (e.g.
openid,email,profile): basic sign-in only. No verification required. App publishes immediately. - Sensitive scopes (e.g.
gmail.readonly,gmail.send,gmail.labels): require a Google security assessment (OAuth verification). App stays in Testing mode until verified. - Restricted scopes (e.g.
mail.google.com,gmail.modify): require both Google OAuth verification AND a CASA Tier 2 security audit. Takes significantly longer.
Scope selector: choose the minimum scopes your app actually needs. Each sensitive or restricted scope adds verification requirements. Plan this before you build.
For a complete reference of Gmail-specific scopes, which APIs each one unlocks, and how to request them in your authorization URL, see the Gmail API Scopes Guide.
Principle of least privilege: only request scopes your app currently uses. Adding a restricted scope after launch means restarting the entire verification process, including a new CASA Tier 2 audit.
In the Audience tab, the Test users section lets you add Google account emails that can authorize your app while it is in Testing status.
Key rules about the test user cap:
- Maximum 100 test users can be added to an External app in Testing status. This is a hard Google limit - you cannot increase it without publishing your app.
- Test users see the "unverified app" warning screen but can still authorize your app by clicking through the warning.
- Access tokens for test users in testing mode expire after 7 days. Users must re-authorize when the token expires.
- Once you submit for verification and Google approves your app, the 100-user cap is lifted and the 7-day expiry goes away.
If you need more than 100 users before verification: the only option is to submit your app for Google verification. There is no workaround within Google's systems. Alternatively, consider whether Unipile's pre-verified OAuth key (next section) can handle the OAuth flow for you, eliminating both the cap and the verification timeline.
Want to skip this entire configure oauth consent screen process?
Use Unipile's verified OAuth key instead - no consent screen setup, no 100-user cap, no verification wait.
Internal vs External: which one should you choose?
The Internal vs External choice on the google oauth consent screen is one of the most consequential decisions in your setup. It determines your verification path, your user base, and whether you will face a 100-user cap during development. Here is the full picture.
Skip the Internal vs External decision entirely
With Unipile's pre-verified OAuth key, you serve external users without Google verification - Unipile operates as an independent technical intermediary on behalf of each authenticated user.
After the consent screen: verification and CASA
Completing the google oauth consent screen configuration is not the end of the process for External apps requesting sensitive or restricted scopes. What comes next depends on which scopes you chose. Here is the short version - the full verification and CASA walkthrough lives in the Google OAuth hub.
Right after you configure the oauth consent screen, your External app is in Testing status. Only the users you add to the test users list (up to 100) can authorize your app. This is fine for development and early testing.
When you are ready to open your app to more users, click "Prepare for Verification" (or "Submit for verification") in the Google Auth Platform overview. Google reviews your app's privacy policy, authorized domains, requested scopes, and how your app uses the data. Review time varies - typically 2-6 weeks, sometimes longer for restricted scopes.
If your app requests restricted scopes (like mail.google.com or gmail.modify), Google additionally requires a CASA Tier 2 security audit by an approved third-party assessor. This involves a review of your app's security posture, data handling, and access controls.
Once verified, your app is published. The "unverified app" warning screen disappears. The 100-user cap is lifted. The 7-day token expiry for test users goes away. Users see your branded consent screen without warnings.
For a broader view of how Google OAuth fits into email API architecture - including unified provider access across Gmail, Outlook, and IMAP - see the Email API guide.
Unipile has already completed the CASA Tier 2 audit for its Google OAuth integration. This means when you use Unipile as an independent technical intermediary, acting on behalf of each authenticated user, you don't have to go through the CASA process yourself. See the full Google OAuth hub for the details on Unipile's certification path and how the POC / certify later / switch workflow works.
Skip the consent screen setup entirely
If your product needs to access users' Gmail or Google Calendar data, you can choose to handle the Google OAuth consent screen setup yourself - or you can use Unipile as an independent technical intermediary, acting on behalf of each authenticated user, with a pre-verified OAuth key that already has CASA Tier 2 certification. This is not a workaround for Google's security review. Unipile has completed that review for you - that is the product.
Unipile is not affiliated with, endorsed by, or sponsored by Google. Unipile operates as an independent technical intermediary between your application and the Google OAuth infrastructure.
Connect your users' Google accounts through Unipile's verified OAuth integration. Your users authorize once - Unipile handles the rest, as an independent technical intermediary, on behalf of each authenticated user.
Google OAuth Consent Screen - FAQ
The most common questions about configuring, troubleshooting, and navigating the google oauth consent screen in 2026.
There are five common reasons: (1) You're looking for the old "OAuth consent screen" menu - it was renamed to "Google Auth Platform" in 2024. (2) You're in the wrong project - check the project picker at the top. (3) Your account lacks Owner or Editor IAM role. (4) No OAuth-compatible API has been enabled on the project yet - the Google Auth Platform section only appears once an API is activated. (5) Your app is configured as Internal but you're testing with an external Google account - Internal apps block all non-Workspace users by design. For detailed fixes, see the troubleshooting section above.
Since 2024, navigate to APIs & Services > Google Auth Platform. The old "OAuth consent screen" menu item no longer exists - it was replaced by Google Auth Platform, which organizes the settings into three tabs: Branding (app name, logo, domains), Audience (Internal/External user type, test users), and Clients (OAuth Client IDs and redirect URIs). This UI restructure is the single biggest cause of the google oauth consent screen "not showing" search query in 2026.
More on this in our complete Google OAuth Playground guide.Internal: all users are in your Google Workspace organization, no verification ever required, no test user cap, no unverified warning. Best for internal tools. Requires a Workspace account (not personal Gmail).
External: any Google account holder can use your app. Starts in Testing mode (100-user cap). Sensitive scopes require Google verification (2-6 weeks). Restricted scopes additionally need CASA Tier 2. Choose External for any public or customer-facing application.
The hard cap is 100 test users for External apps in Testing status. This limit is set by Google and cannot be bypassed. Test users can still authorize your app but see a warning screen first. Their tokens expire after 7 days (instead of the normal refresh-token lifetime). To lift the cap, submit your app for Google's OAuth verification. Once published, there is no user limit.
It depends on your configuration: Internal apps never need verification. External apps using only basic scopes (openid, email, profile) can publish without verification. External apps requesting sensitive scopes (like gmail.send, gmail.readonly) must pass Google's OAuth verification before lifting the 100-user cap. External apps requesting restricted scopes (like mail.google.com) additionally require a CASA Tier 2 security audit - on top of the standard verification. See the Gmail API Scopes Guide for the full scope classification.
You cannot skip the google oauth consent screen within Google's own infrastructure - it is a required step for any OAuth 2.0 flow. However, you can avoid configuring and getting it verified yourself by using Unipile's pre-verified OAuth key. Unipile acts as an independent technical intermediary, on behalf of each authenticated user, with Google verification and CASA Tier 2 certification already completed. This is not a security workaround - Unipile has gone through Google's full review process. Your users still see a consent screen (Unipile's verified one), you just don't have to build and verify your own.
Discover production-ready Gmail API integration.Still have questions about Google OAuth setup? Our team is here to help.
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL 
TR