01.01 · Concept · Free
What a User Actually Is
Name the four separate things a 'user' collapses - identity, credential, session and authorization - and say which of them a database row actually holds.
Curated for this lesson1/3
Identity & Authentication
An Illustrated Guide to OAuth and OpenID Connect
OAuth and OpenID Connect naturally separate identity, credentials, sessions, and authorization for beginner web engineers.
A user is not one thing: it is identity, credential, session and authorisation being casually named with the same word. The database row usually represents identity, while login proofs, active logged-in state and permission decisions should be treated as separate parts of the system.
What this lesson answers
- what does user mean in authentication systems
- difference between identity credential session and authorisation
- what belongs in a users database table
Notes
In everyday product code, the word “user” often means too many things at once. It can mean an identity, which is the stable record saying “this is Alice’s account.” It can mean a credential, such as a password, passkey, API key, or OAuth login proof used to verify a claim. It can mean a session, which is the temporary logged-in state attached to a browser, device, token, or cookie. It can also mean authorization, which is the set of things the current actor is allowed to do.
A useful mental model is to imagine entering an office. Your employee profile is your identity. Your badge or fingerprint is your credential. The fact that security let you into the building today is your session. The doors your badge opens are your authorization. These are related, but they are not the same object, and good systems keep their boundaries clear.
The common misconception is “the users table is the user.” Usually, a database row mostly stores identity data: an internal user id, email address, display name, creation time, and account status. It may reference credentials, but it should not be confused with the password or login method itself. It may be associated with active sessions, but those are separate and expire. It may have roles or permissions attached, but those are authorization decisions layered on top of identity.
After this lesson, you should be able to look at an authentication bug and ask which layer is failing. Is the identity record missing or duplicated? Is the credential invalid or compromised? Is the session expired, stolen, or not being sent? Or is the user correctly logged in but not authorized for the action? That separation makes auth systems easier to design, debug, and secure.
References
Common questions
- Is a user row the same thing as a logged-in user?
- No. A user row usually stores identity data such as an internal account reference, email, name and status. A logged-in user means there is also a valid session proving that some actor recently authenticated. The row can exist without any active session, and a session should be revocable without deleting the identity.
- Where do credentials fit if the users table stores identity?
- Credentials are the evidence used to prove control of an identity, such as a password, passkey, API key or external login proof. They may be referenced from an identity record, but they are not the identity itself. Keeping that distinction makes rotation, compromise handling and multiple login methods much cleaner.
- Why separate authentication from authorisation in product code?
- Authentication answers who the actor has proved themselves to be. Authorisation answers what that actor may do right now. Mixing them causes bugs where being logged in is treated as enough permission. Separating them lets you diagnose whether a failure is identity lookup, credential verification, session state or access control.