What Is Authentication?

The second your app has users, it needs to know who is who. That job is called authentication. This lesson walks through what it covers, where it lives in your app, and the two VERY different kinds of tools you can use for it.

Who Are You?#

Authentication answers one question... who is making this request?

When you log in to your email, you prove you're you, usually with a password. From that point on, the email service trusts that the requests coming from your browser are yours, right up until you log out.

What an Auth System Has to Do#

Login looks like one lil form, but there's a LOT going on underneath it.

• Sign up. Create an account and check that the email address is real.
• Log in. Check the password without ever storing it as plain text.
• Stay logged in. Remember the user between page loads using a session.
• Log out. End the session properly.
• Forgot password. Send a reset link that only works once and then expires.
• Social login. Let people sign in with Google, GitHub or Apple.
• Extra security. Add two factor codes, block password guessing and catch odd activity.

Every one of these has ways to go wrong, and a mistake here can expose your users' accounts. That's why most developers don't build auth from scratch.

I've seen the messy side of this firsthand. A WooCommerce site I was looking after got hit with a spam attack, and part of cleaning it up was locking things down so people couldn't create accounts without being signed in. Account stuff gets abused the moment you leave a door open.

How a Session Works#

Here's the basic flow, and you'll see it in every auth tool out there.

Step 1. The User Logs In#

They type in an email and password, or click "Sign in with Google."

Step 2. The Auth System Checks Them#

It compares the password hash, or asks Google to confirm who they are.

Step 3. A Session Is Created#

The auth system creates a session and hands the browser a small token, usually stored in a cookie (the computer kind, sadly).

Step 4. Every Request Carries the Token#

Every time the browser asks your app for a page or some data, that token tags along with it.

Step 5. Your App Checks the Token#

Your code asks the auth system "who does this token belong to?" and then decides what to show.

  Browser --- login ---> Auth system
     ^                        |
     |---- session token -----+
     |
  Browser --- request + token ---> Your app
                                      |
                        "who is this?" v
                                  Auth system

Where Auth Sits in Your App#

Short answer? Pretty much everywhere. Your sign in pages use it. Your backend checks it before handing back private data. Your database usually has a users table, or links its records to a user ID from the auth tool. Even payments and emails need to know which user they belong to.

That's why it pays to pick your auth tool EARLY. Switching later means moving every single user account... and nobody wants that weekend.

Two Kinds of Auth Tools#

This module covers one of each, and the difference matters.

Clerk is a hosted service. Better Auth is a library you run yourself. (You can probably guess which way I lean, since I'm the own-your-tools guy, but you're learning both here so you can make that call yourself.)

What to Look For#

When you're comparing auth tools, run through these questions.

• Does it work with your framework? If you're on Next.js, look for a Next.js guide.
• Which sign in methods does it support? Think email and password, magic links, Google, GitHub and passkeys.
• Where does user data live? Is it on their servers or in your own database?
• How much do you have to build? Do you get ready-made pages, or are you writing the forms yourself?
• How does it charge? A lot of hosted services price by active users, so check how that grows as your app does.

The Tools in This Module#

TL;DR#

• Authentication proves who a user is, and authorization decides what they can do
• An auth system handles sign up, log in, sessions, password resets, social login and a bunch more
• Passwords have to be hashed and never stored as plain text
• A session token rides along with every request so your app knows who's asking
• Hosted services run auth for you, and libraries run inside your own app and database
• This module covers Clerk (hosted) and Better Auth (library)

What's Next?#

First up is the Clerk chapter, where you'll get to watch a hosted service handle sign up and log in for you...