Authentication and authorization

Objectives

By the end of the lesson, you can separate authentication (who are you?) from authorization (what may you do?), you can tell the 401 and 403 responses apart, and you understand why hiding a button is not an authorization check.

Why two separate questions?

Recognizing the logged-in user and permitting an operation are two separate questions. If a service mixes them up, two typical errors follow: either it lets in everyone who has logged in ("they are logged in, so surely authorized"), or it rejects even the authorized user. Authentication answers whose identity the service accepts. Authorization answers what this actor may do with a given resource.

A student and an instructor in the same system

The student can view the courses and enrol. The instructor can modify the description of their own course. Both authenticate successfully, but they are authorized for different operations. Not even the instructor can modify every course: the concrete resource and the relationship matter too.

flowchart LR
    K[Request] --> H[Authentication: who?]
    H --> J[Authorization: may they?]
    J --> V[Execution or rejection]

The diagram separates two logical checks. The order can be more complex in the implementation, but the decision questions differ.

Authentication: whose request do we believe?

Authentication means that the service accepts a claim about an identity according to the chosen method. The user can prove themselves in several ways: with a password, with an external identity provider (7.5, 7.6), with an additional factor (8.4). After successful authentication the service creates a session (7.2), so that the proof need not be given again for later requests. Authentication does not mean that the service infallibly knows everything about the person; it means that it accepts the identity according to a defined method.

At the HTTP level the signal of authentication is the 401 status code, and the client sends the proof in the Authorization header. According to MDN, a 401 response must contain a WWW-Authenticate header, which tells with what method authentication can be done (for example Basic or Bearer). The Basic scheme encodes the user name and the password with base64 only, which is not encryption, so it may be used only over HTTPS.

Authorization: what may the given actor do?

Authorization is a decision about whether the known actor may carry out an operation on a resource. The basis of the decision can be of several kinds:

• by role (student, instructor, administrator);
• by a condition tied to the resource (the instructor can edit their own course, the student can see their own enrolments);
• by context (a deadline, the state of the course).

The actor, the operation, the resource, and the context count together. Tried on the trial server, where the student can read only their own enrolments and the instructor everyone's:

Anna (student) logged in:
  GET /jelentkezesek/anna  -> 200 ["webprog"]
  GET /jelentkezesek/bela  -> 403 {"hiba":"nem jogosult"}

Instructor logged in:
  GET /jelentkezesek/bela  -> 200 ["adatbazisok"]

Not logged in:
  GET /jelentkezesek/anna  -> 401 {"hiba":"nincs bejelentkezve"}

(The error texts mean "nem jogosult" = "not authorized", "nincs bejelentkezve" = "not logged in".)

Actor	Operation	Decision
Student	Reading the course list	Allowed
Student	Reading another student's enrolment	Rejected (403)
Instructor	Modifying the description of their own course	Allowed under conditions
Instructor	Modifying another instructor's course	Rejected
Anonymous visitor	Any personal data	Rejected (401)

The table is a teaching example, not the real policy of Kurzuspont. The point: even after a successful login, access must be examined for every relevant operation.

401 and 403

Situation	Status code	What does it mean?	What the client should do
No accepted identity	401 Unauthorized	Authentication missing or invalid	Log in (again)
Known user, but without the right	403 Forbidden	The server understands the request, but refuses it	A new login does not help
The existence must not be revealed either	404 Not Found	According to MDN the server can also send 404 to hide a resource from the unauthorized	–

Using 404 can be useful because 403 reveals that the resource exists. It is not advisable to explain the rejection with the same level of detail for every resource.

Access control in the layers

The authorization decision always happens close to the data, on the server. The browser, the CDN, and a cache cannot make an authorization decision in its place. If an intermediary served a personal page from a cache (4.4), the authorization check would be skipped: that is why personalized responses must be excluded from caching (chapter 10).

Worked example: who can see what in Kurzuspont?

Resource	Anonymous	Student	Instructor (own course)	Administrator
Course description	can read	can read	can read and modify	can modify
Own enrolments	–	can read, create	–	can read
Another student's enrolment	–	forbidden	can read on their own course	can read
Enrolment list for the course	–	–	can read	can read

Every cell is a server-side rule. If the check is missing at a single endpoint in the API, that endpoint makes all the prohibitions of the interface bypassable.

Common misconceptions

Statement	Clarification
"Whoever is logged in can do anything."	Authorization varies by operation and resource.
"Hiding a button forbids the API call."	The server must check the authorization separately.
"Authentication and authorization are the same."	The former answers about identity, the latter about permission for an operation.
"401 and 403 mean the same."	One is an authentication rejection, the other an authorization rejection.
"Basic authentication encrypts the password."	It only encodes it with base64; without HTTPS it is not protected.

In brief

• Authentication establishes who the requester is; authorization establishes what they may do.
• 401 signals the lack of authentication, 403 the lack of authorization.
• The authorization decision happens on the server, close to the resource; hiding the interface is not protection.
• Broken access control is one of the most important web vulnerabilities.

Review questions

1. How does authentication differ from authorization?
2. When is 401 and when is 403 the right response?
3. Why is a hidden button not enough to protect an operation?
4. Why can 404 also be an authorization response?

Learning resources

• HTTP authentication (MDN) — 401, 403, WWW-Authenticate, and Authorization.
• OWASP Top 10:2025 — the most important web risks, including broken access control.