What Is Authentication? A Plain-English Explanation

The one-sentence version: proving who you are, not what you're allowed to do

Authentication answers exactly one question: is this really you? A password matching what's on file, a code from an email link, a passkey on your device, all prove identity the same underlying way, by checking something only the real account holder could produce. What happens after that, whether you can see another user's data or reach an admin page, is a separate question entirely, called authorization, and it's genuinely common for a system to get one right and the other wrong.

Two ways your app remembers you're logged in: sessions and tokens

Once you've authenticated, your app needs a way to recognise you again on every following request, without asking for your password each time. A session is the older, still-common approach: the server keeps a record of who's logged in, tied to a unique ID stored in your browser's cookie, and checks that record on each request. A token, most often a JWT, works differently: it's a signed piece of data containing your identity that your app can verify on its own, without a server-side lookup, which is why it scales more easily across separate services. Neither is universally "better," they're different tools for the same job, and which one you're using is usually decided by your platform's own authentication provider, not something you choose directly.

Where this actually happens on your AI-built app

Lovable and Bolt.new both use Supabase Auth by default, which issues a short-lived JWT access token, typically valid for 5 minutes to an hour, plus a longer-lived refresh token used to silently get a new one once it expires, so you stay logged in without re-entering a password constantly. Base44 ships authentication as a built-in backend feature the same way it ships its database and storage, no separate service to connect. Either way, your AI agent wires this up by prompting for it, connecting sign-up, login and "who's currently logged in" checks to your app's own pages, not by writing password-handling code from first principles.

The one rule that matters again here: never trust the frontend to decide who's authenticated

The same rule this site's guide to why you can't put an API key in the frontend covers applies directly to authentication too: a frontend check like "hide this button if not logged in" is a display decision, not a real security boundary, since a visitor's own browser fully controls what runs there. The actual enforcement has to happen on the backend, and for data specifically, this is exactly what this site's guide to what a database is covers under Row Level Security: a database rule, not a frontend check, deciding which rows a given authenticated user is actually allowed to see.

Not every login needs to be built from scratch

Social login, signing in with an existing Google account instead of creating a new password, and passkeys, device-based authentication with no password involved at all, are both increasingly common alternatives worth considering before defaulting to a traditional email-and-password form. Most platforms this site documents support at least social login as a real, tested option your AI agent can wire up the same way it handles password-based login, not a separate, harder feature to add later.