Authentication & Authorization

Authentication answers 'who are you', authorization answers 'what can you do'. The mental model: auth is a chain — prove identity → issue credential → credential presented → validated → permissions checked → access granted or denied. Each step can fail and must be designed defensively. Authentication vs Authorization These terms are frequently conflated in interviews: Authentication (AuthN): Who are you? Verify identity. (Login, API key check) Authorization (AuthZ): What can you do? Verify permissions. (RBAC, policy check) Authentication always precedes authorization. You cannot authorize an unknown identity. --OAuth 2.0: The Delegation Framework OAuth 2.0 is not an authentication protocol — it is an authorization delegation framework. It lets users grant third-party apps limited access to their resources without sharing passwords. Four OAuth 2.0 Grant Types: Use Case Web apps with backend (most secure, use PKCE for SPAs) Client Credentials TV/CLI apps without browser ~~Implicit~~ PKCE (Proof Key for Code Exchange): Required for public clients (SPAs, mobile). Client generates a (random), hashes it to , sends challenge with auth request, and verifier with token exchange. Prevents authorization code interception. --JWT: JSON Web Tokens A JWT is a self-contained, signed token. The resource server validates it without calling the auth server. JWT Security Rules: Never store secrets in payload — it is base64-encoded, not encrypted Always validate — expired tokens must be rejected Prefer RS256 over HS256 — asymmetric signature allows public key distribution without sharing secrets Keep JWTs short-lived — 15 minutes for access tokens; use refresh tokens for longer sessions Implement token revocation via a denylist or short TTL refresh token rotation JWT vs Opaque Tokens: JWT Local (no network call) Difficult (must wait for exp) ~500 bytes Stateless microservices --SSO: Single Sign-On SSO lets users authenticate once and access multiple applications. Two main protocols: SAML 2.0 — Enterprise/legacy. XML-based assertions. Identity Provider (IdP) issues signed XML tokens to Service Providers (SP). Okta, Azure AD, Google Workspace. OpenID Connect (OIDC) — Modern. Built on OAuth 2.Adds (JWT) for identity. Separates authentication (OIDC) from authorization (OAuth 2.0). SSO Session Flow: User hits App A — no session App A redirects to IdP User authenticates at IdP — IdP creates SSO session cookie IdP redirects back with token User hits App B — no session App B redirects to IdP — IdP sees SSO cookie, auto-issues token User is logged into App B without re-entering credentials --PKCE Deep Dive: Why It Matters for SPAs PKCE (Proof Key for Code Exchange, pronounced "pixie") was added to OAuth 2.0 specifically to protect public clients — apps that cannot store secrets securely, like SPAs and mobile apps. The problem PKCE solves: Without PKCE, if an attacker can intercept the authorization code (via a malicious browser extension, a redirect URI mismatch, or a compromised redirect handler), they can exchange it for tokens. The code alone is sufficient to get tokens.