Authentication is the one part of a no-code app where cutting corners shows up immediately — as a security hole, a locked-out user, or an App Store rejection. FlutterFlow gives you two credible native paths: Firebase Authentication and Supabase Auth. Both are production-ready; which one you pick should depend on what database you’re already using, not which logo you like better.
FlutterFlow’s Two Native Auth Paths
| Firebase Auth | Supabase Auth | |
|---|---|---|
| Best paired with | Firestore | Supabase Postgres |
| Row-level security | Firestore security rules (JSON-like syntax) | Postgres RLS (real SQL policies) |
| Social logins supported | Google, Apple, Facebook, email link | Google, Apple, GitHub, email link |
| Email verification flow | Built-in, one toggle | Built-in, configurable templates |
| Good fit | Simpler data models, fastest to ship | Apps that need relational data and complex queries |
Step-by-Step: Firebase Email/Password + Google Sign-In
- In FlutterFlow, go to Settings > Firebase and connect or create your Firebase project.
- Under Authentication, enable the sign-in methods you need — start with Email/Password, then add Google.
- For Google Sign-In, generate the OAuth client ID in the Google Cloud Console and paste it into FlutterFlow’s auth settings; FlutterFlow handles the SDK wiring.
- Build your sign-up and login pages using FlutterFlow’s built-in Auth widgets, or wire custom UI to the “Create Account” and “Sign In” actions.
- Turn on “Email Verification Required” in the auth settings if you don’t want unverified accounts touching real data.
- Set Firestore security rules so reads/writes check
request.auth.uid— FlutterFlow’s default rules are permissive during development and need tightening before launch.
Step-by-Step: Supabase Auth with Row-Level Security
- Connect your Supabase project under Settings > Supabase in FlutterFlow.
- Enable the auth providers you want in the Supabase dashboard (Authentication > Providers).
- Use FlutterFlow’s Supabase Auth actions (“Sign Up,” “Sign In,” “Sign Out”) on your auth pages — these map directly to Supabase’s auth API.
- In the Supabase SQL editor, write actual row-level security policies, e.g.
USING (auth.uid() = user_id)on every table that stores user-owned data. This is the step most no-code builders skip, and it’s the difference between “looks secure” and “is secure.” - Test policies with the Supabase dashboard’s “Run as user” feature before shipping — a policy that works for the service role but not the anon/authenticated role will silently break your app in production.
Adding Social Logins — the Apple Requirement Nobody Reads
If your app ships to iOS and offers any third-party sign-in (Google, Facebook, etc.), Apple’s App Store Review Guidelines require you to also offer “Sign in with Apple” as an equivalent option. This isn’t optional and isn’t new, but it’s the single most common reason FlutterFlow apps get rejected on first submission. Add it in the same auth settings panel alongside Google/Facebook — the incremental setup cost is small compared to a rejected build.
Common Pitfalls
- Shipping with default/open security rules. Both Firestore and Postgres start permissive in dev mode — lock them down before launch, not after.
- Hardcoding API keys in client-visible config. Public anon keys are fine to expose (that’s how Supabase is designed); service-role keys and Firebase Admin credentials are not — never put those in a FlutterFlow client action.
- No email verification gate. Without it, spam accounts and typo’d emails pile up in your user table with no way to reach them.
- Forgetting Apple Sign-In. Covered above, but worth repeating — it’s the rejection every FlutterFlow forum thread mentions.
- Testing auth only as the developer. Auth bugs (session expiry, password reset emails landing in spam, RLS blocking a legitimate read) mostly surface only when a genuinely new user goes through the flow cold.
FAQ
Can I switch from Firebase Auth to Supabase Auth later? Technically yes, but migrating user accounts and re-hashing/resetting passwords is real work — pick based on your database choice up front rather than planning to switch.
Do I need row-level security if my app has no sensitive data? Yes — even a simple to-do app should scope data per user, or any authenticated user can read or overwrite anyone else’s records via the API.
Is FlutterFlow’s built-in auth UI good enough for production? It’s a solid starting point; most teams end up restyling it to match brand, but the underlying auth logic doesn’t need to change.
Verdict
Choose Firebase Auth if you’re already on Firestore and want the fastest path to a working login flow. Choose Supabase Auth if your data is genuinely relational and you want real SQL-based row-level security instead of Firestore’s rule syntax. Either way, the actual work isn’t flipping the auth toggle on — it’s writing and testing the security rules that decide who can read what, and remembering that Apple requires Sign in with Apple the moment you offer any other social login.
