🦞 4minAI.com
1 / 14
Day 13 of 28 Β· Vibe Coding Challenge

User Authentication

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 have better design
C
There's no practical difference
D
Authenticated pages load faster
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.

⚑
Bolt
online
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
Modern login page with split layout β€” blue gradient on the left, login form with Google and GitHub social login buttons on the right
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
Auth has critical security requirements β€” password hashing, session management, token security β€” that are easy to get wrong
C
You can't build auth without Supabase
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.

πŸ€–
Cursor AI
online
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 more secure than email/password
D
It's required by Google
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.

⚑
Bolt
online
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
The frontend doesn't know who the user is
B
Frontend restrictions can be bypassed β€” anyone can modify browser code. Backend enforcement means the rules can't be cheated
C
It's a best practice but doesn't matter technically
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.
πŸ”₯1
1 day streak!