Authentication and Authorization

11 min read · Updated 2026-04-25

Authentication and authorization are two distinct concepts often confused.

Authentication (authN)
Who are you?
The process of verifying identity. Username + password, biometric, hardware key, federated identity. The yes/no question of "is this who they claim to be?"
Authorization (authZ)
What can you do?
The process of determining what an authenticated user is allowed to do. Roles, permissions, policies. The "what does this person have access to?" question.

You can be authenticated without being authorized to do something. AuthN is the gatekeeper at the door; authZ decides which rooms you can enter.

Authentication Methods

Password-based
Username + password. Universal. Vulnerable to phishing, credential stuffing, weak passwords. Combine with MFA.
MFA / 2FA
Second factor — TOTP (Authy, Google Authenticator), SMS (vulnerable to SIM swap), push notification, hardware key.
Passwordless / passkeys
WebAuthn / FIDO2. Phishing-resistant cryptographic auth. The future for consumer-facing auth.
Social / federated
Sign in with Google, Apple, GitHub. OAuth/OIDC under the hood. User skips creating yet another password.
SSO / SAML
Enterprise sign-on. Users authenticate to their company's IdP (Okta, Azure AD); the SaaS trusts the IdP's assertion.
API keys
For programmatic access. Long-lived bearer tokens. Rotate them. Don't put them in URLs.

OAuth 2.0 and OIDC

The standard protocols underneath modern SaaS authentication.

OAuth 2.0
Delegated authorization
Lets app A access app B on behalf of a user, without sharing the user's password with A. Originally for delegation; widely misused for authentication.
OpenID Connect (OIDC)
Authentication on top of OAuth
Adds a standardized "ID token" (JWT) to OAuth's access flow. The right protocol for "log in with X." OIDC + OAuth is the modern combo.

The OAuth flows

Authorization Code (with PKCE)
The standard for web and mobile apps. User authenticates at the IdP; redirects with a code; app exchanges code for tokens. PKCE prevents code interception.
Client Credentials
Service-to-service auth. App authenticates with its own credentials, gets an access token. No user involved.
Device Code
For CLIs, smart TVs, IoT. User visits a URL on their phone, enters a code, app polls for completion.
Implicit (deprecated)
Old single-page-app pattern. Don't use it for new apps. Authorization Code with PKCE replaces it.

JSON Web Tokens (JWT)

JWTs are the standard format for tokens in modern web auth.

Header.Payload.Signature

eyJhbGciOiJSUzI1NiIs...     # header (algorithm, type)
.eyJzdWIiOiIxMjM0...        # payload (claims: user ID, expiration, etc.)
.SflKxwRJSMeKKF2QT...       # signature (HMAC or RSA, verifies integrity)

The payload contains claims like sub (subject = user ID), exp (expiration), iss (issuer), aud (audience). Plus custom claims (tenant ID, roles).

Pros
Stateless verification (server doesn't need to look up the user on every request). Self-contained — claims travel with the token.
Cons
Hard to revoke before expiration. Long-lived JWTs are dangerous if leaked. Compromised signing key = catastrophic.

Best practices

Authorization Models

RBAC — Role-Based
Users have roles; roles have permissions
User Alice has role "admin"; admins can do X, Y, Z. Simple, well-understood, scales to medium complexity. The default for most B2B SaaS.
ABAC — Attribute-Based
Policies based on attributes
User can edit document if user.tenant == document.tenant AND (user.role == admin OR user.id == document.owner). More flexible; harder to reason about.
ReBAC — Relationship-Based
Permissions follow relationships. "User can read folder if user is a member of group, group has access to folder." Google Zanzibar paper. Used by tools like SpiceDB, OpenFGA.
PBAC — Policy-Based
Centralized policy engine evaluates "can user X do Y on resource Z?" Open Policy Agent (OPA), Cedar (AWS). Decouples policy from code.

For most SaaS, start with RBAC, layer in ABAC for nuanced cases (resource ownership, tenant boundaries), reach for ReBAC/PBAC when complexity demands it.

Multi-Tenant Authorization

Tenancy adds another dimension to authorization.

A typical pattern:

1. JWT carries tenant_id and user_id.
2. Every API call validates: user belongs to tenant? (else 403)
3. Every DB query includes WHERE tenant_id = ?
4. Authorization within tenant proceeds via RBAC/ABAC.

For added safety: Postgres Row-Level Security (RLS) can enforce tenant isolation at the DB level. App-level mistakes get caught.

Session Management

Session cookies
Server stores session in DB/Redis; client carries an opaque session ID. Easy to revoke. Requires storage.
Stateless JWTs
Token contains user info. No DB lookup. Hard to revoke. Combine with short expiration + refresh tokens.
Hybrid
Short-lived JWTs for performance + a revocation list (recently revoked token IDs) for kill-switch capability.
Refresh tokens
Long-lived (days or weeks). Stored securely (HTTPOnly cookie). Used to mint new access tokens. Revoke = logout.

Identity-as-a-Service Options

Most SaaS shouldn’t build auth from scratch. Use a managed identity provider:

Auth0 (Okta)
The dominant managed identity platform. OAuth/OIDC/SAML, social logins, MFA, enterprise federation. Pricey at scale.
AWS Cognito
AWS-native. User pools for app auth, identity pools for federated. Tightly integrated with AWS services.
Clerk / WorkOS
Modern dev-first auth platforms. Clerk for consumer SaaS; WorkOS for enterprise auth (SSO, SAML, SCIM).
Supertokens / FusionAuth / Keycloak
Self-hosted alternatives. Trade managed convenience for cost control and data sovereignty.

Common Pitfalls

Recap