Course B · Module B1 Production · Lesson 6 of 18
Real users need real logins. This lesson shows you how to add them safely — without building any login security yourself.
The moment you move from a private prototype to an app real people use, you need authentication — a way for users to prove who they are and get in. Get it wrong and strangers can see each other's data, or worse. Get it right and it takes an afternoon, not a week. Your single win here: by the end you'll understand the two halves of auth, know the golden rule that keeps you safe, and be ready to wire up a provider so logins just work.
People use "auth" as one word, but it covers two different jobs:
The login step. The user proves their identity with a password, a Google account, or a magic link. Your app gets back a confirmed answer: this is Maya, user ID 4821.
Once you know who they are, you decide what they're allowed to see or touch. A free user can't reach the premium dashboard. An admin can delete records; a regular user can't.
Both matter. Most early-stage apps get authentication working and then forget authorization entirely — which is how free users end up reading paying customers' invoices. Plan for both from day one.
Imagine you're running a members-only club. You could build your own vault, print membership cards, and guard the door yourself. Or you could hand all of that to a specialist security company that does nothing else, has passed every audit, and carries the liability if something goes wrong.
Storing passwords is the vault. Never build your own vault. The specialist companies are called auth providers, and using one is the right call every time — no matter how good your AI coding is.
When you store a password yourself, you're responsible if your database leaks. An auth provider stores a cryptographic hash (a scrambled fingerprint) on servers designed for exactly this purpose, and they handle password resets, brute-force protection, rate limiting, and compliance. You get all of that for free by not rolling your own.
Three providers dominate the indie and startup space. All three have a generous free tier and take less than a day to integrate:
All three follow the same basic flow: you register your app, get an API key (see B5), add their library to your code, and replace your hand-rolled login form with their component. Your AI assistant can generate the wiring from the provider's quickstart docs — paste the URL in and ask it to follow the guide.
Once a user logs in, your app needs to remember them as they click around — that's a session. Think of it like a wristband at a music festival: you prove your ticket once at the gate, get a wristband, and every tent you walk into checks the wristband instead of your ticket.
The wristband in web apps is a token — a short encrypted string your browser stores and sends along with every request. Your auth provider creates and validates the token; you just check "is there a valid token?" before showing protected pages. Sessions expire (the wristband has an end time), forcing a re-login after some period of inactivity. Your provider handles all of this automatically.
Answer before opening — recalling it is what makes it stick.
Authorization. Authentication confirmed who they are; authorization controls what they can access. The rule that says "free users can't see this page" is missing or misconfigured.
Because you'd be responsible for securing them — and auth providers are specialists who store only cryptographic hashes, carry the compliance burden, and handle brute-force protection and resets automatically. You get all that for free by not rolling your own.
A session token. After login, the provider issues a short encrypted token stored in the browser. Every page checks for a valid token instead of asking for the password again. The session eventually expires and forces a fresh login.
Read this next (primary source)
Clerk Documentation — start with the quickstart for your framework. It's the clearest end-to-end walkthrough of how a modern auth provider connects to a real app, even if you end up choosing a different provider. See RESOURCES.md for more.
New terms this lesson — authentication, authorization, session, token, social login — are in the course glossary. Keep it open.