Sign-in, without writing it yourself

The feature you must not build from scratch

Ask a model for “user login” and it will produce something that works: a users table with a password column, a form, a comparison. Older training data will hash the password with MD5 or SHA-1, or not at all. Newer data will use bcrypt and still get the surrounding parts wrong: the session, the reset flow, the timing of the comparison, the lockout after failures.

Authentication is the one part of an app where “works” and “safe” are furthest apart, because the failure is invisible: a badly hashed password table looks identical to a well hashed one until it is stolen. The rule is absolute for this course. Do not write it. Use a library or a hosted provider, and spend your attention on wiring it correctly.

The options

A library in your app. Auth.js (formerly NextAuth), better-auth and Lucia’s guide for hand-wired sessions are the common ones in the JavaScript world. They store users and sessions in your own database, cost nothing, and give you sign-in with Google, GitHub, email links and passwords with the hashing done properly. The trade: you run it, and you read its documentation.

A hosted provider. Clerk, Auth0, Firebase Auth and Supabase Auth keep the users on their side and hand your app a verified identity. Generous free tiers (Clerk’s covers ten thousand monthly active users at the time of writing) and a polished sign-in screen in ten minutes. The trade: your users live in somebody else’s system, and leaving later means migrating them.

Either is fine. Pick by which your framework’s documentation shows first, and put the choice in the specification so the model does not pick a third.

What “sign in with Google” actually does

The flow has six steps, and knowing them is what lets you debug it.

1. Your app sends the browser to Google with your client id and a callback address: the page on your site to come back to.
2. Google shows its own consent screen. Your app never sees the password.
3. Google sends the browser back to your callback address with a short-lived code.
4. Your server exchanges the code, together with your client secret, for a token. This step is server to server, which is why the secret never reaches the browser.
5. Your server asks Google who the token belongs to and gets an email and a name.
6. Your app finds or creates a user with that email and starts a session.

Step 1 is where the deployed site breaks. Google only sends users back to callback addresses you registered in advance, and the list you made on day one contains http://localhost:3000/api/auth/callback/google and nothing else. The error is redirect_uri_mismatch, it is not a code bug, and the fix is to add the production address to the list in the Google Cloud console. Every provider has the same check and the same error under a different name.

The client secret goes in environment variables, on the server side, without the public prefix. Step 4 is why: it is the proof that the request came from your server and not from a copy of your JavaScript.

Passwords, if you must

Some audiences will not sign in with Google, and email-plus-password remains the most familiar form. The library hashes with bcrypt or argon2 (slow by design, so that a stolen table takes years to crack rather than minutes) and you will never see the plaintext. What remains yours: a minimum length (eight is the floor; do not add complexity rules, they push people towards Password1!), a rate limit on the sign-in route so that guessing is slow, and a reset flow that sends a one-time link rather than the password.

Magic links and codes

An email containing a link or a six-digit code, valid for ten minutes, is a password the user never has to remember. It moves the security to the inbox, which is where a password reset would have sent it anyway. It needs an email-sending service (Resend’s free tier of three thousand a month is enough for a small app) and it needs the link to expire and to work once.

The parts you still own

The library authenticates. Your code decides what a signed-in person may do, which is the next lesson’s subject and the security block’s whole concern. And your code decides which identity the rest of the app refers to. Store your own users row and have bookings reference that, not the provider’s id, so that switching providers later is a migration of one table rather than of every foreign key in the system.

Testing it

Make a second Google account, or use the provider’s test users. Sign up fresh, sign out, sign in again, reset a password, sign in from a private window while already signed in elsewhere. Every one of those is a path a user takes in the first week and none of them is the path the agent tested, because the agent only ever signed in once.