Kembo
BlogDocsSign inSign up
Kembo

Mobile auth in minutes. Google and Apple sign-in for Expo, Flutter, Capacitor, and Web.

Product

  • Documentation
  • Blog
  • Pricing
  • Get started

Legal

  • Privacy Policy
  • Terms of Service
  • DPA
  • Data Deletion

© 2026 Kembo

Operated by ByteStronauts

← All posts
August 8, 2026·8 min read

Flutter authentication without the boilerplate: Google and Apple sign-in

Flutter gives you the sign-in widgets, but the hard parts — verifying tokens, minting sessions, secure storage, and per-platform OAuth config — are still yours. Here is how Flutter authentication really works and how to skip the repetitive plumbing.

FlutterDartauthenticationGoogle sign-inSign in with Applemobile auth

Flutter has a healthy ecosystem of auth packages, which can make authentication feel solved. Add a dependency, drop in a button, get a credential back. But that credential is only the first third of the job. The parts that make authentication real— verifying the token, creating a session you control, storing it securely, and handling each platform's OAuth quirks — are still entirely yours.

This post maps the full picture of Flutter authentication, separates what the packages do from what you still own, and shows how to get Google and Apple sign-in working without rebuilding the same plumbing in every app.

What the packages give you (and what they don't)

Packages like google_sign_in and sign_in_with_applehandle the front half: launching the provider's flow and returning a credential — an ID token or authorization code. That is genuinely useful. Here is what they do not do:

  • Verify the token. A credential from the device is not trustworthy until your backend verifies its signature, audience, and expiry.
  • Create your session. You still mint your own access and refresh tokens so the rest of your app has a consistent identity.
  • Store securely. The package hands you tokens; keeping them safe is on you.
  • Configure the providers. The OAuth clients, fingerprints, Services ID, and keys are still your setup.

Platform setup is still platform setup

Flutter is one codebase, but OAuth does not care. You configure each platform separately:

  • Android. Google needs your package name and the SHA-1 fingerprints — debug, upload, and crucially the Play App Signing key, or sign-in breaks for store users. See the Google sign-in post for why this is the number one Android bug.
  • iOS. Google needs the reversed-client-ID URL scheme; Apple needs the Sign in with Apple capability on your App ID.
  • Apple web flow. For Android and the backend exchange, you still need a Services ID, a verified domain, a return URL, and a .p8 key — exactly as in the Sign in with Apple deep-dive.

The first-authorization trap, in Dart too

Apple returns the user's name and email only on the first sign-in, regardless of language or framework. In Flutter it is just as easy to read those fields into your model on every login and end up with blank returning users. Persist them server-side the first time and never rely on them again.

Verify on the backend, always

The single most important rule: never trust a credential just because it arrived from the device. Send the ID token or authorization code to your backend, verify the signature and that the audience matches your client, check expiry, and only then create a session. Skipping this is how apps get spoofed sign-ins.

Then issue your own tokens and manage them with the lifetimes and rotation from our session management post.

Secure storage in Flutter

Use flutter_secure_storage (or an equivalent) so tokens land in the iOS Keychain and Android Keystore rather than shared preferences in plaintext. As on every platform, a refresh token in unencrypted storage can leak through a backup — the same hole we flagged for native and Expo apps.

How Kembo's Flutter SDK removes the boilerplate

Kembo gives Flutter the same drop-in experience as every other platform. The Dart SDK ships an AuthView, a KemboProvider, and secure token handling, so you get the whole flow — not just the front half a package gives you.

  • AuthView renders Google and Apple sign-in with correct prominence; KemboProvider exposes the signed-in user to your widget tree.
  • Token verification and session creation happen server-side, so you are not implementing audience checks in Dart.
  • Tokens are stored in secure storage and refreshed automatically — no rotation races to debug.
  • The OAuth client, fingerprint, and Services ID setup lives on Kembo's side, so the per-platform config does not live in your repo.

One identity model across platforms

If you ship Flutter alongside a web or Expo app, a hosted auth layer gives every client the same user model and session rules. That means a person who signs in on iOS and later on the web is one user, not two — without you writing reconciliation logic.

Let Flutter be the fun part

Flutter's packages get you a credential; production authentication needs verification, your own sessions, secure storage, and a pile of per-platform OAuth config. Knowing exactly where the package stops and your responsibility starts is what keeps Flutter auth from becoming a multi-week detour.

To skip the detour, start a free Kembo project, add the Flutter SDK, and get Google and Apple sign-in with secure sessions out of the box. Next week we leave auth aside and talk activation: onboarding that survives churn.

Ready to skip the Wednesday OAuth panic? Create a free Kembo project.