Auth and identity

Authentication (AuthN for short) answers 'who are you?'. It happens at sign-in, using something the person knows (a password), has (a phone or security key) or is (a fingerprint), and ends with the app issuing a session or token that carries the answer to later requests. Authorisation (AuthZ) answers 'what may you do?' and runs on every request: may this user read this invoice, delete this project, open the admin page?

The two fail in different ways. Broken sign-in lets a stranger in; a missing authorisation check lets a real, signed-in user read other people's data, which is why broken access control sits at the top of the OWASP Top 10. Checks belong on the server or in the database, because anything enforced only by hiding it in the interface can be bypassed. HTTP status codes mirror the split: 401 means 'not signed in' and 403 means 'signed in, but not allowed'.

Instead of granting abilities person by person, RBAC groups them: the 'editor' role may create and edit posts, the 'viewer' role may only read, and each user gets the roles that fit their job. Changing what editors can do then means changing one role rather than hundreds of accounts. Roles are often scoped to a team or workspace, so the same person can be an admin in one organisation and a viewer in another.

Enforcement belongs on the server. A backend checks the role before acting, reading it from a table or from custom claims in the user's token, and a database can enforce it directly: PostgreSQL row level security policies can compare the user's id and role with each row. Hiding a button in the app is only cosmetic. When rules depend on relationships or attributes (the owner of this document, members of this project), finer models take over: attribute-based (ABAC) and relationship-based (ReBAC) access control, with tools such as OpenFGA.

With SSO, an app stops checking passwords itself and trusts an identity provider (IdP) such as Okta, Microsoft Entra ID or Google Workspace. The app sends the user to the IdP, the IdP signs them in with its own password rules, 2FA and device checks, and returns a signed statement of who they are. Two standards carry that statement: SAML 2.0, an older XML format still common in enterprises, and OpenID Connect, its modern JSON and JWT based counterpart.

For a company, SSO means one place to enforce security and one switch that removes a leaver's access everywhere, often paired with SCIM, which creates and deletes accounts in each app automatically. For a software vendor it is usually the feature that unlocks business customers, which is why many products reserve it for their top plan, a habit nicknamed the 'SSO tax'. 'Sign in with Google' on a consumer site is the same idea on a smaller scale.

The server creates a long random token, stores a hash of it with a short expiry (minutes rather than hours) and emails a link containing it. When the link is opened, the server checks the token, marks it as used and starts a session. Signing in is therefore exactly as safe as the person's email account, which is the same trust that password reset emails already rely on.

Delivery decides the experience: the email must arrive within seconds and stay out of spam, so magic links need a transactional email service with SPF, DKIM and DMARC set up. Two snags are common. Corporate email scanners sometimes open links before the person does, using up a single-use token, and a link opened on another device leaves the original tab signed out. Many apps include a short code in the same email for exactly these cases.

There are two families. Sent codes are created by the server, delivered by SMS, email or WhatsApp, and checked against a stored copy; they prove the person can receive messages at that number or address. Generated codes come from an authenticator app such as Google Authenticator, Microsoft Authenticator or a password manager, using TOTP (time-based one-time passwords): the app and the server share a secret, set up once by scanning a QR code, and both work out the same code every 30 seconds without any message being sent.

Codes serve either as the whole sign-in (phone-number login is common in mobile-first markets such as India) or as a second step after a password. Good implementations keep codes short-lived, allow only a few attempts, limit how often codes can be sent and store them hashed. SMS has known weaknesses: numbers can be hijacked through SIM swapping, messages can arrive late or not at all, and attackers run 'SMS pumping' fraud, triggering thousands of paid messages to numbers they profit from.

Factors come in three kinds: something you know (a password or PIN), something you have (a phone, an authenticator app, a security key) and something you are (a fingerprint or face). 2FA combines two different kinds; multi-factor authentication (MFA) is the general term. After the password, the app asks for the second factor, often with a 'remember this device' option so it is not asked for every time.

The options differ in strength. SMS codes are better than no second factor but are exposed to SIM swapping and phishing. Authenticator apps (TOTP) are free and stronger. Push approvals are convenient but invite 'MFA fatigue' attacks, where someone sends prompts until the user taps approve. Hardware security keys and passkeys resist phishing, because they only respond to the genuine website. Every setup also needs a recovery path, usually one-time backup codes, or lost phones turn into support tickets.

A passkey is a WebAuthn (FIDO2) credential. When someone creates one, their device makes a private key that stays on the device or in their password manager and gives the website only the matching public key. At sign-in the site sends a random challenge, the device asks for a fingerprint, face or PIN to unlock the key, and signs the challenge; the server checks that signature with the public key. No shared secret exists, so a leaked database holds nothing an attacker can sign in with.

