What Really Happens When You Log Into a Website Securely?

You open a website.

You enter:

Email: [email protected]
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: [email protected]
Password: MyPassword123

The browser prepares a login request.

Conceptually:

{
  "email": "[email protected]",
  "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:

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.