Build · Protect it

Auth

How do people sign in, and how does your app know who they are?

Auth answers two questions on every request: who is this (authentication) and are they allowed to do this (authorization). You either build the login yourself, or hand it to a service that gives you ready-made sign-in screens, sessions and social logins.

It is the front desk of a building: it checks your ID once, hands you a badge, and every door after that just looks at the badge.

Add it when Users have their own data, accounts, paid plans or anything private.

It can wait when Everything on the site is public and nobody saves anything.

1 Which one should I pick?

Answer what you can. The ranking updates as you go, and you can ignore it if you disagree.

Who are your users?

How much of the sign-in do you want to build?

What matters most right now?

Most people start with

2 Side by side

Three pips is strong, one is weak. Pick a row to read about it below.

Option	Quick to set up	Cheap while small	Easy to leave	Room to grow	Price
					Free tier, then per monthly active user
					Free tier, then bundled with the project plan
					Free; you pay for the library or host you run it on
					Free; the cost is your time

3 Look closer, then wire it in

Managed service

Clerk

Drop-in sign-in screens, user management and sessions, hosted for you.

Pick it when You want working login with Google, email and a user dashboard by this afternoon.

Skip it if You must keep every user record in your own database or need to avoid per-user pricing at large scale.

Pre-built sign-in and profile components
Social logins, magic links and MFA in a few clicks
Handles sessions and security patches for you

Users live in their system, so moving away means a migration
Price grows with active users

Quick to set up
Cheap while small
Easy to leave
Room to grow

PriceFree tier, then per monthly active user

How to connect it

Create an application in the Clerk dashboard and switch on the sign-in methods you want.
Install the SDK and wrap your app in the provider component.
Add the middleware so protected routes redirect signed-out visitors to sign-in.
Read the user id on the server and store it on your own rows as the owner.

Put these in your .env file

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
CLERK_SECRET_KEY

middleware.ts

import { clerkMiddleware, createRouteMatcher } from "@clerk/nextjs/server";

const isPrivate = createRouteMatcher(["/dashboard(.*)"]);

export default clerkMiddleware(async (auth, req) => {
  if (isPrivate(req)) await auth.protect(); // signed-out users are sent to sign-in
});

4 Watch it work

Press play, or step through one message at a time.

Client
Service
API gateway
Database

Text description

Browser → Your app: Open /dashboard
Your app replies to Browser: No session: redirect to sign-in
Browser → Auth service: Email and password, or Google
Auth service replies to Browser: Signed session or token
Browser → Your app: Open /dashboard with the token
Your app → Auth service: Is this token valid?
Auth service replies to Your app: Yes, user 42
Your app → Your database: Load rows where owner = 42
Your database replies to Your app: Their rows only
Your app replies to Browser: The dashboard

5 Mistakes to skip

Storing the token in localStorage.
Use an httpOnly cookie so page scripts cannot read it.
Checking login only in the browser.
Check on the server for every request that returns private data. The browser can be edited.
Storing passwords as plain text or a fast hash.
Use a service, or argon2 or bcrypt. Never invent your own.

See where it sits in a whole app

The stack builder draws your product with auth in it and animates a request through it.

Open the stack builder

What it is