User accounts & login

The message that changes everything

A week after going live, Tom receives the piece of feedback that comes up most often. Lina, a seventh-grader, writes to him: "Sir, I checked off all my habits on the library computer, and in the evening on my phone, everything was gone!" Tom understands immediately: he chose local storage in chapter 3, and localStorage keeps the data in each device's browser. The school library computer and Lina's phone are two separate worlds that don't talk to each other. For the app to follow Lina everywhere, it must be able to recognize her — and recognizing someone, on the web, is called a user account.

Remember: in chapter 3, "user account" was on the list of trap words to ban from your v1. That wasn't a permanent prohibition, it was a matter of timing. Tom first built, deployed, and gathered real feedback. Now the need is no longer a hypothesis: it's his users' number one request. That's exactly the right order — complexity is justified by a proven need, never by a "just in case". You'll see that this complexity, approached properly, is well within your reach.

Authentication: what really happens

Three vocabulary words will transform your dialogues with the AI on this topic. Authentication is proving who you are ("I really am lina@school.edu"). The session is staying recognized for a while without having to prove it on every click — it's what saves you from logging back in every thirty seconds. Authorization is what you're allowed to see or do once recognized ("Lina sees HER habits, not other people's"). When you use these words in your prompts, the AI will know exactly what you're talking about.

Behind a simple login screen actually hides a whole system: sign-up, login, logout, recovery when someone forgets, protection against bots, secure credential storage… Building all that yourself is long, and above all dangerous: the slightest mistake exposes your users' data. The good news is that nobody builds it themselves today — not even professionals. Everyone relies on specialized services that have solved the problem once and for all.

Ready-made authentication services

These services are sometimes called BaaS (Backend as a Service): they provide your app with the server-side building blocks it needs — including authentication — without you having to manage a server. You create an account with them, grab two keys, and your app delegates all the sensitive work to them. Three names come up everywhere, and the AI knows them by heart:

For this course, we'll follow Tom on Supabase: its free tier easily covers a classroom app, and having authentication and the database in the same place will simplify chapter 7. But remember the principle more than the name — the method you're about to learn applies identically with the competitors.

Which login method for your users?

There are three main ways to log in, and the right choice depends entirely on who your users are. The classic password is universal but painful: people forget it, reuse it everywhere, and you have to handle recovery. Logging in via Google or Apple ("OAuth") is comfortable… provided your users have a Google account they actually use. The magic link removes the password altogether: the user enters their email, receives a link, clicks, and they're logged in.

• Password: universal, but frequent forgetting and mandatory recovery management.
• Google / Apple login: one click and it's done — if your users have (and use) these accounts.
• Magic link: nothing to remember, nothing to forget. Perfect for occasional or young users. Only requirement: access to their inbox.

Tom picks the magic link: his students all have an address provided by the school, and "forgot my password" would have become his second job. Ask yourself the same question for your own app: which method creates the least friction for YOUR users? There is no universal right answer, only a right answer for your audience.

sequenceDiagram
  participant E as Student
  participant A as Tom's app
  participant S as Supabase service
  E->>A: Enters their email address
  A->>S: Requests a magic link
  S-->>E: Sends the email with the link
  E->>A: Clicks the received link
  A-->>E: Session opened and habits displayed

Integrating authentication with the AI

The approach takes three steps: create your project on Supabase (an account, one click on "New project"), grab your two access keys, then ask the AI to wire it all up. As with deployment in chapter 5, you don't have to memorize the procedure — you ask for step-by-step guidance suited to your level. Here is Tom's complete prompt:

I want to add user accounts to my habit-tracking app.
Context: HTML/CSS/JS app deployed on Vercel, data in localStorage for now.
Use Supabase Auth with magic link login, no passwords.
What I want:
1. a simple login screen: email field + "send me my link" button
2. after clicking the link received by email, the user comes back to the app, logged in
3. a discreet "log out" button at the top of the page
4. if the user isn't logged in, they see the login screen; otherwise, their habits
IMPORTANT: don't touch the data yet — we keep localStorage for now.
First guide me through creating the Supabase project and finding my two keys, step by step, before writing any code.

The line "don't touch the data yet" is strategic. Adding authentication AND migrating the data at the same time means two big changes at once — exactly what chapter 4 taught you to avoid. This chapter wires up user recognition; chapter 7 will take care of their data. One step at a time, even when the staircase is tall.

API keys: your first secrets

When creating your Supabase project, you'll come across two keys. The public key (called "anon") identifies your app: it can live in browser code, that's what it's designed for. The secret key (called "service_role") grants ALL rights over your project: it must never, ever appear in code visible to a browser. These secrets go into a special file, the .env, which Git ignores:

# .env file — stays on your machine, never published
SUPABASE_URL=https://yourproject.supabase.co
SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIs...   # public: OK browser-side
SUPABASE_SERVICE_ROLE_KEY=eyJzZXJ2aWNl...   # SECRET: never browser-side

Testing the flow like a user

Authentication is tested end to end, no shortcuts: enter a real address, go find the email (also check the spam folder, that's the classic blocker), click the link, verify you arrive logged in. Then log out and start over. Finally, the decisive test: open the app in two different browsers with two different addresses, and verify that each one has its own session. If something gets stuck, apply the chapter 4 method — the four-point bug report. Here's the version adapted to authentication:

Login bug to fix.
What I do: I enter my address, I receive the magic link email, I click the link.
What I expected: to come back to the app, logged in.
What happens: I come back to the app but I still see the login screen.
Error in the console: [paste the exact red line here, if there is one]
Check the redirect URL configuration in Supabase as a priority — my deployed site's URL is https://my-app.vercel.app — and tell me what to fix, step by step.

This prompt shows a next-level reflex: Tom steers the diagnosis ("check the redirect URLs as a priority") because that's THE classic cause of this symptom — the service sends the user back to an address that doesn't match the deployed site. You don't have to know these classic causes: ask the AI "what are the three most frequent causes of this problem?" and it will list them for you.

What awaits you in the next chapter

At the end of this stage, Tom's app recognizes each student… but their habits still live in each device's localStorage. Lina can log in at the school library and on her phone, but she doesn't see the same data there yet. The second half of the solution is missing: an online database, where each account's habits will be stored once and for all, reachable from anywhere. That's the whole agenda of chapter 7 — and you've already laid the ideal foundation to welcome it.