Authentication

Overview JWT and session-based authentication both prove who a user is on every request, but they disagree about where that proof lives. A JWT is a signed, self-contained token the client carries and the server checks locally, while session-based auth hands out a small ID that maps to state the server stores and looks up on every call. That single difference in where state lives cascades into how each approach scales, revokes access, and fits different architectures. ...

Overview OAuth and SAML both let one system vouch for a user to another, but they solve different problems: OAuth is an authorization framework built to grant apps limited access to APIs, while SAML is an XML-based standard built for enterprise single sign-on. Picking the wrong one means using a token-delegation protocol for an identity-federation problem, or vice versa. Comparison Diagram OAuthdelegated authorizationSAMLfederated authenticationClient AppAuthorizationServerAccess Token{ JSON }Resource APIService ProviderIdentity ProviderSAML Assertion<XML>SP Session Comparison Table Aspect OAuth SAML Primary purpose Authorization - grants an app limited, scoped access to resources Authentication - proves a user’s identity for single sign-on Assertion/token format JSON, most commonly a JWT access token XML, a digitally signed SAML assertion Flow initiation Client app redirects the user to an authorization server to request consent Service provider redirects the user to an identity provider to authenticate Credential delivery Access token returned via redirect or back-channel to the client Signed assertion POSTed back to the service provider’s endpoint Transport mechanism REST/HTTP calls carrying a bearer token in the Authorization header HTTP redirect and POST bindings, historically also SOAP Session establishment Client presents the token on each API call to prove access rights Service provider validates the assertion once and creates a local session Lifetime and renewal Short-lived access tokens paired with long-lived refresh tokens Assertions tied to the SSO session with no built-in refresh mechanism Typical ecosystem Mobile apps, SPAs, and third-party API integrations (Google, GitHub) Enterprise SSO into web apps via IdPs like Okta, ADFS, or Azure AD Key Differences OAuth is fundamentally an authorization framework, not an identity protocol, though OpenID Connect layers authentication on top of it. SAML assertions are XML-based and signed, while OAuth tokens are typically JSON, often as a JWT. SAML is built around browser redirects and POST bindings for SSO, while OAuth is built around bearer tokens for API calls. OAuth supports refresh tokens for renewing access; SAML assertions have no native renewal and rely on re-authentication. When to Use Each OAuth ...

Overview Authentication (AuthN) confirms who a user or system claims to be, typically through credentials like passwords, biometrics, or tokens. Authorization (AuthZ) determines what an already-authenticated identity is permitted to do or access. The two are sequential and often conflated, but security bugs frequently trace back to confusing one for the other — e.g., checking that a user is logged in without checking they’re allowed to see a specific resource. ...