FullstackPhoenix

User Authentication for Phoenix SaaS Applications

phoenixauthenticationliveviewsaas

You're three days into a new SaaS prototype. The product idea is interesting, the LiveView demo is convincing, and now you need to ship a real signup, login, password reset, and "remember me" before anything else matters. The Phoenix phx.gen.auth generator gets you 80 percent of the way there — but you still have to extend the schema with the fields you actually need, decide how roles work, and figure out how the first admin gets created.

This feature handles that gap. It runs mix phx.gen.auth Users User users --live for you, then extends the generated User schema with the role enum, profile fields, locale, timezone, and admin bootstrap logic that every SaaS ends up adding by hand on day three.

A real account foundation, not just a login form

Authentication is rarely the interesting part of a SaaS — it is the part you have to get right before anything else can ship. By the time you actually need teams, billing, or an admin area, you want current_user to already carry a role, a name, a locale, and a stable place to attach more profile fields. This feature installs that shape from the start.

What This Feature Adds

  • A full mix phx.gen.auth Users User users --live run, producing the users table, UserAuth plug, LiveView sign-in / register / reset / settings pages, and a UserNotifier
  • An extended MyApp.Users.User schema with role (:user, :admin, :superuser), name, locale, timezone, embedded data for ad-hoc profile fields, and soft-delete support
  • A custom profile changeset so updating "name" or "timezone" never touches authentication-sensitive fields
  • Admin bootstrap config — an admin_emails list and a "promote first user to superuser" toggle — wired through config/config.exs
  • Test coverage from phx.gen.auth plus the extensions to it

How It Fits Into Your Phoenix Application

The feature builds directly on the standard Phoenix authentication generator instead of replacing it. That means the conventions, helpers, and test patterns you already know from Phoenix work unchanged — current_scope, require_authenticated_user, Phoenix.LiveView on_mount hooks, the UserAuth plug. The extensions sit on top: the role enum drives admin gating later, and the data embed gives you a place to add fields without writing another migration the next time a new product requirement lands.

Splitting profile updates into their own changeset matters more than it looks. It is what lets a "settings" page accept a timezone change without forcing the user to re-enter their password.

Installation Notes

  • No external feature dependencies — this feature is the foundation that other features (teams, admin, notifications, OAuth, payments) build on.
  • Set your admin email(s) in config/config.exs before the first user signs up, otherwise the first user is just a regular :user.
  • Database migrations are generated by phx.gen.auth; run mix ecto.migrate after installation.
  • Templates use MyApp / my_app placeholders that the installer rewrites for your real app name.

Build This With Live SaaS Kit

Install saas_kit, then mix saaskit.feature.install authentication to stand up Phoenix authentication with profile fields and role-based access in a single step.