Authentication vs Authorization

The problem

A lot of systems think like this:

if the user logged in, everything is fine now

It is not.

Login does not answer everything.

It answers only one question:

• who this person probably is

The system still needs to answer another:

• can this person perform this action on this resource right now?

Mental model

Think about it like this:

• authentication proves identity
• authorization decides access

Those are different questions:

• who are you?
• what can you do?

When those questions collapse into one idea in the team’s head, the usual failures show up:

• a logged-in user accessing something they should not
• access rules hidden only in the UI
• an overly broad role acting as if it solved every case

Breaking it down

First the system proves identity

Password, magic link, session, token, or SSO exist for that:

• connecting a request to an identity

Without a trustworthy identity, there is no real permission decision to make yet.

Then the backend decides access

Now the question changes from “who are you?” to:

• can you edit this order?
• can you view this report?
• can you delete this user?

Notice the detail:

authorization usually depends on:

• the action
• the resource
• the context

not only on some generic role.

The UI helps, but it does not decide

Hiding a button, disabling a menu item, and shaping the screen are good UX decisions.

But the real decision still belongs to the backend.

If the rule exists only in the frontend, it does not really exist yet.

Permissions without context are usually too shallow

isAdmin === true solves some cases.

But many real systems need something more specific:

• owner of the resource
• correct tenant or team
• state of the object
• scope of the token

Mature authorization is often about the concrete resource, not just about the kind of user.

Simple example

Imagine a dashboard that hides the “Delete User” button from non-admins.

In the interface, everything looks fine.

But if the backend accepts:

DELETE /users/123

without checking the real permission, any authenticated user can still try the request with curl, a script, or DevTools.

The problem is not that the button is hidden.

The problem is treating a visual rule like real access control.

Common mistakes

• assuming that logged in means authorized
• trusting the UI to block a sensitive operation
• using a very broad role without looking at the resource and the context
• forgetting that every critical action still needs a backend check
• talking about authentication and authorization as if they were interchangeable

How a senior thinks

More experienced engineers separate these things early:

• identity
• session
• permission

The reasoning usually sounds like this:

First I know who made the request. Then I decide whether that identity can act on this specific resource. If the answer depends only on the frontend, the architecture is still weak.

That separation improves:

• security
• API design
• interview explanations
• rule maintenance

What the interviewer wants to see

In interviews, this topic reveals conceptual clarity very quickly.

The interviewer wants to see whether you:

• separate identity from access
• understand authorization as a contextual decision
• do not outsource security to the frontend
• can explain the distinction without empty jargon

A strong answer often sounds like this:

Authentication tells me who is making the request. Authorization decides whether that identity can perform that action on that resource. I can hide the action in the UI for UX, but the real decision still belongs to the backend.

Login proves identity. Permission proves a limit.

An authenticated user without authorization is still not allowed to perform the action.