Identity, credentials, and sessions

Maya joins a fictional online reading club as “RiverReader.” The service assigns her an internal account identifier. Her display name helps people recognize her, but it is not a secret and may change. The account identifier lets the service connect her reviews, preferences, and access decisions without relying on a nickname as proof.

Identity has more than one meaning

Identity proofing establishes confidence in a claimed identity using an appropriate process and evidence. A service that verifies professional qualifications has different needs from a casual book club. Authentication instead checks control of an authenticator associated with an account. A pseudonymous member can authenticate correctly without having supplied a legal name.

A password is a knowledge-based authenticator. A cryptographic authenticator can prove control of a key without transmitting the private key. A local device check may unlock use of that key. These distinctions explain why seeing a username or unlocking a screen is not automatically evidence that a remote service accepted a sign-in.

A session continues the context

After sign-in, the club may issue a cookie containing an unpredictable identifier. The server connects that identifier to session state: which account authenticated, when, and under what conditions. The next page request can refer to that session instead of asking Maya to repeat the original proof each time.

The cookie is the browser’s delivery mechanism. It does not need to contain a password or a readable identity record. The application must still check that the session is valid, and separately decide whether the requested action is allowed. An expired session cannot be made current merely by keeping an old browser tab open.

Endings need explicit rules

An inactivity timeout and an overall lifetime solve different problems. The first limits idle sessions; the second limits how long authentication remains sufficient even if activity continues. Exact durations depend on the service and its requirements. A sensitive action may also require fresh authentication.

PredictMaya changes her password on her laptop. Must her phone’s existing session end immediately?

Not automatically. The application must define and implement whether password changes revoke other sessions. The phone may hold an independently valid session or token. The interface should make the actual behavior clear.

Recovery is another path to control

Maya loses a device. Recovering the account means establishing enough confidence to bind replacement authenticators or restore access. A strong everyday sign-in method is undermined if recovery accepts much weaker evidence without considering the consequences. Accessible recovery still matters: protection that permanently excludes legitimate members creates another failure.

Separate the decisions: replace the lost authenticator, invalidate its future use, and review sessions that were already established. These actions are related but need not happen automatically together. A useful account interface explains which devices remain connected and which recovery methods are available.

Finally, a successful sign-in says nothing by itself about permission to edit another member’s review. Follow the account context into authentication versus authorization to see the next decision.