User Authentication Flow — sign-up to validated session
A user authentication flow on an interactive canvas: account creation, credential hashing and storage, sign-in, session creation, and validating protected requests.
A user authentication flow is the path from someone creating an account to every later request being trusted: credentials are hashed before storage, verified at sign-in, and a session token then stands in for the password.
User Authentication Flow — sign-up to validated session
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Read the three columns left to right: Sign-up, Sign-in, Session.
- The four lanes are the actors, and the password never leaves the top three — only hashes reach the Database lane.
- The "Hash matches the stored one?" decision splits sign-in into the session path and the "Sign-in denied" reject.
Sign-up
"User creates an account" and "Client sends email and password" feed "Auth service hashes the password" — the moment the password stops being recoverable. "Hashed credential is stored in the database" is the end of sign-up: the database now holds a salted hash, and its comment explains that the service cannot recover the plaintext, which is the point of hashing.
Sign-in
"User signs in with credentials" and "Client forwards them to the auth service" repeat the first half of the journey, and "Hash matches the stored one?" is the verification: the incoming password is hashed the same way and compared. The "No" branch ends at "Sign-in denied"; the "Yes" branch proceeds to create the session.
Session
"Auth service creates a session" issues the token that replaces the password, "Client stores the session token" moves it to the client, and "Protected requests carry the token; server validates it" is the steady state of the system — every protected request proves itself with the token. "Access granted for the session" closes the flow: the user is authenticated for the life of the session, not for a single request.
Key relationships and takeaways
- Passwords are hashed before storage — the database holds a salted one-way hash, never the plaintext.
- Sign-in compares hashes, so the auth service itself cannot recover the stored password.
- The session token replaces the password for subsequent requests, which is what makes authentication practical at scale.
- Storage and verification are separate concerns in different lanes, so each can be protected separately.
- The flow is the same shape whether the token is a server session or a JWT — see the JWT visual for the token mechanics.
When to use this visual
- Teaching a new team the secure shape of authentication before they design their first sign-in.
- Reviewing an auth flow for the classic flaws — storing plaintext, comparing plaintext, trusting the client.
- Grounding a conversation about multi-factor authentication and where it plugs into the flow.
How it works
Rename the actors to your system
Replace Client app and Auth service with your real components — your web app, your identity provider — and add the ones the generic diagram misses.
Add multi-factor authentication
Insert an MFA step at sign-in, between the hash check and session creation, with a branch for the second-factor verification.
Show the password reset path
Add a reset branch off the sign-in decision — forgot password, reset token, set new password — each ending in an explicit state.
Annotate the token lifecycle
On the session box, note your token's expiry, revocation and refresh rules, and link to the JWT visual if you issue JWTs.
Frequently asked questions
What is the secure way to store passwords?
Never store the password itself. Store a salted hash — a one-way function applied to the password plus a random salt — and discard the plaintext. At sign-in, hash the incoming password the same way and compare the hashes. If the database leaks, the attacker gets hashes they cannot reverse, which is exactly the property the visual's hashing boxes exist to show.
What is the difference between hashing and encryption?
Encryption is reversible — with the key you can recover the original value. Hashing is one-way — there is no key and no way back. For passwords you want hashing, because you never need the plaintext again, only the ability to verify. The visual says "hashes" rather than "encrypts" for this reason; encrypting passwords is a common and dangerous confusion.
How does a session token replace the password?
After a successful sign-in the auth service creates a session and hands the client a token — a random value, or a signed JWT — that stands for the authenticated user. Protected requests carry the token, and the server validates it instead of asking for the password again. That is what makes authentication practical for repeated requests, and it is why the token's expiry is the real security boundary.
Where does multi-factor authentication fit in this flow?
MFA is an extra check at sign-in, after the password is verified and before the session is created: the user provides a second factor — a one-time code, an authenticator app, a hardware key. The visual's sign-in column is where that step plugs in. MFA does not change the hashing or session mechanics; it raises the bar on the one decision, "Hash matches the stored one?", by adding a second proof.
Edit this visual in QueryChart (FlowJam)
Open this exact authentication canvas as your own chart, rename the actors to your system, and add your real controls.