You enter your email and password on a website, click Login, and suddenly you're inside your account.

It feels like a simple action.

But what actually happens after you click that button?

How does the website know that the email and password belong to you?

Where does the password go?

How does the server remember that you've logged in?

And how does it know what you're allowed to access?

Let's follow the journey of a login request from the browser to the backend and back.

The Big Picture

Imagine a website with a login form:

Email:    user@example.com
Password: ********

        [ Login ]

You enter your credentials and click Login.

A simplified version of what happens is:

Login Form
    ↓
Browser / JavaScript
    ↓
HTTP Request
    ↓
Backend API
    ↓
Database
    ↓
Password Verification
    ↓
Session / Token
    ↓
HTTP Response
    ↓
User Logged In

Let's break this down using a simple example.

1. You Enter Your Credentials

Suppose you enter:

Email:    sam@example.com
Password: MyPassword123

and click Login.

The browser now has the information that you entered.

But the browser doesn't decide whether the credentials are correct.

The backend needs to verify them.

So the browser sends the login information to a backend endpoint.

2. The Browser Sends a Request

A frontend application might send a request using JavaScript:

fetch("/api/login", {
    method: "POST",
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        email: "sam@example.com",
        password: "MyPassword123"
    })
});

The important part here is:

POST /api/login

The browser is basically saying:

"Here are the credentials the user entered. Please process this login request."

The request body might look like:

{
    "email": "sam@example.com",
    "password": "MyPassword123"
}

This request should be sent over HTTPS, so the credentials are protected while traveling between the browser and server.

3. What Is an API Endpoint?

You may have seen URLs such as:

/api/login
/api/users
/api/products
/api/orders

These can be API endpoints.

An API endpoint is a specific location where a client can communicate with a backend operation.

For our login example:

POST /api/login

is the endpoint responsible for handling the login request.

The browser communicates with the backend through this API instead of directly accessing the database.

The architecture can look like:

Browser
   ↓
API
   ↓
Backend
   ↓
Database

The frontend should not directly connect to your database.

4. The Backend Receives the Request

Now the request reaches the backend.

For example, an Express.js application might have something like:

app.post("/api/login", async (req, res) => {
    const { email, password } = req.body;

    // Login logic goes here
});

The backend receives the email and password.

But it should not blindly trust the data coming from the browser.

The server needs to validate it.

5. The Backend Validates the Input

The backend might check:

Is an email provided?
Is a password provided?
Is the email valid?
Are the values in the expected format?

For example, if the user submits:

{
    "email": "",
    "password": ""
}

the server can reject the request.

This is called input validation.

Validation is important because data coming from the client can never be assumed to be trustworthy.

6. The Backend Looks for the User

Suppose the email is:

sam@example.com

The backend needs to find out whether an account with that email exists.

It might query the database:

SELECT id, email, password_hash
FROM users
WHERE email = 'sam@example.com';

The database might return something like:

id: 42
email: sam@example.com
password_hash: $2b$12$...

Notice something important.

The database does not contain:

password: MyPassword123

Instead, it contains a password hash.

Why?

7. Passwords Should Not Be Stored as Plain Text

Imagine a database storing passwords like this:

sam@example.com → MyPassword123

If the database were compromised, attackers could immediately see the users' passwords.

That's why applications should not store user passwords as plain text.

Instead, passwords are processed using dedicated password-hashing algorithms such as:

• bcrypt
• scrypt
• Argon2

The basic idea is:

Password
   ↓
Password Hashing
   ↓
Password Hash
   ↓
Database

The database stores the hash rather than the original password.

8. How Does Password Verification Work?

Now you might wonder:

"If the original password isn't stored, how can the server check whether my password is correct?"

Good question.

When you log in, the server takes the password you entered and uses the password-hashing algorithm to verify it against the stored password hash.

Conceptually:

Password entered by user
          ↓
   Password verification
          ↓
Stored password hash
          ↓
     Match or not?

If the password doesn't match:

Authentication Failed

If it matches:

Authentication Successful

The server does not need to retrieve the original password from the database.

9. Authentication — Who Are You?

This brings us to the main concept of the article:

Authentication.

Authentication means verifying the identity of a user.

When you enter your email and password, the application is essentially asking:

"Are you really the user associated with these credentials?"

If the credentials are correct:

Authentication → Successful

If they aren't:

Authentication → Failed

But authentication is not the same as authorization.

Authentication vs Authorization

These two words are easy to confuse.

Authentication

Who are you?

For example:

Login successful
       ↓
You are Sam

Authorization

What are you allowed to do?

For example:

You are Sam
     ↓
Are you allowed to access /admin?
     ↓
No

So:

Authentication → Who are you?
Authorization  → What can you access?

You can be successfully authenticated but still not have permission to access certain resources.

10. The Server Needs to Remember Your Login

Here's another interesting problem.

HTTP is largely stateless.

