If you’ve added “Sign in with Google” to your app, you’ve probably hit a wall: Google’s OAuth verification process. Before your users can sign in without seeing a scary “unverified app” warning, Google needs to review and approve your application. And the number one reason apps get rejected or delayed? The privacy policy.
This guide explains exactly what Google requires, why most privacy policies fail the review, and how GDPR.Direct makes passing verification straightforward.
What Google actually checks
When you submit your app for OAuth verification through the Google Cloud Console, Google’s Third Party Data Safety Team reviews several things. For apps requesting standard scopes (openid, profile, email), which is what most “Sign in with Google” implementations use, the two critical requirements are:
- A privacy policy hosted on your domain. The URL you provide in the OAuth consent screen must be on the same domain as your application. A Google Doc or a PDF won’t pass.
- Specific disclosure of Google user data practices. Your privacy policy must contain clear sections explaining what Google data you access, how you use it, and how you store it.
Miss either of these, and you’ll receive an email like this from Google:
“Our review found that your application’s privacy policy is missing required information. Specifically, it does not contain clear sections describing your app’s data collection, storage, and data usage practices.”
At that point you need to fix the issues and reply to the email to continue the review. This back-and-forth can add days or weeks to your launch timeline.
Why most privacy policies fail
The typical developer approach to privacy policies falls into one of two traps:
Trap 1: Generic templates. Free privacy policy generators produce vague, boilerplate text that doesn’t mention Google by name. Google’s reviewers explicitly look for specific disclosure about their platform, generic language about “third-party services” is not enough.
Trap 2: No policy at all. Many early-stage apps simply don’t have a privacy policy page on their domain. They might link to a Google Doc or have a placeholder. Google requires the policy to be accessible at a URL on the same domain as your application (e.g., yourapp.com/privacy-policy).
What Google wants is specific and concrete:
- Data Accessed: “When a user signs in with Google, we receive their email address, name, and profile picture.”
- Data Usage: “This data is used exclusively for account creation and authentication. We do not access any other data from the user’s Google account.”
- Legal basis: A reference to the legal ground for processing (for EU users, this means GDPR).
- Retention period: How long you keep the data and what happens when the user deletes their account.
- Link to Google’s Privacy Policy: A direct reference so users can review Google’s own data practices.
How GDPR.Direct solves both requirements
GDPR.Direct addresses the two Google requirements in one step: it generates a legally compliant privacy policy that includes Google-specific disclosures, and lets you embed it directly on your domain.
Requirement 1: Privacy policy on your domain
GDPR.Direct’s Legal Hub provides an embeddable widget — a single line of HTML that you add to a page on your website:
<iframe
src="https://app.gdpr.direct/embed/privacy-policy?id=YOUR_COMPANY_ID&lang=en"
style="width: 100%; border: none;"
title="Privacy Policy"
></iframe>
This renders your full privacy policy directly at yourapp.com/privacy-policy. To Google’s reviewers, it’s a standard web page on your domain. The content loads from GDPR.Direct’s servers and automatically resizes to fit, so it looks native to your site.
No static files to maintain. No copy-pasting legal text. When you update your policy in GDPR.Direct, the embed updates everywhere automatically.
Requirement 2: Google user data disclosure
GDPR.Direct’s privacy policy template includes a dedicated “Third-party authentication” section. When you enable Google as an authentication provider in your GDPR.Direct company profile, your generated privacy policy automatically includes:
- A clear statement that you receive basic profile information when users sign in through third-party providers
- A structured table listing each provider (Google, GitHub, Microsoft) with the exact data accessed, the purpose, and a link to that provider’s privacy policy
- The legal basis for processing (Article 6.1(b) GDPR — contractual necessity)
- The data retention period (duration of the user’s account, deleted upon account deletion)
Here’s what the generated section looks like:
Third-party authentication
In cases where we enable the possibility of authenticating into our services using a third-party provider, we may receive basic profile information from these providers when you choose to sign in through them. This data is used exclusively to create and manage your account.
Provider Data accessed Purpose Privacy policy Email address, name and profile picture Account creation and authentication Google Privacy Policy GitHub Email address, name, username and profile picture Account creation and authentication GitHub Privacy Statement Microsoft Email address, name and profile picture Account creation and authentication Microsoft Privacy Statement The legal basis for the processing of such data is the execution of the contract between you and us, in accordance with Article 6.1.(b) GDPR.
The data obtained from these providers is retained for the duration of your account. Upon account deletion, this data will be removed except where retention is required for legal compliance purposes.
This is exactly the kind of specificity Google’s reviewers are looking for. No ambiguity, no generic language — just a clear, structured disclosure of what data you access, why, and for how long.
Step-by-step: from zero to verified
Here’s the complete process to go from no privacy policy to a Google-approved OAuth app:
1. Set up your GDPR.Direct account
Sign up at app.gdpr.direct and complete the onboarding wizard. You’ll enter your company details (business name, ID number, address, contact email) which are injected into your legal documents automatically.
2. Generate your privacy policy
GDPR.Direct uses your company information and a short description of your product to generate a complete, legally compliant privacy policy. The AI expands your product description into proper legal language covering all required GDPR sections, including the third-party authentication table.
3. Add the embed to your website
Create a /privacy-policy page on your website and paste the embed code. The exact method depends on your tech stack:
Next.js / React:
export default function PrivacyPolicy() {
return (
<iframe
src="https://app.gdpr.direct/embed/privacy-policy?id=YOUR_COMPANY_ID&lang=en"
style={{ width: "100%", border: "none" }}
title="Privacy Policy"
/>
);
}
Astro:
<iframe
src="https://app.gdpr.direct/embed/privacy-policy?id=YOUR_COMPANY_ID&lang=en"
style="width: 100%; border: none;"
title="Privacy Policy"
></iframe>
WordPress / HTML:
<iframe
src="https://app.gdpr.direct/embed/privacy-policy?id=YOUR_COMPANY_ID&lang=en"
style="width: 100%; border: none;"
title="Privacy Policy"
></iframe>
For full integration instructions including auto-resize and platform-specific tips, see our Legal Hub Implementation Guide.
4. Configure your OAuth consent screen
In the Google Cloud Console:
- Go to APIs & Services → OAuth consent screen
- Set your Application homepage to your website URL
- Set the Application privacy policy link to
https://yourapp.com/privacy-policy - Add your Authorized domains
- Click Save and Continue, then Submit for Verification
5. Wait for review and respond
Google’s review typically takes 1-5 business days. If they request changes, you’ll receive an email. Since GDPR.Direct’s template already covers the standard requirements, most apps pass on the first submission. If Google does request additional information, you can update your policy in GDPR.Direct’s dashboard and the embed will reflect the changes immediately — then simply reply to Google’s email confirming the update.
Proven at scale
This isn’t theoretical. Many companies, across multiple products and domains, use GDPR.Direct’s embedded privacy policy with the third-party authentication section. All of them have passed Google’s OAuth verification successfully, with the same template and the same approach described in this guide.
The pattern works because it directly addresses what Google’s Third Party Data Safety Team checks for: a real privacy policy, on your domain, with specific and structured disclosure of how Google user data is handled.
Beyond Google: what else you get
While passing Google’s OAuth verification might be your immediate goal, the privacy policy generated by GDPR.Direct covers far more than just the authentication section. Your complete policy also includes:
- Data controller identification: your business details, as required by GDPR Article 13
- All processing purposes: service provision, analytics, cookies, advertising, with legal bases for each
- User rights: access, rectification, deletion, portability, opposition, and limitation
- Data retention periods: specific timelines for each processing purpose
- Third-party processors: disclosure of services like CRMs, analytics, and payment processors
- Cookie policy: a separate, detailed cookie disclosure (also embeddable)
This means one GDPR.Direct subscription covers your Google OAuth verification, your GDPR compliance obligations, and your legal page needs — all kept in sync from a single dashboard.
Get started
Stop wrestling with legal boilerplate and verification rejections. Set up your privacy policy in minutes and move on to building your product.
Create your GDPR.Direct account and get a Google-ready privacy policy today.