Day 13 of 28 Β· Vibe Coding Challenge
User Authentication
β± 7 min
π Intermediate
Authentication is the feature that turns a tool into a product. Once users can sign up and log in, they have their own data, their own settings, their own experience. It's also the feature most people think is too hard to build.
It's not. Not with AI.
What authentication actually means
Authentication answers one question: "Who are you?"
When you log into Netflix, it knows you're you β so it shows your watchlist, your recommendations, your profile. That's authentication.
The components:
Sign up β Create a new account (usually email + password)
Log in β Prove who you are (enter your credentials)
Session β Stay logged in so you don't have to re-enter your password on every page
Log out β End the session
Protected routes β Pages only logged-in users can see (like a dashboard or settings)
Knowledge Check
What's the difference between a page with authentication and one without?
A
Authenticated pages can show personalized content for each user β their data, their settings, their account
B
Authenticated pages load faster
C
Authenticated pages have better design
D
There's no practical difference
Without auth, every visitor sees the same thing. With auth, each user gets a personalized experience β their own data, preferences, and content. That's the foundation of every product from social media to project management tools.
The easy way β third-party auth
You don't need to build authentication from scratch. Services like Supabase Auth, Clerk, and NextAuth handle all the hard parts β password hashing, session management, OAuth, email verification β so you just plug them in.
Add user authentication to my app using Supabase Auth. I need:
- Sign up with email and password
- Log in
- Log out button in the nav bar
- Protect the /dashboard route β redirect to /login if not authenticated
- Show the user's email in the nav bar when logged in
Authentication added β
π **Sign up page** (/signup)
- Email + password fields
- "Already have an account? Log in" link
- Error messages for weak passwords and existing accounts
π **Login page** (/login)
- Email + password fields
- "Don't have an account? Sign up" link
- Error message for wrong credentials
πͺ **Logout** β Button in nav bar, clears session
π‘οΈ **Protected route** β /dashboard redirects to /login if not authenticated
π€ **User email** β Shown in nav bar when logged in
Supabase handles password hashing, session tokens, and security. Try signing up!
β» Replay conversation
Sign up, log in, social auth β all from one prompt using Supabase Auth.
Knowledge Check
Why use a service like Supabase Auth instead of building authentication yourself?
A
Building it yourself is illegal
B
You can't build auth without Supabase
C
Auth has critical security requirements β password hashing, session management, token security β that are easy to get wrong
D
Supabase Auth is faster for users
Authentication is one of the few things where "good enough" isn't good enough. A single security mistake β storing passwords in plain text, weak session tokens, missing rate limiting β can expose all your users' data. Auth services handle these security requirements so you don't have to.
Social login β "Sign in with Google"
Users hate creating new accounts. Social login lets them sign in with accounts they already have β Google, GitHub, Apple, or others.
Add "Sign in with Google" and "Sign in with GitHub" buttons to the login page. Use Supabase Auth OAuth. Keep the email/password option too. Make the social login buttons look polished β Google and GitHub brand colors and logos.
Social login added β
π΅ **Google button** β White background, Google logo, "Sign in with Google"
β« **GitHub button** β Dark background, GitHub logo, "Sign in with GitHub"
π§ **Email/password** β Still available below a "or" divider
OAuth flow:
1. User clicks social button
2. Redirected to Google/GitHub to authorize
3. Redirected back to your app, logged in
Supabase handles the OAuth tokens and user creation automatically.
After social login, I want to show the user's avatar from their Google/GitHub profile in the nav bar.
Done β User avatar (from Google/GitHub profile) now shows in the nav bar as a circular image. Falls back to their initials if no avatar is available.
β» Replay conversation
Knowledge Check
Why do many apps offer "Sign in with Google" instead of only email/password?
A
It reduces friction β users don't have to create yet another account and password
B
It's cheaper for the developer
C
It's required by Google
D
It's more secure than email/password
Every extra step costs users. Creating a new account with a new password is friction. Social login takes one click β users are already signed into Google or GitHub, so they just authorize your app. Less friction = more signups.
What authenticated apps can do
Once you have auth, you unlock these patterns:
Personal dashboards β Each user sees their own data. My tasks, my projects, my settings.
User-generated content β Posts, comments, reviews β all tied to a user account.
Role-based access β Admins see everything. Regular users see only their own data. Viewers can browse but not edit.
Billing and subscriptions β Tie payments to accounts. Free vs. paid features.
Multi-user collaboration β Team workspaces where multiple people work together.
Now that I have auth, update the feature request board from Day 11. Each user should only be able to delete their own feature requests. Show who submitted each request. And users can only vote once per request.
Feature board updated with auth β
π€ Each request shows who submitted it (name + avatar)
ποΈ Delete button only appears on your own requests
π One vote per user per request (toggleable)
π Vote count is accurate β no duplicates
All enforced on the backend β can't be bypassed from the browser.
β» Replay conversation
Final Check
Why is it important that vote restrictions are "enforced on the backend"?
A
It's a best practice but doesn't matter technically
B
Frontend restrictions can be bypassed β anyone can modify browser code. Backend enforcement means the rules can't be cheated
C
The frontend doesn't know who the user is
D
Backend code runs faster
Anything in the browser can be modified by the user β they can open developer tools and change values. Backend enforcement means the server validates every request. Even if someone tries to cheat, the server rejects invalid votes. Security happens on the backend.
π
Day 13 Complete
"Authentication turns visitors into users. Users turn projects into products."
Tomorrow β Day 14
Deploying to the World
Your app works locally. Tomorrow you put it on the internet β live, with a real URL, for anyone to use.