How I Do Authentication Without Rolling My Own Auth

Don't roll your own auth—but a managed provider isn't the whole job. My framework for Firebase Auth sessions, JWT revocation, MFA, custom claims, and recovery.

The best security advice I ever got fit on a sticky note: "You are not going to out-engineer a team of a hundred people whose only job is login." That's why I don't roll my own auth. But "don't roll your own auth" is one of those slogans that's completely right and quietly misleading, because it makes juniors think authentication is a box you buy and bolt on, and then you're done.

You're not done. Outsourcing identity moves the hard problems around; it doesn't delete them. A couple of years back I inherited a Firebase Auth setup on a client project where everything "worked" — users logged in, tokens flowed, the login screen was pixel-perfect — and it still had a password-reset flow that would hand a motivated attacker other people's accounts. The provider was flawless. The 200 lines of glue we owned were not. This post is the decision framework I actually use: what to hand off to a managed authentication provider, what to keep, and how to tell the two apart.

Why "don't roll your own auth" is right but incomplete

Rolling your own auth means writing the crypto and the credential storage yourself: password hashing, timing-safe comparisons, token signing, the session store, TOTP validation windows, rate limiting on the login endpoint. This is a genuinely brutal domain where every mistake is a CVE and the failure mode is silent. You don't find out you got the bcrypt cost factor wrong, leaked a timing side-channel, or forgot to salt until someone dumps your database and the internet finds out for you.

Handing this to a managed identity provider — Firebase Authentication, Auth0, Amazon Cognito, Clerk, or Supabase Auth — is almost always the correct call. I've never once regretted delegating credential verification. These teams live and breathe OWASP guidance, run bug bounties, and patch the classes of bug you'd never think to test.

But identity is bigger than the login box. The provider owns credential verification. It does not own:

• Authorization — who is allowed to do what. The provider tells you who someone is, never what they may do.
• Session lifetime policy — how long a login stays valid, and when you force re-authentication.
• Account recovery — the password reset and "I lost my phone" flows, which is where real breaches happen.
• The trust boundary — where you decide to believe a token, and where you re-check it.

Every one of those lives in your code, your security rules, and your product decisions. So the real skill isn't "use a provider." It's knowing exactly where the provider's responsibility ends and yours begins, and not fumbling the handoff. That handoff — the seam between authentication and everything downstream of it — is where I've watched otherwise solid apps spring leaks.

What a managed auth provider gives you, and what it quietly doesn't

Here's the honest split for Firebase Auth, which is what I reach for most because it's free at the scale most of my projects run and it plugs straight into the rest of the Google Cloud stack. The same mental model maps cleanly onto Auth0, Cognito, and Supabase — only the API names change.

What you get, and should be grateful for:

• Credential storage and verification (scrypt-based, tuned, not your problem).
• Social and OAuth providers wired up (Google, Apple, GitHub, and so on) without you touching a single OAuth or OIDC dance.
• A signed ID token — a JWT — that proves identity, with a public-key rotation scheme you never have to think about.
• Email verification, password reset, and (on the paid tier via Identity Platform) MFA primitives.

What it quietly does not give you:

• A session. The ID token is a one-hour bearer credential, not a session. You decide what "logged in" means for your app.
• Authorization. Out of the box, every authenticated user is equal. Roles, tenants, ownership, plan tiers — all yours.
• Instant revocation. More on this below; it's the single most misunderstood thing about JWT-based auth.
• Recovery hardening. The default reset flow is fine for a hobby app and dangerous for anything with money or PII behind it.

The trap is treating the ID token as a login session. It isn't. It's a short-lived claim about identity that your backend re-verifies on every call. And "verify" is doing real work in that sentence — decoding a JWT is not verifying it. A decoded token is just base64 that anyone can forge in a text editor.

// Backend: verify the ID token on EVERY request. Never trust a decoded// JWT you didn't verify — a decoded token is just a base64 string.import { getAuth } from "firebase-admin/auth";async function requireUser(req: Request): Promise<DecodedIdToken> {  const header = req.headers.get("authorization") ?? "";  const token = header.startsWith("Bearer ") ? header.slice(7) : null;  if (!token) throw new HttpError(401, "missing token");  // checkRevoked = true costs a lookup but honors forced sign-out.  return getAuth().verifyIdToken(token, /* checkRevoked */ true);}

That checkRevoked flag is the difference between "user is signed out everywhere in a few minutes" and "user is signed out everywhere in up to an hour." Know which one you shipped, and make it a deliberate choice rather than a default you never read.

Session and token lifetime: the decisions people get wrong

This is where I see the most confident mistakes, so let me be blunt about the model.

Firebase gives you two things: a short-lived ID token (one hour, non-negotiable) and a long-lived refresh token (effectively durable) that the client SDK uses to silently mint new ID tokens. The refresh token is your session. The ID token is a disposable proof you attach to each request. Get those two roles straight in your head and half of the confusion around JWT expiry evaporates.

