You open a website.
You enter:
Email: you@example.com
Password: ********
You click Log In.
A moment later, you're inside your account.
It looks simple:
Email + Password
↓
Database
↓
Logged In
But that's far from what actually happens.
A modern authentication system involves HTTPS, TLS, password hashing, databases, sessions, cookies, tokens, authentication, authorization, MFA, rate limiting, CSRF protection, and session management.
The real question isn't simply:
"Is the password correct?"
It's:
"How can the system securely prove who you are and continue recognizing you across thousands of requests?"
Let's follow the complete journey.
The Big Picture
A simplified secure login flow looks like this:
User
↓
Enter Credentials
↓
HTTPS / TLS
↓
Login Request
↓
Authentication Server
↓
Find Account
↓
Verify Password Hash
↓
Authentication
↓
Session / Token
↓
Secure Cookie
↓
Future Requests
↓
Authorization
↓
Protected Resources
There are two fundamental problems involved:
Authentication
Who are you?
Authorization
What are you allowed to do?
Understanding this distinction is fundamental to web security.
1. You Enter Your Credentials
Suppose you enter:
Email: nayan@example.com
Password: MyPassword123
The browser prepares a login request.
Conceptually:
{
"email": "nayan@example.com",
"password": "MyPassword123"
}
This information is extremely sensitive.
If it were transmitted over an insecure connection, someone monitoring the communication could potentially intercept it.
That's why secure websites use:
https://example.com/login
instead of:
http://example.com/login
The browser needs a secure communication channel before sending credentials.
2. HTTPS and TLS Secure the Connection
HTTPS is essentially HTTP running over TLS.
TLS stands for:
Transport Layer Security
It establishes a secure communication channel between your browser and the server.
Conceptually:
Browser
│
│ TLS Handshake
▼
Server
│
│ Secure Connection
▼
Encrypted HTTP
TLS provides three important security properties:
Confidentiality
Attackers should not be able to simply read the encrypted traffic.
Integrity
Attackers should not be able to silently modify the communication without detection.
Authentication
The server presents a certificate that helps the browser verify that it is communicating with the intended domain.
3. HTTPS Does Not Hash Your Password
This is a very common misunderstanding.
You might hear:
"HTTPS encrypts your password."
More precisely, HTTPS encrypts the communication channel.
The server receives the password through that secure channel and then performs password verification.
Browser
↓
HTTPS / TLS
↓
Internet
↓
Server
↓
Password Verification
So two different security mechanisms solve two different problems:
HTTPS / TLS
↓
Protects data while traveling
Password Hashing
↓
Protects passwords when stored
HTTPS protects credentials in transit.
Password hashing protects credentials at rest.
4. The Login Request Reaches the Backend
The request now travels through the internet and reaches the application's infrastructure.
A large application might look like:
Browser
↓
Internet
↓
CDN / Load Balancer
↓
Authentication Service
↓
Database
A load balancer can distribute requests across multiple application servers:
Login Requests
↓
Load Balancer
↓
┌─────────┼─────────┐
↓ ↓ ↓
Server A Server B Server C
This allows the authentication system to scale horizontally.
Instead of relying on one server, additional servers can handle increasing traffic.
5. The Server Finds Your Account
The authentication service needs to identify the account associated with the supplied email.
Conceptually:
Email
↓
Database Query
↓
User Record
A simplified user record could contain:
User ID
Email
Password Hash
Created At
Account Status
MFA Enabled
Notice what's missing:
Plain Password
A properly designed system should never store user passwords in plaintext.
Instead, the database stores information that allows the application to verify the password without storing the original password itself.
6. Password Hashing and Salting
Suppose the user's password is:
MyPassword123
The application should not store:
password = "MyPassword123"
Instead, it stores a password hash:
Password
↓
Password Hashing Algorithm
↓
Password Hash
Common password-hashing algorithms include:
- Argon2
- bcrypt
- scrypt
These algorithms are intentionally expensive to compute.
Why?
Because if an attacker obtains password hashes from a database, they may attempt huge numbers of password guesses. Making each guess computationally expensive increases the cost of such attacks.
What Is a Salt?
Suppose two users have the same password:
User A → password123
User B → password123
A salt adds unique random data before hashing:
Password + Random Salt
↓
Hashing
↓
Password Hash
So:
User A:
Password + Salt A → Hash A
User B:
Password + Salt B → Hash B
Even if both users choose the same password, their resulting hashes can be different.
Modern password-hashing algorithms generally handle salt generation and storage as part of their password-hash format.
7. Hashing Is Different From Encryption
Another important concept is the difference between encryption and hashing.
Encryption
Encryption is designed to be reversible using the appropriate key.
Original Data
↓
Encrypt
↓
Encrypted Data
↓
Decrypt
↓
Original Data
Hashing
Hashing is designed as a one-way transformation:
Password
↓
Hash
↓
Password Hash
During login, the server doesn't decrypt the stored password.
Instead, it verifies whether the supplied password matches the stored password hash.
Entered Password
↓
Password Verification
↓
Stored Password Hash
↓
Match?
If verification succeeds, the password is considered correct.
8. What Happens If the Database Is Stolen?
Imagine an attacker obtains the users table:
Users
-------------------------
Email
Password Hash
If passwords were stored in plaintext:
email → password123
the attacker could immediately obtain the password.
With strong password hashing:
email → $argon2id$...
the attacker instead faces the much harder problem of cracking the password hash.
This is why:
Password hashing is a defense against database compromise.
However, hashing does not make weak passwords magically safe.
Weak passwords can still potentially be discovered through guessing or cracking attempts.
That's why secure authentication systems combine multiple defenses:
- Strong password hashing
- Salting
- MFA
- Rate limiting
- Session security
- Account protection
9. The Server Verifies the Password
The server now has:
Email
Password
It retrieves the user's password hash and verifies the supplied password against it.
Conceptually:
Entered Password
↓
Password Verification
↓
Stored Password Hash
↓
Match?
/ \
Yes No
↓ ↓
Continue Reject
If verification fails, authentication fails.
A good authentication system should also avoid revealing unnecessary information, such as whether the email address exists, because overly specific error messages can help attackers enumerate accounts.
10. Authentication Succeeds — But the Story Isn't Over
Suppose the password is correct.
The server now knows:
This request has successfully authenticated as User 123.
But users don't make only one request.
After logging in, the browser may request:
GET /profile
GET /dashboard
GET /settings
GET /orders
GET /notifications
The server cannot ask for the password every time.
So the system needs a way to maintain authenticated state across future requests.
This is where sessions and tokens become important.
11. Session-Based Authentication
One common architecture uses server-side sessions.
The flow looks like:
Login
↓
Verify Credentials
↓
Create Session
↓
Generate Session ID
↓
Send Session ID to Browser
For example:
session_id = abc123xyz
The server may maintain a mapping such as:
abc123xyz → User 123
The browser doesn't need to send the password again.
Instead, it sends the session identifier.
The server uses that identifier to determine which authenticated user is making the request.
12. Cookies Maintain the Login
The server can send a cookie:
Set-Cookie: session=abc123xyz
The browser stores it.
For future requests:
Browser
↓
Cookie: session=abc123xyz
↓
Server
The server can then look up:
abc123xyz
↓
User 123
This allows HTTP, which is fundamentally stateless at the protocol level, to support a stateful login experience.
Authentication cookies should be carefully configured.
Important cookie attributes include:
Secure
The cookie should only be sent over HTTPS.
HttpOnly
JavaScript cannot directly access the cookie.
This can reduce the impact of some XSS attacks.
SameSite
Controls when cookies are sent in cross-site requests and can help protect against CSRF.
For example:
Set-Cookie: session=abc123;
Secure;
HttpOnly;
SameSite=Lax
The appropriate configuration depends on the application's architecture.
13. Token-Based Authentication
Another architecture uses tokens.
The basic flow becomes:
Login
↓
Verify Credentials
↓
Generate Token
↓
Client
↓
Future Requests
A request might contain:
Authorization: Bearer <access-token>
One well-known token format is JWT (JSON Web Token).
A JWT can contain claims such as:
User ID
Issued At
Expiration
The server can use the token to determine the authenticated identity and relevant claims.
But an important point is:
JWTs are not automatically more secure than sessions.
JWT is a token format. Whether a token-based architecture is appropriate depends on how tokens are issued, stored, validated, expired, revoked, and transported.
14. Sessions vs Tokens
A simplified comparison:
| Session-Based | Token-Based |
|---|---|
| Server maintains session state | Token can carry claims |
| Client sends session ID | Client sends token |
| Server-side invalidation is straightforward | Token lifecycle needs careful management |
| Common with browser cookies | Common in APIs and distributed architectures |
| Requires session storage | Stateless validation can be convenient |
Neither approach is universally better.
The correct choice depends on the application's architecture, requirements, threat model, and operational needs.
15. Authentication vs Authorization
Now we reach one of the most important concepts in security.
Authentication
Who are you?
For example:
User 123 is authenticated.
Authorization
What are you allowed to do?
For example:
User 123
↓
Authenticated
↓
Can access /profile
↓
Cannot access /admin
The complete flow is:
Authentication
↓
Identity Established
↓
Authorization
↓
Permissions Checked
↓
Resource Access
Being logged in does not automatically mean the user can access everything.
16. Roles, Permissions, 401 and 403
Many systems assign roles:
User
Admin
Moderator
Manager
For example:
Request /admin/users
↓
Authenticated?
↓
Yes
↓
Has Admin Role?
/ \
Yes No
↓ ↓
Allow 403
This is commonly called Role-Based Access Control (RBAC).
More advanced systems can also use permission-based or attribute-based authorization.
Two HTTP status codes are especially important:
401 Unauthorized
Usually indicates that valid authentication credentials are missing or invalid.
Not Authenticated
↓
401
403 Forbidden
The user is authenticated but doesn't have permission to perform the requested action.
Authenticated
↓
No Permission
↓
403
This distinction is particularly useful when designing APIs.
17. MFA Adds Another Layer of Security
A password is only one authentication factor.
Multi-Factor Authentication (MFA) adds another factor.
For example:
Password
+
Authenticator Code
A simplified flow:
Email + Password
↓
Password Verified
↓
MFA Challenge
↓
OTP / Authenticator / Security Key
↓
Verification
↓
Login Complete
The idea is that compromising one factor isn't necessarily enough to access the account.
MFA therefore adds another security barrier beyond the password itself.
18. Rate Limiting, Session Expiration and Logout
Authentication systems also need to control how long and how frequently credentials can be used.
Rate Limiting
Without rate limiting, an attacker could attempt:
1 attempt
10 attempts
1,000 attempts
1,000,000 attempts
A system can introduce rate limits:
Too Many Requests
↓
Rate Limit
↓
Reject / Delay
Other defenses can include:
- CAPTCHA
- Suspicious-login detection
- MFA
- IP/device reputation
- Temporary delays
The goal is to make automated attacks significantly harder.
Session Expiration
Authentication credentials shouldn't necessarily remain valid forever.
Login
↓
Session Created
↓
User Uses Website
↓
Session Expires
↓
Login Required Again
Systems can also use:
- Session rotation
- Token expiration
- Refresh tokens
- Logout invalidation
- Device/session management
Short-lived credentials can reduce the amount of time a stolen credential remains useful.
Logout
For a server-side session:
Logout
↓
Invalidate Session
↓
Session ID No Longer Valid
The browser can also remove the associated cookie.
For token-based systems, logout strategies depend on the token architecture and can involve revocation, short-lived access tokens, or refresh-token management.
19. CSRF, XSS and Federated Login
A secure authentication system also has to defend against attacks that go beyond password guessing.
CSRF
Cross-Site Request Forgery (CSRF) occurs when a malicious website attempts to cause a user's browser to make an unwanted authenticated request to another website.
For example:
User logged into bank.com
↓
Malicious Website
↓
POST /transfer
Depending on the request and cookie configuration, the browser may automatically include authentication cookies.
Defenses can include:
- SameSite cookies
- CSRF tokens
- Origin/Referer validation
- Appropriate request design
XSS
Cross-Site Scripting (XSS) occurs when an attacker manages to inject malicious JavaScript into a page viewed by users.
Conceptually:
User Input
↓
Stored Unsafely
↓
Rendered as HTML
↓
Malicious JavaScript Executes
XSS can be particularly dangerous around authentication because attackers may attempt to access sensitive application data or perform actions as the user.
HttpOnly cookies help prevent JavaScript from directly reading authentication cookies, but they are only one defense. Secure output handling, Content Security Policy, and proper application design are also important.
Continue With Google
Modern websites often provide:
Continue with Google
Continue with GitHub
Continue with Apple
This can involve OAuth 2.0 and OpenID Connect, depending on the provider and flow.
Conceptually:
Your Website
↓
Identity Provider
↓
User Authenticates
↓
Identity Provider Confirms Identity
↓
Your Website Receives
Authorization / Identity Information
↓
User Logged In
The important idea is that your application doesn't necessarily need to directly handle the user's Google password.
OpenID Connect adds an identity layer on top of OAuth 2.0 for authentication use cases.
20. What Happens on Every Request After Login?
This is where the entire authentication architecture comes together.
Suppose you've already logged in and request:
GET /dashboard
A simplified flow becomes:
Browser
↓
Cookie / Token
↓
Server
↓
Authenticate
↓
Authorize
↓
Application Logic
↓
Database / Services
↓
Response
↓
Browser
Notice something important:
Authentication isn't necessarily a one-time event.
The application needs a reliable mechanism to establish the user's identity on subsequent requests.
Putting everything together:
User
↓
Enter Credentials
↓
HTTPS/TLS
↓
Login Request
↓
Load Balancer
↓
Authentication Service
↓
User Lookup
↓
Password Hash Verification
↓
┌────┴────┐
↓ ↓
Invalid Valid
↓ ↓
Reject MFA
↓
Create Session
↓
Secure Cookie
↓
Future Requests
↓
Authentication
↓
Authorization
↓
Protected Data
Behind this simple flow are many security mechanisms working together:
- HTTPS / TLS
- Password hashing
- Salting
- Sessions
- Cookies
- Tokens
- Authentication
- Authorization
- MFA
- Rate limiting
- CSRF protection
- XSS protection
- Session expiration
- OAuth / OpenID Connect
Final Takeaway
When you click Log In, the process isn't simply:
Email + Password
↓
Database
↓
Logged In
It's much closer to:
Credentials
↓
HTTPS / TLS
↓
Authentication Service
↓
User Lookup
↓
Password Hash Verification
↓
MFA
↓
Session / Token
↓
Secure Cookie
↓
Authentication
↓
Authorization
↓
Protected Resources
And that's only the beginning.
A production authentication system also has to consider password recovery, session expiration, CSRF, XSS, brute-force attacks, MFA, account takeover, token security, device management, and logout.
The fascinating part is that every time you click Log In, you're not simply proving that you know a password.
You're establishing a trusted identity that the application can securely recognize across future requests.
So the next time you click Log In, remember:
You're not just entering a password. You're establishing a secure identity between your browser and a distributed backend system.
Top comments (0)