Authentication and authorization are often conflated, but they answer fundamentally different questions. Authentication verifies who you are, typically through something you know (a password or PIN), something you have (a phone or hardware token), or something you are (a fingerprint or face). Authorization, on the other hand, decides what you are permitted to do once your identity is known, using roles, permissions, and access control lists. Authentication always comes first, and a common pattern is multi-factor authentication, which combines at least two of those independent factor types so that compromising one alone is not enough to impersonate a user; common implementations include time-based one-time passwords (TOTP) and the WebAuthn/FIDO2 standards.
OAuth 2.0 is an authorization framework, not an authentication protocol, designed to let third-party applications act on a user's behalf at another service without ever handling that user's primary credentials. Several grant types suit different scenarios: the Authorization Code flow is the most secure and is used by server-side applications; PKCE extends this for single-page apps and mobile clients; the Client Credentials grant handles machine-to-machine communication; and Refresh Tokens let clients obtain new access tokens without re-prompting the user. In the Authorization Code flow, the user is redirected to an authorization server, authenticates there, grants consent, and is redirected back with a short-lived authorization code that the application exchanges server-to-server for an access token. Because tokens never traverse the browser in plaintext, this approach resists interception. JSON Web Tokens (JWTs) are a popular token format with three Base64Url-encoded parts: a header declaring the algorithm, a payload of claims such as user identity and expiration, and a signature that binds them together using HMAC or RSA. JWTs are stateless because the server can verify them without storing session state, but they carry common pitfalls: accepting alg: "none", storing them in localStorage where XSS can steal them, skipping signature validation, omitting an exp claim, embedding sensitive data (the payload is only encoded, not encrypted), and failing to provide a revocation mechanism.
OpenID Connect (OIDC) layers authentication on top of OAuth 2.0. Where OAuth answers "what can this application access on the user's behalf?", OIDC answers "who is this user?" by returning an ID token (typically a JWT) plus a /userinfo endpoint that exposes standardized claims such as openid, profile, and email. Together, these protocols form the backbone of modern federated identity: OAuth 2.0 for delegated authorization, OIDC for federated authentication, JWTs as a compact token format, and MFA layered on top to strengthen the initial authentication step. Secure session management complements these protocols on the server side by generating cryptographically random session identifiers, setting cookies with HttpOnly, Secure, and SameSite attributes, enforcing idle and absolute timeouts, regenerating the session ID after login to prevent session fixation, and invalidating sessions on logout.