Expo authentication in 2026: a practical guide to social login

Expo makes most of mobile development delightful. Authentication is the place where the delight runs out. The moment you want real Google and Apple sign-in — not a toy demo — you collide with development builds, redirect schemes, native modules, and secure storage. None of it is impossible; all of it is fiddly and easy to get subtly wrong.

This is the practical, current guide to social login in Expo: the pieces you actually need, the order to do them in, the things that trip everyone up, and how to get a working sign-in screen without spending a week on plumbing.

First: you need a development build

The biggest early misunderstanding is trying to test real OAuth inside Expo Go. Native sign-in modules — the Apple system sheet, native Google sign-in — are not part of the Expo Go sandbox. To use them you need a development build (a custom dev client) or a production build on a real device.

• Plan to build to a physical device early. Simulators do not exercise the native sheets the same way, and Apple sign-in in particular behaves differently there.
• Once you are on a dev build, config plugins can apply the native changes (URL schemes, entitlements) at build time so you never touch Xcode or Gradle by hand.

The two flows you will deal with

Expo social login comes in two flavors, and most apps use both:

• Native sign-in. The platform-provided experience — the Apple sheet on iOS, native Google sign-in. Best UX, but requires the native module and correct entitlements.
• Web-based OAuth via an auth session. Opens a secure in-app browser, returns to your app through a redirect URI. This is what powers providers without a native module and the Android/web paths.

For Apple specifically, remember the rule from our Sign in with Apple deep-dive: native sheet on iOS, web flow elsewhere, and capture name and email on the first authorization because you only get them once.

Redirect URIs: the number one Expo headache

The web flow returns to your app via a redirect, and getting that scheme exactly right is where most time disappears. Two rules save you hours:

1. Set a stable URL scheme for your app and use it consistently. Ad-hoc schemes that differ between dev and production are a recipe for redirect_uri_mismatch.
2. Log the redirect URI your app actually generates and register that exact string with the provider — never type it from memory. (See the Google sign-in post for why exactness matters.)

Store the tokens correctly

After sign-in you hold tokens, and where you put them matters more than the sign-in itself. Use Expo's secure store, which maps to the iOS Keychain and Android Keystore — never plain AsyncStorage, which can be read on a compromised device or swept into a backup.

And do not stop at storing the access token. You need refresh and rotation so users stay logged in for weeks without a long-lived token riding every request. We covered the whole pattern in session management for mobile apps.

The full checklist for self-hosting it

1. Create a development build; test on a physical device.
2. Configure Google clients (web, Android with SHA-1s, iOS).
3. Configure Sign in with Apple (App ID capability, Services ID, key, return URL).
4. Pin a URL scheme and register exact redirect URIs.
5. Implement native sheets on iOS, web flow on Android/web.
6. Verify tokens server-side and mint your own session.
7. Store credentials in the secure store; add refresh + rotation.
8. Add an in-app account-deletion path before you submit.

That is a real week of work — and none of it is your product. It is the same checklist for every Expo app anyone has ever shipped.

The shortcut: Kembo's Expo SDK

Kembo collapses that checklist into a drop-in component. The Expo SDK gives you an AuthView that renders Google and Apple sign-in with correct prominence, runs the right flow per platform, verifies tokens server-side, and stores sessions securely.

• Drop in AuthView for the sign-in screen; read the signed-in user from a hook anywhere in your app.
• Secure storage, refresh, and rotation are handled by the SDK — no Keychain wiring, no refresh races.
• The OAuth client and fingerprint setup happens on Kembo's side, so the redirect and SHA-1 bugs never reach your app.
• A built-in delete-the-current-user action covers the store account-deletion requirement.

Sign-in should not be the hard part

Expo authentication is entirely doable by hand — dev build, native sheets, web flow, exact redirects, secure storage, refresh. It is just a lot of undifferentiated work that every app repeats. Know the pieces so you can debug them, then decide whether building them again is the best use of your week.

If it is not, start a free Kembo project, drop AuthView into your Expo app, and have working Google and Apple sign-in today. Next week, the same treatment for Flutter: Flutter authentication without the boilerplate.