What Happens When You Click “Login”? Understanding Authentication for Beginners

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: u***@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: s**@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: "s**@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": "s**@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: s**@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 = 's**@example.com'; The database might return something like: id: 42 email: s**@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: s**@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 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 →