OAuth, OpenID Connect, and Sessions: Which Problem Does Each Solve?

Login implementations become confusing when every token is treated as proof that a user is signed in. OAuth, OpenID Connect, and application sessions are related, but each solves a different problem. OAuth provides a framework for delegated authorization: letting a client obtain limited access to a service. OpenID Connect adds an identity layer. An application session then determines how your own product recognizes the user across subsequent requests. ## An access token is for its intended API An access token authorizes calls to a particular resource server under defined permissions. It is not a universal identity document. A token issued for one API should not automatically grant access to another application. OpenID Connect defines ID tokens with identity-related claims. Correct validation includes issuer, audience, signature, expiration, and applicable flow-specific protections. Simply decoding a JWT reveals its contents; it does not validate the signature or establish that the token was meant for your app. Use a maintained authentication library and the provider's documented flow. Handwritten token validation often misses key rotation, discovery, or subtle protocol requirements. ## Protect the redirect flow Authorization code flows typically send the browser to an identity provider and return it to a registered callback. Strict redirect URI handling reduces opportunities for sending credentials to an attacker-controlled destination. PKCE binds authorization-code redemption to the client that initiated the flow. State and nonce have distinct roles in the applicable protocols and should be managed by the authentication implementation rather than replaced with arbitrary constants. Keep login errors understandable without revealing sensitive protocol details. Preserve the intended return destination safely, and reject open redirects that could send a newly authenticated user to an untrusted site. ## Your application still needs session rules After identity is verified, many web applications create their own server-backed session and send an opaque cookie. Others use different supported architectures. Choose deliberately rather than placing every available token in browser storage. Cookies should use appropriate `HttpOnly`, `Secure`, and `SameSite` settings. Cookie-based authentication also requires an explicit CSRF strategy. Rotate sessions when appropriate, define idle and absolute expiration, and invalidate access when account status changes. Logging out of your application does not necessarily log the person out of their identity provider. Revoking API access and ending a browser session are also different operations. The practical lesson is to label each credential by purpose, audience, and lifetime. When those boundaries are clear, it becomes much easier to answer which system trusts a token and what a stolen credential could actually do. ## Further reading - [OpenID Connect overview](https://openid.net/developers/how-connect-works/) - [OWASP: OAuth 2.0 protocol cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html)