Add login the safe way.

The safe way to add authentication to your app is to use a proven auth service or library, not a password system that you or your AI agent wrote. Offer passkeys or social login, keep the session in a secure cookie, and have the server check who the user is and what they own on every request.

That last step is the easy one to miss. The login screen works, but the data behind it answers anyone who asks directly. This guide covers the choices, the session basics and the tests that catch those gaps.

01Why you should never build your own password system

A login form looks like two fields and a button. Behind it sits a list of jobs that each have a known way to fail:

• Storing passwords with a slow, salted hashing algorithm, never as plain text or a fast hash.

• Reset links that expire, work once and do not reveal whether an email has an account.

• Limits on repeated guesses, so nobody can try a million passwords.

• Email verification, account recovery and multi-factor authentication.

• Sessions that expire, and that end on the server when someone signs out.

The rules have changed, too. NIST’s current guidance says a password used on its own must be at least 15 characters. It forbids rules like “must include a symbol” and forced periodic changes, and it requires checking new passwords against a blocklist of common and breached ones. Older tutorials still teach the opposite, and code copied from them inherits the mistakes.

A good auth provider handles all of this and patches it when attacks change. Your job shrinks to choosing one and wiring it in correctly.

02Which auth service should you use in 2026?

All of these are sound choices. The differences are price at scale, how much they do for you, and where your user records live. Free tiers as of September 2026, from each provider’s pricing page:

Read the small print on “user.” Clerk counts someone only if they come back at least a day after signing up. It also keeps passkeys, multi-factor authentication and branding removal for Pro.

Hosted or library? A hosted service is fastest and keeps up with new attacks for you, but you pay per user at scale and your user records live with the vendor. A library keeps users in your own database at no cost, but you own the updates, the emails and the rate limits.

One more change: Auth.js, long the default library for Next.js, has been maintained by the Better Auth team since September 2025. That team recommends Better Auth for new projects.

03Passkeys, magic links or social login?

Passkeys can sync across a person’s devices through their passkey provider, and they are becoming familiar:

A sensible default for a new app: social login plus passkeys, with an email code as the fallback. If your audience allows it, skip passwords entirely.

04How to add authentication to your app in five steps

1. 01

   Choose one provider and follow its quickstart

   Pick from the table and use the provider’s own guide for your framework. Paste that link into your agent’s instructions, so it follows the current setup rather than an older version it remembers.

2. 02

   Turn on two sign-in methods

   Enable them in the provider’s dashboard, such as Google and passkeys. Start small. Every extra method is another flow to test.

3. 03

   Protect API routes on the server

   Hiding a button is not protection. Every route that returns or changes private data must check the session on the server and refuse requests without one.

4. 04

   Link your data to the user ID from the session

   Store the provider’s user ID on every row a user owns. When a request arrives, take that ID from the verified session, never from the request body or the URL.

5. 05

   Keep secret keys on the server

   Providers give you a public key for the browser and a secret key for the server. The secret belongs in environment variables only. Our guide to keeping API keys safe shows how.

05Sessions in plain English

Because the token is the key to the account, how it is stored matters. This is the cookie Better Auth 1.7.5 sets by default when a user signs up on an HTTPS site, with the token removed:

set-cookie: __Secure-better-auth.session_token=<token>; Max-Age=604800; Path=/; HttpOnly; Secure; SameSite=Lax

Each attribute does a job. HttpOnly hides the cookie from page scripts, so an injected script cannot steal it. Secure sends it only over HTTPS. SameSite=Lax keeps it off most requests started by other websites, which blocks a class of forgery attacks. Max-Age=604800 ends it after seven days.

OWASP’s session guidance adds three rules worth checking. Issue a fresh session ID at login. Make sign-out end the session on the server, not just delete the cookie. And choose lifetimes on purpose: shorter for admin panels and anything that moves money.

06What to check in AI-written auth code

Agents are good at wiring up a provider’s SDK. The mistakes tend to sit around it:

• Protected screens, open API. The page redirects signed-out visitors, but the API behind it still returns data to anyone.

• Trusting the browser. A user ID read from the request body or URL instead of the session.

• Missing ownership checks. /api/invoices/42 returns invoice 42 to any signed-in user, not only its owner.

• Tokens in localStorage. Any script on the page can read them. An HttpOnly cookie cannot be read that way.

• Homemade security. Math.random() for tokens, or a fast hash such as MD5 for passwords.

• Checks switched off “for testing”. Email verification off, rate limits removed, or cross-site requests allowed from anywhere.

If your data lives in Supabase, row-level security is a second lock behind login. Our guide to choosing a database shows it working.

Review every file that handles sign-in, sessions or access to user data. For each API route, tell me:
1. Does it check the session on the server before doing anything else?
2. Where does the user ID come from: the verified session, or something the browser sent?
3. Does it confirm the signed-in user owns the record being read or changed?
Also flag tokens in localStorage, secret keys reachable from client code, homemade token or password handling, and any security check disabled "for now". List problems as file and line, most severe first. Do not fix anything yet.

For the wider picture, see our checklist for securing AI-generated code.

07Test your login like an attacker

Ten minutes of hostile testing catches many of these gaps. Start with the API. Call a protected route with no session:

# Swap in one of your app's protected routes
curl -i http://localhost:3000/api/account

A protected route answers like this (other headers trimmed):

HTTP/1.1 401 Unauthorized
content-type: application/json

{"error":"Not signed in"}

A 200 with data means anyone who finds that route can read it. Then work through the rest by hand:

08FAQ

Next, add payments to your app, or follow the whole path from idea to paying user.