AUTHENTICATION / LESSON 01

What Is Authentication?

How apps know who you are, why login is hard to build, and how to choose an auth tool

Written by Andrew Lee JenkinsPublished Oct 5, 20269 min readFree lesson

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

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.

Example

  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.

	Hosted Service	Library You Run
What it is	A company runs login for you on its servers	Code you install inside your own app
Where users live	On the service's servers	In your own database
Setup	Usually faster, with ready-made sign in pages	More steps, more control
Settings	Mostly in a web dashboard	Mostly in your code
Cost	Usually free to start, then priced by usage	The library can be free, you pay for your own hosting and database

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

Tool	Kind	Chapter Covers
Clerk	Hosted service	How it works, adding it to your app, features and pricing
Better Auth	Library	What it is, installing it, using it in a Next.js app

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...

Loading the lesson…

Loading activities…