Imagine logging into an application.
You enter your email and password, click Login, and land on your dashboard. Everything works as expected.
Now, suppose you try accessing the admin dashboard, but the application denies access.
You're already logged in. So why can't you access it?
Because knowing who you are and deciding what you're allowed to do are two different things.
This is where Authentication and Authorization come in. They are two fundamental concepts in backend development, and almost every application that handles users relies on them.
Although they often work together, they solve two completely different problems.
1. Authentication: Who Are You?
Authentication is the process of verifying the identity of a user or system.
It answers one simple question:
"Are you really who you claim to be?"
Think about what happens when you log into an application. You provide credentials such as:
- Email address
- Password
- One-time password (OTP)
- Biometric information
The backend receives the credentials and verifies them against the information stored for that user.
For example, consider a login request:
{
"email": "alex@example.com",
"password": "mypassword"
}
The backend checks whether the supplied credentials are valid. In a properly secured application, passwords are stored as password hashes rather than plain text, and the submitted password is verified against the stored hash.
If verification succeeds, the backend establishes an authenticated identity for the user.
The application now knows that the request belongs to Alex.
But here's an important question:
Does successfully logging in mean Alex can access everything in the application?
Not necessarily.
That's where authorization comes in.
2. Authorization: What Can You Do?
Authorization determines what an authenticated user is allowed to access or perform.
It answers a different question:
"Given who you are, what are you allowed to do?"
Let's take an example of an e-commerce application with three types of users:
| User | Permissions |
|---|---|
| Customer | Browse products, place orders, view their own orders |
| Manager | Manage inventory, view orders, update product details |
| Admin | Manage users, products, orders, and application settings |
All three users can successfully log in.
Authentication establishes their identities, but authorization determines what actions each user can perform.
For example, a customer might successfully log in and view their orders. However, if they try to delete another user's account, the backend should reject the request.
The customer is authenticated, but they aren't authorized to perform that operation.
This distinction is important because being authenticated doesn't automatically mean being authorized.
3. How Do Authentication and Authorization Work Together?
Let's connect these concepts through a typical backend request.
Suppose Alex logs into an application and tries to access an administrative API.
The backend follows two important steps:
Authentication: Verify Alex's identity.
Authorization: Check whether Alex has permission to access the requested resource.
The simplified flow looks like this:
USER
|
v
LOGIN REQUEST
|
v
AUTHENTICATION
Verify Identity
|
Is Identity
Valid?
/ \
No Yes
| |
v v
Reject Authenticated
Request User
|
v
API REQUEST
|
v
AUTHORIZATION
Check Permissions
|
Is Access Allowed?
/ \
No Yes
| |
v v
Reject Process
Request Request
There are two separate decisions being made:
Is this request associated with a verified identity?
Is that identity allowed to perform the requested operation?
If authentication fails, the backend cannot establish the identity needed for an authenticated operation.
If authentication succeeds but authorization fails, the user is recognised but doesn't have the required permission.
This separation allows applications to manage user identity and access control independently.
4. Understanding 401 and 403
While working with APIs, you'll frequently encounter two HTTP status codes related to access control:
401 Unauthorized
Despite its name, 401 Unauthorized generally means that the request lacks valid authentication credentials.
For example:
A user hasn't logged in.
An authentication token is missing.
A token is expired or invalid.
The backend cannot establish a valid authenticated identity for the request.
403 Forbidden
403 Forbidden means the server understood the request but refuses to allow the requested operation.
For example:
A customer tries accessing an admin-only API.
A user attempts to modify a resource they don't have permission to modify.
In this case, the user may already be authenticated, but they don't have the required permissions.
A simple way to remember the difference:
401: The request isn't properly authenticated.
403: The request is authenticated, but access is not permitted.
5. Where Should These Checks Happen?
One common mistake in application development is relying entirely on the frontend to control access.
Imagine an application that hides the Delete User button from regular customers.
It might seem secure because customers cannot see or click the button.
But the frontend is not a security boundary.
A user can inspect the application's code, modify client-side state, or send an API request directly using tools such as Postman or cURL.
For example:
DELETE /api/users/42
Even if the frontend hides this operation, the backend endpoint still exists.
If the backend doesn't verify the user's permissions, an unauthorized user might successfully perform the operation.
That's why authentication and authorization checks must be enforced on the backend.
The frontend can improve the user experience by hiding unavailable features, but the backend must make the final access decision.
6. The Key Takeaway
Authentication and authorization are closely related, but they shouldn't be treated as the same thing.
Think of entering an office building.
Your identity card helps establish who you are. But having an identity card doesn't mean you can enter every room.
Some rooms require additional permissions based on your role.
That's authentication and authorization working together.
| Authentication | Authorization |
|---|---|
| Verifies identity | Checks permissions |
| Answers "Who are you?" | Answers "What can you do?" |
| Uses credentials and identity verification | Uses roles, permissions, and access rules |
| Establishes an authenticated identity | Determines access to protected operations |
Both are essential for building secure backend applications.
Authentication establishes trust in an identity, while authorization determines what that identity is allowed to do.
What's Next?
Now that we understand how a backend identifies users and controls their access, there's another interesting question:
How does a backend remember that you've already logged in?
HTTP is stateless. Every request is independent, so how does a server recognise you when you navigate to another page or make another API request?
That's where sessions, cookies, and tokens enter the picture.
Next in the series: How Backend Authentication Evolved - From Passwords to Sessions and JWTs.
Top comments (0)