SevyDevy

Module 7 · Keeping It Running and Safe · Lesson 31 of 35

Authentication vs authorization: who you are and what you may do

11 minFree System design course · Beginner to intermediateLesson 7.6By Saket Bhatnagar

Researched and drafted with AI, reviewed and edited by Saket Bhatnagar.

In short

  • Authentication vs authorization: authentication checks who is calling, and authorization checks what that caller is allowed to do. A login proves only the first.
  • Think of an office ID card. The gate checks the card is yours; each door checks whether it may open.
  • Check identity once at the API gateway and permission in every service. Give each caller only the access it needs, and keep keys out of code.
Soon

Video lesson · coming soon

Authentication vs authorization: door check, room check

Lala, your AI mentor, will walk you through this lesson in a short animated video. Until then, everything is here to read and try.

  1. 01 Refunds nobody asked for
  2. 02 An office ID card
  3. 03 One gate, a lock on every room
  4. 04 Flip the cards: 401 vs 403
  5. 05 Three roles and a locked key
  6. 06 Next: forty engineers, one codebase

“The traces show something else,” says Sandeep Patil at the Baner office. “A support account refunded bookings it should never touch.”

The same week, a concert organiser opens another organiser’s sales page by changing one number in the web address. Nobody stole a password. Everyone was properly logged in.

“Who let them?” asks Meera Kulkarni. “Did someone hack us? What do I tell the organiser?” Arjun Nair shrugs. “They were logged in, so the system worked. And the refund service is internal. It trusts the API gateway.”

Zoya Mirza draws a gate on the whiteboard, with rooms behind it. “What is each caller allowed to do?” Nobody answers. The login worked perfectly and no password was stolen. So what exactly failed?

Authentication vs authorization: what is the difference?

Authentication checks who is calling; authorization checks what that caller is allowed to do. You met authentication at the API gateway in lesson 10. Authorization is the second question.

When you log in, the app gets a login token, a pass sent with each request to prove who you are. The line to keep: check who is calling at the door, check what they may do at every room.

  • Door check: who are you? Once, at the API gateway, by checking the login token.
  • Room check: may you do this, to this booking? Inside every service, on every request.

A gate check, then a room check in every service

The API gateway checks who the caller is once and passes that identity on. Each service then checks what this caller may do.

Diagram connections:

  • Client to API gateway (Login token)
  • API gateway to Booking service (Identity passed)
  • API gateway to Refund service (Identity passed)
  • API gateway to Sales report service (Identity passed)
  • Client: A fan, an organiser or a support agent, with a login token.
  • API gateway: Gate check: who is calling? Checked once.
  • Booking service: Room check: may this fan book this seat?
  • Refund service: Room check: may this agent refund this booking?
  • Sales report service: Room check: does this organiser own this match?

What is the difference between 401 and 403?

401 means the request has no valid credentials, the proof of who is calling. 403 means the server understood the request and refuses it. Both are status codes from lesson 4.

401 and 403 at the office gate
CodeThe guard saysThe app should
401 UnauthorizedShow your cardAsk the user to log in again
403 ForbiddenYour card is real, but not for this floorSay “no access”; logging in again as the same user will not help

You have seen a 401 when an app asks you to log in again after a night left open. Your login token expired, so the server no longer knew you.

You have seen a 403 when a shared-document app says “You need permission to view this” after you log in. It knew you, and still said no.

No, and the code is 403. The server knows exactly who she is, so it is not a 401. She does not own that match, so the room stays shut.

What is least privilege?

Least privilege means giving each person and each service only the access its job needs, and nothing more. It starts with handing out access in bundles.

In the Gurugram tower, staff, visitor and housekeeping cards each open a different set of doors. Gurleen gets a staff card, and it opens what staff may open.

SeatJaldi’s three roles
RoleMayMay not
FanBook seats; view and cancel their own bookingsSee other people’s bookings or any sales
OrganiserCreate their own matches; see sales for their own matchesSee another organiser’s sales; refund bookings
SupportView a booking; refund it within a limit, only for a booking on their open support ticketSee organiser sales; change prices

A role says what kind of action is allowed. The room check also asks whose thing it is: this organiser, this match. A card that opens only the rooms you need, and does little harm if lost, is least privilege.

Services need this too. Internal callers can have bugs, and keys, the passwords programs use, can leak. So every service checks every caller, even SeatJaldi’s own.