Each passkey is bound to the website's domain, so a look-alike phishing site simply gets no answer, which is what sets passkeys apart from passwords and codes. Apple, Google and Microsoft support them across their platforms, and they sync between a person's devices through iCloud Keychain, Google Password Manager or password managers such as 1Password and Bitwarden. On a borrowed computer, a phone can approve the sign-in by scanning a QR code.

Adoption is still uneven: older devices, shared computers and people without a synced account can struggle, so apps usually offer passkeys alongside another method and invite users to add one after they sign in. On Android, Credential Manager handles creating and using them.

In the usual authorisation code flow, the app sends the user to the provider (Google, GitHub, Microsoft) with a list of scopes, the permissions it wants. The user signs in there and approves a consent screen, and the provider redirects back with a short-lived code. The app's server swaps that code for an access token, which it presents to the provider's APIs, and often a refresh token for getting new access tokens later. The app never sees the user's password.

OAuth was designed for delegated access (let this app read my calendar), not for proving identity, so social login normally adds OpenID Connect on top, which returns an ID token saying who the user is. GitHub is a notable exception that uses plain OAuth plus a profile API call. Mobile apps and single-page apps cannot keep a client secret, so they use PKCE. OAuth 2.1 gathers these lessons into one specification, requiring PKCE and dropping older flows such as the implicit flow.

For users, social login means no new password and a sign-up that takes seconds. For the app, it means following each provider's rules: a registered developer app, exact redirect URLs, reviews for sensitive scopes, and on iOS the App Store rule that apps offering third-party login must usually also offer Sign in with Apple or a similar privacy-focused option.

After a successful sign-in, the server creates a session record (user id, expiry, perhaps the device) in a database table or a fast store such as Redis, and sends back a long random session ID in a cookie. On each request the browser returns the cookie and the server looks the ID up to learn who is asking. The ID means nothing by itself, so reading it reveals nothing, but whoever holds it is treated as that user until it expires.

Because the truth lives on the server, control is simple: signing out, 'sign out of all devices', banning a user or changing their role takes effect on the very next request. The costs are a lookup on every request and a store that every server must share. Good practice is to mark the cookie HttpOnly (hidden from JavaScript), Secure (sent only over HTTPS) and SameSite (not sent from other sites, which blunts CSRF), to issue a fresh ID at sign-in, and to expire idle sessions.

A JWT (pronounced 'jot') is three base64url-encoded parts joined by dots: a header naming the signing algorithm, a payload of claims (sub for the user id, exp for the expiry time, iss for the issuer, plus custom ones such as role) and a signature. It is signed either with a shared secret (HS256, an HMAC) or with a private key (RS256, ES256), in which case anyone can verify it with the public key, usually published at a JWKS URL.

The payload is encoded, not encrypted, so anyone holding the token can read it and it must never contain secrets. The central trade-off is revocation: a valid JWT keeps working until it expires, even after the user signs out or is banned. Systems therefore issue short-lived access tokens (minutes to an hour) with a refresh token that gets new ones, or keep a deny list, which brings back the lookup JWTs were meant to avoid.

Supabase, Firebase and Clerk all give apps JWTs, and OpenID Connect ID tokens are JWTs. Verifying code must check the algorithm, signature, expiry and audience; libraries that once accepted the 'none' algorithm or confused key types led to real vulnerabilities. Tokens kept in localStorage are exposed to any cross-site scripting (XSS) bug, so HttpOnly cookies are often the safer place for them in a browser.

OAuth on its own hands out access tokens that say what an app may do, not who the user is. OpenID Connect, finalised by the OpenID Foundation in 2014, adds the missing piece: when the app asks for the 'openid' scope, the provider also returns an ID token, a JWT with claims such as sub (a stable user id), email, name, iss (who issued it) and aud (which app it is for). The app verifies the signature and those claims, then starts its own session.

It also standardises the plumbing. A discovery document at /.well-known/openid-configuration lists a provider's endpoints and signing keys, so a library can connect to Google, Microsoft Entra ID, Okta, Auth0 or Keycloak with little more than a URL, a client id and a secret. That makes it the modern alternative to SAML for single sign-on, and it suits mobile apps, which SAML was never designed for.

Before redirecting to the provider, the app makes a random secret (the code verifier) and sends only its SHA-256 hash (the code challenge). When it later swaps the authorisation code for tokens, it must present the original verifier, and the provider checks that it hashes to the challenge. A malicious app or script that grabs the code on its way back cannot use it, because the verifier never left the real app.

PKCE (pronounced 'pixy', defined in RFC 7636) was created for apps that cannot keep a client secret, since anything shipped inside a mobile app or a JavaScript bundle can be extracted. It replaced the old implicit flow for single-page apps, current security guidance recommends it for server-side apps too, and OAuth 2.1 makes it mandatory. Good OAuth libraries and auth SDKs handle it automatically.

