Firebase Authentication sends user data to Google LLC. Sign-in identifiers, hashed credentials and the IP address and device used at sign-up leave the device and are stored in Google's Identity Platform, so this third-party transfer must appear in your privacy policy for App Store review, Google Play and the GDPR. Generate a full privacy policy with this clause built in →
Does Firebase Authentication need a privacy policy disclosure?
Yes. Firebase Authentication (part of Google's Identity Platform) creates and manages user accounts for your app. Depending on which sign-in methods you enable, it stores an email address, phone number, display name, photo URL, federated provider user IDs (Google, Apple, Facebook, etc.), and a salted password hash for email/password accounts. To secure sign-up and sign-in it also collects the user's IP address and device information for abuse and fraud detection, plus a "Firebase user agent" containing device metadata (OS version, name, model, brand, form factor), and it issues ID tokens and refresh tokens.
Firebase Authentication is App Functionality, not tracking. Google processes this data as your processor to provide the sign-in service, does not use it for advertising, and does not share it except with subprocessors that help run Firebase or as you instruct. It therefore does not require an App Tracking Transparency prompt. You still must disclose the account data you hold, its purpose, and how a user deletes their account.
What data does Firebase Authentication collect?
| Data type | Purpose | Linked to the user? | Used for tracking? |
|---|---|---|---|
| Email address | Account creation, sign-in, account recovery | Yes | No |
| Phone number (phone auth) | Account creation, sign-in via SMS code | Yes | No |
| Display name and photo URL | Profile, populated from the sign-in provider | Yes | No |
| Federated provider user IDs (Google, Apple, Facebook, etc.) | Link the account to the external identity provider | Yes | No |
| Salted password hash (email/password auth) | Credential verification | Yes | No |
| IP address and device information at sign-up / sign-in | Abuse, fraud and bot detection; rate limiting | Yes | No |
| Firebase user agent / device metadata (OS version, model, brand, form factor, SDK version) | Service delivery, security | Yes | No |
| ID tokens, refresh tokens, reCAPTCHA and Play Integrity tokens | Session management, anti-abuse | Yes | No |
The exact list depends on which providers you enable. Email-link sign-in, anonymous auth, multi-factor auth (which stores a second phone number or TOTP secret), and custom claims all change what you hold. Any extra profile fields you write to the user record are your responsibility to disclose.
Copy-paste privacy policy clause for Firebase Authentication
Account authentication. We use Firebase Authentication, a service
provided by Google LLC, to create and secure your account. Depending on
how you sign in, Firebase Authentication stores your email address,
phone number, display name and profile photo URL, the user identifier
from any third-party sign-in provider you use, and, for password
accounts, a salted hash of your password. To prevent abuse it also
records the IP address and device information used when you sign up and
sign in, and it issues authentication tokens to keep you signed in.
Google processes this data as our processor solely to provide the
authentication service and does not use it for advertising. This is
account functionality, not tracking. You can delete your account and the
associated authentication data at any time; see our account deletion
section. Learn more at https://firebase.google.com/support/privacy.Adapt this: list only the providers you actually enable, add multi-factor details if you use MFA, and link your deletion page. You are responsible for making the wording match your build; this is a starting point, not legal advice.
App Store "App Privacy" label answers
For a typical Firebase Authentication integration, declare in App Store Connect:
- Contact Info > Email Address — purpose "App Functionality". Linked to the user: Yes. Used to Track You: No.
- Contact Info > Phone Number — only with phone auth. "App Functionality", Linked: Yes, Track: No.
- Contact Info > Name and User Content > Photos or Videos (profile photo URL) — if collected from the provider. "App Functionality", Linked: Yes, Track: No.
- Identifiers > User ID — the Firebase UID and federated provider UIDs. "App Functionality", Linked: Yes, Track: No.
- Identifiers > Device ID and Diagnostics — the IP/device data used for abuse detection maps to security use; declare under "App Functionality" / "Fraud Prevention, Security". Not used to track.
Firebase ships an Apple privacy manifest for its SDKs; Firebase Authentication is not an advertising SDK and none of its data is "Used to Track You".
Google Play Data Safety answers
In the Play Console Data Safety form, declare:
- Personal info > Email addresses — Collected: Yes. Shared: No. Purpose: Account management, App functionality. Users can request deletion.
- Personal info > Name and User IDs — Collected: Yes. Shared: No. Purpose: Account management, App functionality.
- Personal info > Phone number — only with phone auth. Collected: Yes. Shared: No.
- Photos — only if you store the provider photo URL. Collected: Yes. Shared: No.
- App info and performance / Device or other IDs — the IP and device data used for security. Collected: Yes. Shared: No. Purpose: Fraud prevention, security, and compliance. Some of this is processed ephemerally for abuse detection.
Mark "Can users request that their data be deleted?" as Yes. Firebase lets you delete a user and their authentication data through the client SDK, the Admin SDK, or the Firebase console.
Firebase Authentication-specific gotchas
- Account deletion is a store requirement. Apple Guideline 5.1.1(v) and Google Play both require an in-app way to delete the account. Build a deletion request page and wire it to Firebase's
deleteUser(client) or the Admin SDK. - Sign in with Apple needs token revocation on deletion. If a user signed in with Apple, deleting the Firebase user is not enough — you must also revoke their Apple tokens. Firebase exposes
revokeToken(withAuthorizationCode:), which calls Apple's revoke endpoint for you; because Firebase does not store the Apple token, prompt the user to reauthenticate first. See the Sign in with Apple clause. - Federated providers pull extra data. Google, Facebook and other providers can return more than name and email depending on the scopes you request; disclose whatever you actually receive and store.
- Phone auth adds SMS and integrity checks. It stores a phone number and uses Play Integrity / reCAPTCHA tokens, and SMS delivery involves telecom carriers as additional recipients.
- Identity Platform upgrade changes retention and logging. Upgrading to Google Cloud Identity Platform adds activity logging and multi-tenancy; review what is logged.
- You are the controller. Google is the processor; accuracy of your policy and store answers is your responsibility.
Related
See the sibling clauses for Sign in with Apple, AppsFlyer, Adjust and Branch. Build the deletion flow with the account deletion page generator, produce the full document with the privacy policy page generator, and read the Firebase privacy policy generator guide for the rest of the Firebase stack.