Authentication

A fictional reading club lets Maya sign in, stay signed in while browsing, and edit her own reviews. Those are three decisions: establishing an account context, maintaining it, and checking permission for a particular action. Keeping them separate helps explain both good design and common mistakes.

An account is not automatically a real-world identity

Authentication establishes confidence that a claimant controls the expected authenticator: perhaps a password, a security key, or a device-bound credential. It does not necessarily prove a legal name. A pseudonymous account can authenticate correctly.

Authorization answers a different question: may this account edit this review now? Public content may permit anonymous reading, while editing requires an authenticated account and an ownership check. Strong authentication cannot repair missing authorization.

Remembering sign-in safely

A Session connects later interactions to the authenticated context. An opaque cookie can carry a random identifier while the server stores the associated state. Cookies are a browser delivery mechanism, not inherently passwords, signatures, or identity records.

The browser sends a cookie only when its matching and security rules allow. Secure, HttpOnly, and SameSite settings address different risks; none removes the need for expiry, appropriate request protections, and server-side checks. Logout should end the intended session, while account recovery may need to revoke other sessions too.

Maya changes her password. Are all devices signed out?

That depends on the application's session policy. A password change does not inherently invalidate every existing session or token. The design must define and implement what remains valid, and the interface should describe that behavior accurately.

Different credentials, different checks

HTTP Basic sends encoded account credentials in an authorization header. Base64 is not encryption; HTTPS protects transport. A Bearer token is accepted through possession within its permitted conditions. It can be opaque or use a format such as JWT. JWT is a format, not a guarantee of safety or encryption. Receivers must validate the intended issuer, audience, lifetime, and applicable permissions.

OAuth primarily supports delegated authorization. OpenID Connect adds an authentication layer. An access token and an ID token therefore have different recipients and jobs; they are not interchangeable login evidence.

Centralizing proof does not centralize every decision

Single sign-on lets applications rely on an identity provider and validate its assertions. Applications may then establish their own sessions and apply their own policies. Centralized protection and account management help, but provider outages, recovery, and stale sessions still require planning.

Mutual TLS can authenticate both connection peers using certificate validation and proof of the corresponding private keys. The keys are not transmitted. A certificate identifies a peer according to the trust configuration; it does not automatically grant every application action.

Choose mechanisms by the assurance, usability, and lifecycle the service needs. Continue with session lifecycles and object authorization to follow those decisions beyond sign-in.

Follow a request across the boundary

Maya opens her saved review. Her browser supplies its session identifier; the service looks up a valid session associated with her account. That answers which account context applies. Next, the application compares the account with the review’s owner and checks the requested action. These are two separate questions even when one library handles parts of both.

Suppose the club then gives Maya an event-editor role. The role permits updating meeting descriptions; it need not grant access to payment records or other members’ private drafts. A useful permission rule includes the subject, action, resource, and relevant context. “Signed in” is only one condition, not the entire rule.

When Maya stops volunteering, the role is removed. An old screen may still show an Edit button. That stale presentation cannot be the authority for the next request. The application needs a policy for evaluating current permissions and for handling cached claims or previously issued tokens. The effect may depend on token lifetime and revocation design, so interfaces should avoid promising an immediate universal change unless the system provides it.

PredictThe identity provider signs Maya out. Does that necessarily end every application session she previously opened?

No. Applications can have their own sessions and termination mechanisms. The system needs explicit arrangements for the intended logout or revocation behavior. A successful provider logout alone does not describe what every relying application has done.

Think of the lifecycle as a sequence of state changes: bind an authenticator, prove control, establish a session, evaluate requests, then expire or revoke the appropriate state. Recovery can change several of these states and deserves the same care as ordinary sign-in.

Explore identity, credentials, and sessions for the lifecycle, then authentication versus authorization for decisions about particular resources.