Supabase Auth is an open-source Go server (it began as a fork of Netlify's GoTrue) that runs beside each project's database and stores users in the auth.users table. It supports email and password, magic links, one-time codes by email or SMS, anonymous sign-ins, OAuth providers such as Google, Apple and GitHub, SAML single sign-on, TOTP two-factor and, more recently, passkeys. Client libraries for JavaScript, Flutter, Swift, Kotlin and Python handle sign-in and token refresh.

Each sign-in returns a short-lived JWT access token and a refresh token. Because the database understands those tokens, row level security policies can call auth.uid() to limit every query to the signed-in user's rows, and a custom access token hook can add claims such as a role. Projects can also accept tokens from Clerk, Firebase Auth or Auth0 when another provider handles sign-in.

Two settings matter before launch. The built-in email sender only reaches the project team's own addresses and allows a couple of messages an hour, so production apps connect their own SMTP service such as Resend, Amazon SES or Postmark. SMS codes likewise need an account with an SMS provider such as Twilio.

Firebase Authentication keeps users in your Firebase project and supports email and password, email link sign-in, phone numbers with SMS codes, anonymous accounts, and providers such as Google, Apple, Facebook, GitHub, Microsoft and X. Custom tokens let an existing login system hand its users over. FirebaseUI offers ready-made sign-in screens, and the SDKs keep people signed in and refresh their tokens automatically.

Each signed-in user has an ID token, a JWT valid for an hour, which Firestore and Cloud Storage security rules read as request.auth and which your own server can verify with the Admin SDK. Upgrading to Firebase Authentication with Identity Platform adds multi-factor authentication, SAML and OpenID Connect providers, blocking functions that run your code during sign-up and sign-in, audit logs, multi-tenancy and an SLA, and switches billing to monthly active users.

Phone sign-in needs the pay-as-you-go Blaze plan and is billed per SMS, so projects should limit which countries may receive codes to keep SMS fraud down. Passkeys are not a built-in sign-in method. Users can be exported with the Firebase CLI, but passwords are hashed with a modified scrypt, so moving elsewhere takes planning.

Clerk supplies drop-in components such as SignIn, SignUp, UserButton and UserProfile, plus hooks and server helpers for Next.js, React, React Router, Astro, Expo and native iOS and Android. Behind them sit passwords, magic links, email and SMS codes, social providers, passkeys, MFA, and organisations with roles and invitations for B2B apps. A dashboard lists every user and session, and bot protection, leaked-password checks and device management come built in.

Sessions pair a long-lived cookie held by Clerk's sign-in API with a short-lived JWT, lasting about a minute, that the SDK refreshes in the background, so revoking a session takes effect almost at once. User records live on Clerk's servers; apps that need users in their own database copy them over with webhooks. Clerk tokens can also be accepted by Supabase and other backends.

Billing counts monthly retained users: a person counts only once they come back at least a day after signing up, so sign-ups that never return cost nothing. Passkeys, MFA and removing Clerk branding need the Pro plan.

Auth.js runs inside your app rather than as a separate service. You list providers (dozens of OAuth services such as Google, GitHub and Microsoft Entra ID, email magic links, or a credentials form for usernames and passwords) and it handles the redirects, callbacks, CSRF protection and cookies. It began as NextAuth.js for Next.js; the core was later split out so SvelteKit, Express, Qwik and SolidStart apps could use it too.

Sessions are either stateless, as an encrypted JWT in a cookie, or stored in your database through adapters for Prisma, Drizzle, Supabase, MongoDB and many more. User records stay in your own infrastructure and there is no per-user fee. It does not include user management screens or built-in two-factor authentication, and its WebAuthn (passkey) provider is marked experimental.

In September 2025 the project passed to the Better Auth team, which joined Vercel in 2026. Auth.js still receives security patches and urgent fixes, but its maintainers recommend Better Auth, a separate open-source library, for new projects and publish a migration guide.

Auth0 usually shows a hosted Universal Login page on its own domain or yours, so passwords never touch your app. It supports passwords, passwordless email and SMS, passkeys, social providers, MFA, and enterprise connections to SAML, Microsoft Entra ID, Google Workspace and LDAP directories. Apps connect through OpenID Connect and OAuth 2.0 with SDKs for most languages, and Actions (small Node.js functions) customise what happens during sign-up and sign-in.

Its strength is the business end: organisations for B2B customers, each with its own SSO connection and branding, role-based access control, protection against bots and credential stuffing, audit log streaming, and the certifications enterprise security reviews ask for. Okta bought the company in 2021, and it also sells Fine-Grained Authorization, based on Google's Zanzibar model, and identity tools for AI agents.

The trade-offs are cost and complexity. The free plan is generous, but paid plans start with a few hundred included users and rise with each step up in monthly active users, and features such as enterprise MFA or connecting your own user database sit on higher tiers. Configuration spans many dashboard screens, and leaving later means rebuilding rules and connections elsewhere.