You are probably wondering why this guy is writing an article on this. Is this some AI slop or what? They keep asking this question in interviews; it is our duty to put it out there and flood the internet with it until everyone easily understands it.

Besides, people have different ways of understanding different concepts. So after reading this article, go out there and write about it in your own words. The internet needs more of that.

The candy store door vs the candy aisle

Authentication is the candy store door. There's a guard at the entrance who checks your ID before letting you in. No ID, no entry. It does not matter how much you want the candy; you need to prove who you are first.

Authorization is the candy aisle. You're inside the store now, but that doesn't mean you can go everywhere. Customers stay in the aisles. The stockroom? Staff only. The manager's office? Don't even think about it. Where you're allowed to go depends on who you are, and that's authorization.

Authentication: Can you get through the door? → prove who you are

Authorization: Which aisles can you walk down? → decided once you're inside

How it actually works in software — JWT

When you log into an app, the server needs a way to remember you without asking for your password on every single click. This is where JSON Web Tokens (JWT) come in.

Think of a JWT as the receipt the guard gives you after checking your ID at the candy store door. Every time you want to grab something off a shelf, you show the receipt, so the staff doesn't need to call the guard again. They check the receipt and know exactly who you are and what you're allowed to pick up.

A JWT has three parts separated by dots:

header.payload.signature

Header → algorithm used to sign it
Payload → user info, roles, expiry
Signature → proof it hasn't been tampered with

The server signs the token when you log in. Every request you make after that carries the token in the header. The server verifies the signature, and if it checks out, it trusts the payload. No database lookup needed on every request. Fast, stateless, and widely used in REST APIs

Authorization in the real world — RBAC

Once a user is authenticated, the system needs to decide what they can do. The most common approach is Role-Based Access Control (RBAC).

Instead of assigning permissions to individual users which gets messy fast, you assign them to roles. Then users are given a role. Back to the candy store: customers can browse the aisles, staff can access the stockroom, and managers can open the safe. Same store, completely different access.

Role    Can read    Can delete
Admin   Yes         Yes
Editor  Yes         No
Viewer  Yes         No

In a JWT, the user's role is often stored right in the payload. So when the server decodes the token, it sees role: admin and knows exactly what that person is allowed to do no extra database call required.

Putting it all together

Here's the full flow in a typical web app:

1. User logs in with credentials → server verifies → authentication (through the door)
2. Server issues a signed JWT with the user's role baked in (the receipt)
3. User sends JWT on every request
4. Server checks the role in the token → grants or denies access → authorization (which aisle)