The mistake people make: they treat the one-hour expiry as a security boundary. It isn't, really. If you need to kill a session right now — the user hit "log out everywhere," or you detected a compromised account — the ID token stays valid for up to an hour unless you actively check revocation. So split your endpoints by blast radius:

• For most read paths, plain verifyIdToken (no revocation check) is fine and fast.
• For sensitive mutations (change email, delete account, move money), verify with checkRevoked: true, or gate them behind a fresh re-authentication.

Prefer session cookies over localStorage for web apps

For web apps specifically, I strongly prefer session cookies over shipping ID tokens to the browser and stashing them in localStorage. Firebase has a first-class API for this: you trade the ID token for an HttpOnly, Secure, SameSite cookie your JavaScript can't read, which shuts down a whole class of XSS token-theft attacks. If an attacker's injected script can't read the credential, it can't exfiltrate it.

// Exchange a freshly-minted ID token for a session cookie.// Keep the window tight for a "remember me = no" experience,// longer if the product genuinely wants persistent login.const expiresIn = 60 * 60 * 24 * 5 * 1000; // 5 daysconst sessionCookie = await getAuth().createSessionCookie(idToken, { expiresIn });res.cookie("session", sessionCookie, {  maxAge: expiresIn,  httpOnly: true,  secure: true,  sameSite: "lax",});

My defaults, learned the boring way:

• Access proof (ID token): short. One hour is fine. Don't fight it.
• Session (refresh token / cookie): match the product, not a superstition. A banking app is not a note-taking app. I've shipped 5-day cookies for consumer apps and 12-hour ones for anything touching payroll.
• Step up for the scary stuff. Re-prompt for password or biometric right before irreversible actions, regardless of session age. "You've been logged in for 3 days" should never be enough to delete an account.
• Cap it absolutely. Even "remember me" should expire eventually. Sessions that live forever are just credentials with extra steps.

One edge case worth calling out: silent token refresh only works while the client can reach the auth servers. If a user goes offline mid-session, the ID token expires and the SDK can't mint a new one until connectivity returns — so any offline-capable app needs to tolerate a stale-but-not-yet-refreshed token gracefully rather than bouncing the user to a login screen.

Account recovery is where breaches actually happen

Attackers rarely brute-force a well-hashed password. They walk in through recovery. The password reset flow, the "verify your email" flow, the "I lost my 2FA device" flow — that's the soft underbelly, and it's almost entirely code you own even with a managed provider.

The client project I mentioned at the top had exactly this hole. The reset worked, but:

• The reset link didn't expire fast enough.
• Triggering a reset leaked whether an email existed — different responses for known versus unknown addresses, a free user-enumeration oracle.
• After a reset, existing sessions stayed alive. So an attacker who already had a session kept it even after the real owner "recovered" the account.

Fixing recovery is unglamorous and high-leverage. My checklist:

• Short-lived, single-use reset tokens. Minutes, not days. Consume them on use so a leaked link can't be replayed.
• Constant responses. "If that email exists, we sent a link." Same response body, same status, same timing, every time. No enumeration oracle.
• Revoke all sessions on password change. In Firebase: revokeRefreshTokens(uid), then require re-login. This is the step everyone forgets, and it's the one that turns a reset into an actual eviction.
• Notify out of band. Email the account owner "your password was changed" on a channel the attacker doesn't control. This turns a silent takeover into an alarm the real user can act on.
• Rate-limit recovery hard. Recovery endpoints get abused far more than login. Treat them as hostile by default and throttle by IP and by account.

