Unlocking the Gates of Authentication

If you are building an application, you are eventually going to run into “Auth.” It is the backbone of application security, but the terminology can get muddy. It sounds scary, but it’s actually just a fancy way of asking, “Who are you, and are you allowed to be here?”

In this post, we are going to break down the digital security walls, look at why we moved away from older standards like Basic Auth, and do a deep dive into the industry standard for modern web apps: JWT (JSON Web Tokens).

“Who are you?” vs. “What can you do?”

First, let’s clear up the confusion between Authentication and Authorization. They sound similar, but in the architectural flow, they handle very different jobs.

• Authentication (AuthN): This verifies the user’s identity. Think of this as the “Gate” at a university. You present your credentials, like an ID card, to prove you are a student or a lecturer.
• Authorization (AuthZ): This determines your permission levels once you are inside. Just because you passed the gate doesn’t mean you can go anywhere. A student might have access to Lecture Hall A or Lecture Hall B, but not a Specific Lab or the Board Room.

In short, Authentication verifies your identity. Authorization determines your permission levels.

Authentication vs Authorization

How do we prove who we are?

To prove who we are, we usually use a mix of three things.

1. Something you know: Like a password.
2. Something you have: Like a mobile phone for an SMS code.
3. Something you are: Like your fingerprint or FaceID.

The Old School Way (Basic Authentication)

In the early days (and still for some simple apps and development environments), we used Basic Authentication.

Here, the client (your browser) sends the Username and Password to the server. The server says, “Yep, that matches,” and lets you in.

The Problem? The browser has to send your username and password with every single request. So,

• You are constantly transmitting sensitive credentials over the wire.
• The server has to re-verify the password against the database for every single API call.

Imagine trying to buy a coffee, but for every sip you take, you have to shout your bank account password to the barista. It’s inefficient and risky!

If you want to be a little more technical and dive in deep to see how basic auth works,

1. A client sends a request to a server to access a protected resource on the server.
2. The server responds with a 401 Unauthorized status, requesting username and password for authentication.
3. The client takes the username and password, puts them together, separating with a colon (username:password). Then this string is Base64 encoded. The resulting encoded string is sent to the server as part of the request header.
4. The server decodes the Base64 encoded credentials to retrieve the original username and password. It then verifies these credentials against its authentication database.
5. If verified successfully, the server returns HTTP status code 200 OK with the protected resource, or if it fails, the server returns HTTP status code 401 Unauthorized, telling the client that the provided credentials are unauthorized to access the resource.

Basic Authentication

The Modern Standard JWT (JSON Web Tokens)

Enter JWT. This is a compact, self-contained method for securely transmitting information between parties as a JSON object.

Get Geeneth Punchihewa’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Instead of sending credentials repeatedly, the server validates the user once and issues a signed token. The client stores this token and sends it in the HTTP Header for subsequent requests.

Think of it like a music festival wristband. You show your ID (password) at the gate once. They give you a wristband (Token). Now, you just show the wristband to get drinks, food, or enter the stage area.

JWT Authentication

What is inside a JWT?

A JWT is just a string of text, but it has three specific parts separated by dots. You can also find more details about this on jwt.io

Header . Payload . Signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

Header

Tells the server how the token was secured (the algorithm). Typically, the type of token (JWT) and the signing algorithm used (like HMAC SHA256 or RSA).

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

Contains the data (claims). This is where we put the User ID, their name, role, and when the token expires.

• Note: This allows the server to know who you are without querying the database every time!

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

Signature

This is the security seal. It is created by combining the Header, the Payload, and a Secret Key that only the server knows. The header and payload are encoded and combined with this secret. Then this string is hashed with the algorithm in the header.

signature = Hash(Base64Url(header) + Base64Url(payload) + secret)

How the Server Validates the Token

When a request comes in, the server takes the Header and Payload from the token and hashes them again using its private Secret Key. It then compares this new hash with the Signature attached to the token.

• If the signatures match, the token is valid.
• If a hacker tries to tamper with the Payload (e.g., changing their role from “user” to “admin”), the hash will change. Since the hacker doesn’t have the Secret Key, they can’t generate a valid signature, and the server rejects the request.

Access & Refresh Tokens

You might wonder if the token is valid until it expires, what if it gets stolen? If a hacker steals your JWT, they can pretend to be you. To fix this, we use two tokens:

1. Access Token: This is your main key. It has a short expiry time (e.g., 15 minutes) to minimize risk. You send this with every request.
2. Refresh Token: This is a special backup key (securely stored). It lasts longer (e.g., 7 days) but is only used when the Access Token expires.

When the Access Token expires (and the server returns a 401 error), the client sends the Refresh Token to a specific endpoint. The server validates it and issues a fresh Access Token without forcing the user to log in again.

Access and Refresh Token Usage

Conclusion

Authentication has evolved from simple credential checking to robust, token-based architectures like JWT. By understanding the distinction between AuthN and AuthZ, and implementing secure token strategies, you ensure your applications are not just functional, but secure and scalable.

I hope this guide helped unlock the mystery of authentication for you. Now, go forth and code safely!