How Auth Works

Authentication and Authorization are two words that sound simple at first, but quickly spiral into complexity once you try to implement them at scale. On the surface, spinning up a basic role-based auth system feels straightforward. There are endless tutorials, libraries, and guides that walk you through setting up login pages, token-based sessions, and even basic role checks. But let’s be honest, building authentication for a side project versus implementing auth for a production-grade application is two completely different challenges. What works for your personal project might collapse under the demands of a real-world, user-facing platform.

Things get even more complicated when you start thinking about scale. Just imagine, something as seemingly routine as integrating Google Drive for users requires finely tuned permission management, careful access controls, and tight security guarantees, all without affecting performance. As user interactions increase, so does the need for strategic database schema design, permission checks, and optimized query logic. Each layer of complexity demands precision, planning, and a deep understanding of how systems interact. In this article, we’ll explore how auth works at a higher level and why it’s much more than just logging users in and out. At the end of this series, you will be able to build a strong foundation in Authentication and Authorization.

Authentication vs Authorization

Authentication is when you tell the application that I am the legitimate user for this account by providing authentication credentials to the server. Authorization is permission that you have with your account. For example, when we log in to YouTube Studio, we can edit and modify options for the channels, which you are part of, which can be as an editor, manager, or owner, but you can't access other accounts. This is what authorization means.

How Authentication Works

First thing to know is that every part of Auth happens in the server, because we cannot trust the client. Let’s get into the workflow of Authentication and Authorization.

Clients communicate with the server by making requests to the server. When the user provides credentials to login, the client sends a request to the server with these data and ask the server are these credentials legit, and getting current credentials the server sends a token(JWT) or creates a session, for the client, now whenever the client make any request these generate token or session is used to validate their identity and these tokens and sessions do have a expire time, so then these token expire new token/session are created this is the flow for Authentication.

When an authenticated user tries to perform certain tasks, the client makes a request to the server, validating if the logged-in user is authorized to perform this task. This flow is referred to as Authorization.

So we can conclude that the source of truth is always the server for every action that we perform.

Server & Client Interactions

We can use local variables to render separate interactions for different users, i.e, users with different access and privileges, but before performing any action, we need to cross-check is the action is valid or accessible by the user.

Session-Based vs Token-Based

We previously discussed session-based and token-based authentication. Session-based authentication is commonly used for websites or applications that operate primarily in the browser. It's generally considered more secure than token-based authentication because the server maintains the authentication state, reducing the chances of data leaks and increasing the reliability of authenticated users.

However, session-based auth introduces challenges at scale. Since the server must create and store session information, the server load increases significantly. In modern microservice architectures, distributing session data across multiple servers becomes complex. It introduces a single point of failure, which often requires replicating session data, adding more infrastructure overhead, and operational complexity. Despite these drawbacks, session-based authentication remains a strong option for scenarios where enhanced security and server-side session control are priorities.

Token-based authentication is generally considered less secure compared to session-based authentication, but it's often easier to implement and scale. In this approach, the server generates a token that is stored on the client side, usually in local storage or cookies. This is necessary because users wouldn’t want to re-enter their credentials every time they act.

These tokens contain encoded information (or keys) that help the server identify the user. However, to ensure security, the server does not send raw user data. Instead, it sends an encrypted token (commonly a JWT, i.e, JSON Web Token) that the client cannot decode without a secret key. When the client makes a request, it sends the token, which the server then decrypts and validates before allowing access.

However, this system introduces a single point of failure—the token itself. If it’s compromised, access is at risk. To mitigate this, we typically use two tokens: a short-lived access token and a long-lived refresh token. When the access token expires, the client can use the refresh token to securely request a new access token, maintaining the session without requiring the user to log in again.

when to use session based authentication

• Web-Only Applications: Ideal for traditional web apps running in browsers (e.g., Django/Express apps with server-rendered pages).

• Higher Security Needs: Server holds the session state, making it harder to tamper with on the client side.

• Centralized Infrastructure: When your app is hosted on a single or tightly-coupled server.

• Short-Lived Sessions: Great for apps with short, controlled user sessions (e.g., banking dashboards, admin panels).

• Secure Storage: Prevents token theft, since session data isn’t stored on the client.

• Built-in CSRF Protection: Works well with anti-CSRF tokens since sessions are server-managed.

  Avoid for highly distributed or stateless architectures (like microservices or mobile apps).