async function onPasswordChanged(uid: string) {  // Kill every outstanding refresh token; ID tokens die within the hour,  // or immediately anywhere you verify with checkRevoked = true.  await getAuth().revokeRefreshTokens(uid);  await sendSecurityEmail(uid, "Your password was changed");}

If you harden one thing after reading this, harden recovery. It's where the money leaks out, and it's the part no provider hardens for you.

MFA that users won't rage-quit

Multi-factor authentication is the highest-ROI security control there is, and also the one users hate most, so the entire game is friction management. Get the friction wrong and people either disable it or, worse, never turn it on. A second factor that nobody enrolls in protects nobody.

My ordering, best experience to worst:

• Passkeys and platform biometrics (WebAuthn). Phishing-resistant, no shared secret to steal, Face ID or fingerprint fast. This is the direction I push new projects toward — it's genuinely both more secure and less annoying, which almost never happens together. Because the credential is bound to the origin, there's nothing to type into a lookalike phishing site.
• TOTP (authenticator apps). Solid, offline, no per-message cost. My default second factor when passkeys aren't viable.
• SMS OTP. Last resort. SIM-swappable, costs money per send, and it trains users to type codes into whatever asks — which is how phishing kits win. I use it only when the audience genuinely can't handle anything else.

The friction rules that keep MFA from getting ripped out:

• Don't prompt on every login. Remember trusted devices for a sensible window. Prompt on a new device, a new location, or a sensitive action — not on every app open.
• Step up, don't gate. Let people browse authenticated; demand the second factor only when they reach for something dangerous.
• Always ship recovery codes. MFA without a backup path is a support-ticket machine and a lockout waiting to happen. Generate one-time recovery codes at enrollment and make the user save them.
• Make enrollment a two-minute flow, not a wizard. Every extra screen is people who bail before their account is protected.

Firebase, via Identity Platform, supports TOTP and SMS enrollment natively, and the WebAuthn ecosystem has matured enough that passkeys are a real option now, not a science project.

The custom-claims and authorization boundary

Here's the rule I tattoo on every backend: the token proves who you are; it never decides what you can do without your code saying so. Authentication and authorization are different jobs, and blurring them is how you get privilege-escalation bugs.

Firebase lets you attach custom claims to a user — small bits of data (role, tenant, plan) baked into the ID token. This is great for coarse-grained decisions because it means your security rules and backend can authorize without a database read, which keeps hot paths fast.

// Set once, server-side only, when a role changes.await getAuth().setCustomUserClaims(uid, { role: "admin", tenant: "acme" });

// Firestore rules can then authorize straight off the verified token.match /tenants/{tenant}/docs/{doc} {  allow read, write: if request.auth.token.tenant == tenant                     && request.auth.token.role in ["admin", "editor"];}

The sharp edges, all of which I've been bitten by:

• Claims are cached in the token. Change a role and the user keeps the old claim until their ID token refreshes (up to an hour) or you force a refresh client-side. For instant demotion, don't rely on claims alone — check a revocation flag or a database record on sensitive paths.
• Keep claims tiny. They ride in every request and there's a hard size limit (roughly 1000 bytes of custom data). Booleans and short IDs, not objects. You'll hit the ceiling fast if you get greedy.
• Coarse in the claim, fine in the data. role: admin belongs in a claim. "Can edit this specific document" belongs next to the document, checked at access time. Don't try to encode row-level permissions into a JWT.
• Never trust a claim you set from the client. Custom claims are server-set only. If a client can influence them, you've built a self-service admin panel for attackers.

The mental model: the token gets you through the front door. Every room still checks the badge.

Migrating off a provider later without a big-bang rewrite

The fear that keeps people writing their own auth is lock-in. Legitimate fear, wrong solution. You reduce vendor lock-in with architecture, not by hand-rolling scrypt.

I keep the provider at arm's length behind a thin internal interface. My app code never calls the Firebase SDK directly for identity decisions; it calls my IdentityService, and that adapter is the only thing that knows a provider exists.

abstract class IdentityService {  Future<AppUser?> currentUser();  Stream<AppUser?> authState();  Future<AppUser> signIn(Credentials creds);  Future<void> signOut();}// FirebaseIdentityService implements this today.// A future adapter can implement the same contract with zero UI changes.

When you do need to migrate — provider pricing changed, a client demands data residency, whatever — the playbook is boring and safe:

• Export or shadow the user store. Most providers let you export password hashes; if they don't, you migrate lazily.
• Lazy migration. Stand up the new provider next to the old one. On each login, if the user isn't in the new system, verify against the old one, then transparently create them in the new one. Users migrate themselves as they show up.
• Dual-verify tokens at the boundary. For a transition window, your requireUser accepts tokens from either provider. Only your adapter changes; nothing downstream notices.
• Retire the old provider once the tail is small. Force-reset the last stragglers rather than paying to keep an old system alive for two percent of users.

I've never done a big-bang auth cutover and I never will. The whole point of outsourcing identity is that it should be swappable, and it is — if you didn't spray provider calls across your codebase.

Key takeaways

• Delegate the crypto, always. Password hashing, token signing, OAuth and OIDC dances, TOTP validation — let the managed provider carry it. You will not out-engineer them.
• Own the boundary. Sessions, revocation, authorization, and account recovery are your code and your product decisions, no matter whose SDK you use.
• The ID token is not a session. It's a one-hour proof of identity; the refresh token or session cookie is the session. Verify the token on every request, and use checkRevoked on sensitive paths.
• Recovery is the battlefield. Short single-use reset tokens, constant responses, revoke-all-on-reset, and out-of-band alerts. Harden this first.
• Sessions are a policy, not a default. Match lifetime to the product, step up for scary actions, and cap even "remember me."
• Authorize on every request. The token says who; your code says what. Coarse custom claims for speed, fine-grained checks at the data layer.
• Stay swappable. One thin identity adapter turns migration into a boring lazy backfill instead of a rewrite you're afraid of.

Outsourcing auth is right. Thinking it means you're off the hook is the mistake. Hand off the parts that are somebody else's core competency, and own the seam — because the seam is where the breaches are.