Adding Google Sign-In to Your Expo App: the Short Answer
Adding Google Sign-In to your Expo app is four steps: create OAuth 2.0 client IDs in the Google Cloud Console, install an authentication library that speaks Google's OAuth flow, launch that flow when the user taps your sign-in button, and take the ID token Google returns and send it to your backend to create a session. Google does not run inside your app the way a native SDK might - it opens a secure browser session, the user picks their account, and the OS hands the result back to your app. From your side it is configuration first, then one button and one async call.
The work that actually breaks first-time builders is not the button. It is the OAuth client setup in Google Cloud. Google issues a separate client ID for iOS, for Android, and for web, and each one is tied to a bundle identifier or a redirect URI that has to match your app exactly. Get those client IDs right and the sign-in flow is standard token handling. Get one wrong and Google returns a redirect_uri_mismatch or invalid_client error before the user ever sees an account picker.
Step 1 - Create Your OAuth Client IDs in Google Cloud
Everything starts in the Google Cloud Console, not in your code. Create a project, configure the OAuth consent screen, and then create OAuth 2.0 client IDs - one for each platform your app runs on. This is the part that is pure configuration and has to be exact, because the client ID and its registered bundle identifier or redirect URI are what Google checks before it will complete a sign-in.
- Create a Google Cloud project and open APIs and Services, then Credentials.
- Configure the OAuth consent screen first. Set the app name, support email, and the scopes you need - for basic sign-in that is email and profile. Google will not issue usable credentials until the consent screen is set up.
- Create an iOS OAuth client ID and enter your app's exact bundle identifier (the same one in your app.json ios.bundleIdentifier).
- Create an Android OAuth client ID with your package name and the SHA-1 fingerprint of your signing key. For EAS builds, get the SHA-1 from the credentials EAS manages for your app.
- Create a Web OAuth client ID as well. Several Expo auth flows use the web client ID as the audience the ID token is issued for, so you often need it even for a mobile-only app.
Step 2 - Install the Auth Module and Wire the Client IDs
Install an authentication library that handles Google's OAuth flow and pass it the client IDs you created. The library owns the messy part - opening a secure browser session, handling the redirect back into your app, and returning the tokens - so your job is to give it the right client ID for each platform and a button to trigger it. Install the library the Expo way (npx expo install) so it pins a version compatible with your SDK and registers any config plugin the native build needs.
- Install your chosen auth library with npx expo install so the version matches your Expo SDK and its config plugin is registered for the native build.
- Provide the iOS, Android, and web client IDs to the library's config, matched to the platform the app is running on. Keep the raw client IDs out of source control by reading them from environment variables at build time.
- Add any required config plugin entry to app.json and confirm your ios.bundleIdentifier and android.package match what you registered in Google Cloud exactly - a single character difference is enough to fail the flow.
- Make a fresh development build or EAS Build after wiring the config. The native redirect handling is baked into the build, so it does not take effect on a JavaScript reload or in a generic Expo Go session.
Step 3 - Launch the Flow and Handle the Token
When the user taps your Google button, call the library's sign-in function. It opens the secure browser session, the user chooses their Google account, and the flow resolves with a result that contains an ID token - a signed JWT that proves the user authenticated with Google. That ID token is the one field that matters for your account system. You do not trust it on the device; you send it to your backend, which verifies it and creates your session.
What you get back from a Google sign-in and what to do with it
| Value | What it is | What you do with it |
|---|---|---|
| ID token | A signed JWT containing the user's Google account ID, email, and name | Send it to your backend to verify against Google's public keys and create your session |
| Google user ID (sub) | A stable identifier for this user, inside the ID token | Use it as your primary key for the account - it never changes for this user |
| Access token | A token for calling Google APIs on the user's behalf | Only needed if you call Google services (Drive, Calendar); ignore it for plain sign-in |
| email / name | Profile fields inside the ID token | Store them, but key the account off the stable user ID, not the email |
The verification belongs on your backend, not in the app. Your app sends the ID token up; your server checks the token's signature against Google's public keys, confirms the token's audience matches your client ID, and only then creates a session. Trusting the raw token on the device means anyone who can call your API can claim to be any user. Treat the app side as collecting the token and the server side as the source of truth - the same rule that applies to any social login.
Google Sign-In and Sign in with Apple Go Together
On iOS, adding Google Sign-In is not a standalone decision. App Review Guideline 4.8 says that any app using a third-party login service must also offer a login option that limits data collection to the user's name and email and lets them keep their email private. Google Sign-In is a third-party login. Sign in with Apple meets the privacy bar. So the practical rule is: if you add Google on iOS, add Apple alongside it in the same release.
- Offer both buttons on your iOS login screen: Google Sign-In and Sign in with Apple. This is what keeps you clear of a Guideline 4.8 rejection.
- On Android you are not bound by Guideline 4.8, and Sign in with Apple's native button is iOS-only, so your Android screen shows Google plus your other methods.
- Key both providers off a stable user ID on your side, and decide how you merge accounts if the same person signs in with Google once and Apple another time - matching on email is the usual approach, with the caveat that Apple can hand you a private relay address.
Let Claude Code Wire the Whole Flow
The Google Sign-In flow is mechanical and has a fixed shape, which is the kind of work Claude Code handles well from the desktop app. Describe what you want - 'add Google Sign-In to my login screen and create a session on my backend' - and it installs the auth library, reads the client IDs from environment variables, renders the button, triggers the flow, and writes the backend token exchange. The one part it cannot do for you is the Google Cloud console setup, because that lives in your account, but it can tell you exactly which client IDs to create and where to paste them.
- Have Claude Code install the auth library and wire the iOS, Android, and web client IDs from environment variables, so nothing sensitive lands in source control.
- Ask it to render the Google button and trigger the sign-in flow, returning the ID token to your session logic rather than trusting it on the device.
- Tell it to add Sign in with Apple in the same pass, because Guideline 4.8 means you need both on iOS - let it wire the two buttons and the account-merge logic together.
- Ask for the backend verification stub too: the endpoint that takes the ID token, verifies it against Google's public keys, checks the audience matches your client ID, and returns your session.
Common Google Sign-In Mistakes and How to Avoid Them
Google Sign-In bugs cluster around a few predictable mistakes, and nearly all of them trace back to a mismatch between what you registered in Google Cloud and what your app actually sends.
Common Google Sign-In mistakes in an Expo app
| Mistake | What goes wrong | Fix |
|---|---|---|
| Wrong or missing client ID for the platform | The flow fails with invalid_client before the account picker appears | Create one client ID per platform and pass the right one for iOS, Android, and web |
| Android SHA-1 from a local keystore, not EAS | Sign-in works in development but fails in the production build | Register the SHA-1 from the signing key EAS uses for your release build |
| Bundle identifier or package name mismatch | redirect_uri_mismatch or an authorization error | Match ios.bundleIdentifier and android.package to the values registered in Google Cloud exactly |
| Trusting the ID token on the device | Anyone who can call your API can impersonate a user | Send the ID token to your backend and verify signature and audience before creating a session |
| Adding Google login without Apple on iOS | Guideline 4.8 rejection for offering a third-party login with no privacy-preserving equivalent | Offer Sign in with Apple alongside Google Sign-In on iOS |
TL;DR
Add Google Sign-In to your Expo app by creating OAuth 2.0 client IDs in Google Cloud (one each for iOS, Android, and web), installing an auth library with npx expo install, wiring the client IDs from environment variables, and launching the flow on tap. Take the ID token Google returns and send it to your backend, which verifies the signature against Google's public keys and checks the audience matches your client ID before creating a session - never trust the token on the device. The most common failures are a client ID or bundle identifier mismatch and an Android SHA-1 taken from the wrong keystore, so match everything to Google Cloud exactly and use the SHA-1 from your EAS signing key. Because Guideline 4.8 requires a privacy-preserving login wherever you offer a third-party one, add Sign in with Apple on iOS in the same release. Claude Code wires the library, the button, the token exchange, and the Apple flow in one pass; you do the Google Cloud setup and confirm the backend checks the audience claim.
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
Do I need separate Google client IDs for iOS and Android?
Yes. Google issues OAuth 2.0 client IDs per platform, and each is tied to a bundle identifier (iOS) or package name plus SHA-1 fingerprint (Android). Create an iOS client ID, an Android client ID, and usually a web client ID too, because several Expo auth flows use the web client ID as the audience the ID token is issued for. Pass the correct client ID for the platform the app is running on.
Why does Google Sign-In work in development but fail in my production build?
The usual cause is the Android SHA-1 fingerprint. If you build with EAS, the signing key for your release build is managed by EAS, not your local machine, so a SHA-1 from your debug keystore will not match. Register the SHA-1 from the credentials EAS uses for the build you ship. A client ID or bundle identifier mismatch between your app and Google Cloud produces the same development-works, production-fails pattern.
Where should I verify the Google ID token?
On your backend, never in the app alone. Your app collects the ID token and sends it to your server, which verifies the signature against Google's public keys, confirms the token's audience (aud) matches your client ID, and only then creates a session. Trusting the token on the device means anyone who can call your API can impersonate a user. A verifier that skips the audience check will accept a valid Google token issued for a different app.
Do I have to add Sign in with Apple if I add Google Sign-In?
On iOS, effectively yes. App Review Guideline 4.8 requires that any app offering a third-party login (Google counts) also offer a login that limits data collection to name and email and lets the user keep their email private. Sign in with Apple meets that bar. Shipping Google login alone on iOS is a common rejection, so plan to add both in the same release.
Does Google Sign-In work on both iOS and Android from one Expo codebase?
Yes. You build both platforms from one Expo project, and the auth library selects the right client ID per platform. The difference is your login screen: on iOS you show Google plus Sign in with Apple (for Guideline 4.8), and on Android you show Google plus your other methods, since Sign in with Apple's native button is iOS-only.
Can I test Google Sign-In in Expo Go?
The full native redirect handling needs a build that includes your config, which a development build or EAS Build provides. The generic Expo Go app does not carry your app's native configuration, so the OAuth redirect can fail there. Make a development build of your own app and test the whole flow, including the production Android signing key, on a real device before you submit.
Last reviewed by David on September 16, 2026