Picture a master key taped to the office notice board. Anyone can copy it. That is a password pasted into code.

Code is copied to every laptop and to the team’s shared code store, the repository. Keep secrets in a secrets store instead, a locked service that hands each program its secrets at start-up.

Try it yourselfDoor check, room check, and the rules around themGuess the answer to each front, then flip the card to check.

Where should engineers check identity, permission and secrets?

Check identity once at the API gateway, check permission in every service, use TLS on every call, and keep secrets out of code.

  • Identity at the gate: the API gateway checks the login token and passes on the user id and roles in an HTTP header. Services trust that header only from the API gateway, which drops any such header a client sends. It proves who is calling, never what they may do.
  • Permission in the room: every request gets a role and ownership check. “It came from our network” is never a permission.
  • Ownership from the identity: the organiser id comes from the checked login, never the web address or request body.
  • TLS on every call, between services too, so tokens cannot be read on the way.
  • Least privilege for services: each service’s database user touches only its own tables.
  • Secrets: one key per service, read at start-up, never logged, changed regularly, and at once if it leaks or its holder leaves.

The HTTP standard adds details. Despite its name, “Unauthorized”, 401 is about authentication, and it must carry a WWW-Authenticate HTTP header naming at least one way to log in. After a 403, the client should not retry automatically with the same login. A server may answer 404 to hide that a forbidden page exists.

sql
-- 17 comes from the checked login, not the web address
SELECT b.booking_id, b.seat_code, b.amount
FROM bookings b
JOIN matches m ON m.match_id = b.match_id
WHERE b.match_id = 42
  AND m.organiser_id = 17;

What just happened? Rows come back only if organiser 17 owns match 42. Edit the address to match 43 and nothing comes back. The service still answers 403, not an empty page: it checks ownership first, and the filter is the safety net.

Try it yourself

  1. List the calls

    View booking BK-10478, view sales for match 42, and refund BK-10478. BK-10478 is a ₹299 seat for match 43, inside support’s refund limit.

  2. List the callers

    No login; the fan who owns BK-10478; organiser 17, owner of match 42; a support agent with an open ticket for BK-10478.

  3. Write the codes

    Using the roles table, write 200 (allowed), 401 or 403 for each caller and call.

  4. Check

    You are right with four 200s, three 401s and five 403s. The 200s: the fan views the booking, organiser 17 views the sales, support views and refunds.

Back to Sandeep’s traces. The authentication was fine; the authorization was missing. The refund room let any agent refund any booking, with no ticket to say it was theirs, and the sales room trusted the web address.

Zoya keeps the door check at the API gateway and adds a room check to every service. Fan, organiser and support become roles. The organiser id comes from the login, wrong calls get 403, and keys move to a secrets store.

“What do I tell the organiser?” Meera asks. “The truth,” says Zoya. “Nobody broke in. We left a room unlocked, and now it is locked.” Then a new worry: 40 engineers now change one codebase and block each other’s releases. Arjun has a fix in mind. Zoya is not sure.

Check yourself

Check yourself

A user with a valid login opens another organiser’s sales page. What should the server answer, and why?

Pick an answer to see why it is right or wrong.

Check yourself

The refund service trusts any call from the API gateway, so a support agent can refund any booking. What is missing?

Pick an answer to see why it is right or wrong.

Check yourself

Where should the refund service keep its payment gateway key?

Pick an answer to see why it is right or wrong.

Try it yourselfModule recap: keeping it running and safeEight quick scenarios from this module. Tap the best answer and read why.

Remember these three

  1. Check who is calling at the door, and what they may do at every room.
  2. 401 means prove who you are; 403 means you are known and still not allowed.
  3. Give each person and service the least access it needs, and keep secrets out of code.

Questions people ask

What is the difference between authentication and authorization?
Authentication checks who is calling, and authorization checks what that caller may do. A user can pass the first and fail the second, so a system needs both.
What is the difference between 401 and 403?
A 401 means the request has no valid credentials, so the caller must prove who they are. A 403 means the server understood the request and refuses it, usually because the known caller is not allowed.
What is least privilege?
Least privilege means each person and each service gets only the access its job needs, and nothing more. If one account or key is stolen, the damage stays small.
Where should permission checks live in a system?
Check identity once at the API gateway, and check permission inside every service, on every request. Never treat a call as allowed because it came from your own network.