That means one request doesn't automatically mean the server remembers everything about previous requests.

Imagine you successfully log in:

POST /api/login

Then you request:

GET /profile

How does the server know that the /profile request belongs to the user who just logged in?

The application needs some way to maintain authentication state.

Two common approaches are:

Session-based authentication
            OR
Token-based authentication

Let's understand both at a high level.

11. Session-Based Authentication

In session-based authentication, the server creates a session after successful login.

The simplified flow is:

User logs in
     ↓
Credentials verified
     ↓
Server creates a session
     ↓
Session ID sent to browser
     ↓
Browser sends session ID with future requests

The browser commonly stores the session identifier in a cookie.

For example:

session_id=abc123

Later, when you request your profile:

GET /profile
Cookie: session_id=abc123

The server can use that session ID to identify the authenticated user.

So the flow becomes:

Browser
   ↓
Session Cookie
   ↓
Server
   ↓
Session
   ↓
User identified

12. What Is a Cookie?

A cookie is a small piece of data that a website can ask the browser to store and send with relevant requests.

Cookies can be used for many things, including:

• Login sessions
• User preferences
• Shopping carts
• Other application state

For authentication, a cookie can contain a session identifier.

Security-sensitive cookies are commonly configured with attributes such as:

Secure
HttpOnly
SameSite

These attributes help protect authentication cookies against certain attacks and misuse.

13. Token-Based Authentication

Another approach is token-based authentication.

After a successful login, the server issues a token.

One commonly used token format is JWT (JSON Web Token).

The simplified flow is:

User logs in
     ↓
Credentials verified
     ↓
Server creates token
     ↓
Browser receives token
     ↓
Future requests include token
     ↓
Server validates token

A request might contain:

Authorization: Bearer <token>

The server can validate the token and determine whether the request is authenticated.

One important point:

JWT is a token format, not a synonym for authentication.

Authentication is the overall process of verifying identity.

JWT is simply one technology that can be used to carry authentication-related information.

14. The Server Sends a Response

Once authentication succeeds, the backend sends an HTTP response to the browser.

For example:

HTTP/1.1 200 OK

The response might contain:

{
    "message": "Login successful"
}

The response can also establish authentication state, such as setting a session cookie.

If authentication fails, the server sends an appropriate error response instead.

For example:

Invalid credentials

The frontend can then display an error message to the user.

15. The User Is Now Logged In

After successful authentication, the browser has the information required to make authenticated requests.

For example:

Login
  ↓
Authentication successful
  ↓
Session / Token
  ↓
GET /profile
  ↓
Server identifies user
  ↓
Profile returned

That's why after logging in, you can move between pages without entering your password every time.

The browser keeps sending the relevant authentication information, and the server uses it to recognize the user.

What Happens If the Login Fails?

Let's say Sam enters the wrong password.

The flow becomes:

User enters credentials
        ↓
POST /api/login
        ↓
Backend
        ↓
Find user
        ↓
Verify password
        ↓
Password doesn't match
        ↓
Authentication failed
        ↓
HTTP response
        ↓
Browser shows error

The user might see:

Invalid email or password

The application should also avoid revealing unnecessary information about whether a particular account exists.

The Complete Login Journey

Now let's put everything together.

User enters email + password
            ↓
       Clicks Login
            ↓
     Browser / JavaScript
            ↓
      POST /api/login
            ↓
        Backend API
            ↓
      Validate input
            ↓
     Find user in database
            ↓
    Retrieve password hash
            ↓
     Verify password
            ↓
       ┌───────────────┐
       │               │
     Failed         Successful
       │               │
       ↓               ↓
 Error response    Create session
                       or token
                        ↓
                  HTTP response
                        ↓
                     Browser
                        ↓
               Authenticated user

A simple login button can trigger all of this behind the scenes.

A Simple Mental Model

You don't need to memorize every technical term.

Think of the process as a story:

I enter my credentials → the browser sends them to the backend → the backend validates the request → finds my account → verifies my password → creates authentication state → sends a response → the browser uses that state for future requests.

Or simply:

Login Form
    ↓
POST Request
    ↓
Backend
    ↓
Database
    ↓
Password Verification
    ↓
Session / Token
    ↓
Response
    ↓
Authenticated User

Final Takeaway

The next time you click a Login button, remember that the button itself isn't doing the authentication.

It starts a conversation between several parts of the application:

Browser
   ↓
API
   ↓
Backend
   ↓
Database
   ↓
Authentication
   ↓
Session / Token
   ↓
Browser

The browser collects the credentials and sends a request.

The backend validates the request and checks the user's account.

The password is verified against a stored password hash.

If everything is correct, the application creates some form of authentication state, such as a session or token.

That authentication state allows the server to recognize the user on future requests.

And that's the basic idea behind what happens when you click Login.

Thanks for reading!

If you're learning full-stack development, the next time you click Login, don't just think about the button.

Think about the entire conversation happening behind it.