Google Sign-In sends user data to Google LLC. When a user taps "Sign in with Google," their Google profile is shared with your app and their IP is sent to Google — both need disclosure. Generate a full privacy policy with this clause built in →
Does Google Sign-In need a privacy policy disclosure?
Google Sign-In (the GoogleSignIn iOS SDK, Credential Manager on Android, and Google Identity Services on the web) lets users authenticate with their Google account. On success your app receives an OpenID Connect ID token plus a basic profile: name, email address, profile picture URL, and the stable Google account ID (the sub claim). Google's SDK also sends the user's IP address to Google to record the OAuth consent and for fraud prevention and rough location estimation.
This is a third-party transfer, so disclose it. Google's API Services User Data Policy and OAuth branding rules require a published privacy policy link before your app can go live. Sign-in is "App Functionality", not "tracking" under Apple's ATT rules or Guideline 5.1.2, and Google does not use Sign in with Google activity for ads. If you request scopes beyond basic profile (Gmail, Drive, Calendar, contacts), those are "sensitive" or "restricted" scopes: disclose each one specifically and pass Google's OAuth app verification, plus an annual security assessment for restricted scopes.
What data does Google Sign-In collect?
| Data type | Purpose | Linked to the user? | Used for tracking? |
|---|---|---|---|
| Name | Create and populate the account | Yes | No |
| Email address | Account identifier, login | Yes | No |
| Profile picture URL | Display in the app | Yes | No |
Google account ID (OpenID sub) and signed ID token | Verify identity, link the account | Yes | No |
| IP address (sent to Google by the SDK) | Record the OAuth grant, fraud prevention, approximate location | By Google | No |
| Any additional scope data you request (email contents, calendar, files, contacts) | Whatever feature needs it | Yes | No |
What you receive depends on the scopes you request and what the user grants. Requesting anything beyond name, email, and profile triggers Google's verification review, so keep the scope list minimal and disclose exactly what you ask for.
Copy-paste privacy policy clause for Google Sign-In
Sign in with Google
This app offers Sign in with Google, provided by Google LLC. When you
choose to sign in with Google, Google shares with us your name, email
address, profile picture, and your Google account identifier, and returns
a signed token that we use to verify your identity. Google's sign-in SDK
also sends your IP address to Google to record your consent to share this
data and to help prevent fraud. We use this information only to create
and secure your account. We do not use Google sign-in data for
advertising. Google processes the sign-in itself as an independent
controller under its own Privacy Policy at
https://policies.google.com/privacy.Adapt this: if you request extra scopes, add a sentence naming each one and why ("We also request read access to your Google Calendar so the app can show your events; you can revoke this at any time in your Google Account"). Otherwise keep it to the basic profile.
App Store "App Privacy" label answers
In App Store Connect, declare the following for Google Sign-In:
- Contact Info > Name, Email Address — purpose "App Functionality". Linked to the user: Yes. Used to track you: No.
- Identifiers > User ID — the Google account ID. Purpose "App Functionality". Linked: Yes. Used to track you: No.
- Contact Info > Other User Contact Info (or skip) for the profile picture — Apple has no exact bucket; the conservative choice is to declare it here. Purpose "App Functionality". (See uncertain note.)
- If you request extra scopes, declare the matching category (for example "Health", "Contacts", "Other Data") with the real purpose.
The GoogleSignIn iOS SDK (v7.1.0 and later) ships a PrivacyInfo.xcprivacy manifest with NSPrivacyTracking set to false and declares the data it collects (a user ID for recording OAuth grants, and an IP address for fraud prevention).
Google Play Data Safety answers
For the Play Console Data safety form:
- Personal info > Name, Email address, User IDs — Collected: Yes. Shared: No (the user provides this to Google directly through Google's consent screen; you receive it, you do not re-share it). Purposes: Account management, App functionality.
- Photos and videos (profile picture) — optional; Collected: Yes if you store it. Shared: No. Purpose: App functionality.
- Device or other IDs / Approximate location — only if your backend logs the IP address returned during sign-in. Collected: Yes in that case. Shared: No. Purpose: Fraud prevention and security.
- Google's own guidance: you do not need to declare data the user provides directly to Google's authentication service under Google's policy, but you do declare the profile data you receive and store. Data is not processed ephemerally; users can request deletion of their account.
Google Sign-In-specific gotchas
- Extra scopes trigger verification. Anything past name / email / profile is a sensitive or restricted scope: your OAuth consent screen must be verified by Google (typically 3 to 5 business days, longer for restricted), and your privacy policy must name each scope.
- Restricted scopes need a security assessment. Gmail, Drive file content, and similar require an annual third-party security assessment that can cost thousands of dollars.
- The ID token is a bearer credential. Verify it server-side against Google's public keys; never trust a client-supplied email without validating the token.
- Do not over-declare tracking. Google Sign-In is not ATT tracking; do not set "Used to track you" for it unless another SDK correlates the Google ID across apps for ads.
- Account deletion. If sign-in creates an account on your server, App Store Guideline 5.1.1(v) and Google Play require an in-app way to delete it.
- Migrated APIs. The classic GoogleSignIn button is deprecated on Android in favor of Credential Manager; the data collected is the same, but update your integration.
- You are responsible for the accuracy of your disclosure. This clause is a template, not legal advice.
Related
See the sibling clauses for RevenueCat, Stripe, Superwall, and Supabase. Build the full document with the privacy policy page generator, and see the Firebase privacy policy guide if your app also uses Firebase Authentication.