A staggering share of real API incidents trace back to a single conflated sentence in an engineer's head: "this endpoint requires login, so it's protected." That sentence answers exactly one question — is the caller who they claim to be — and says nothing at all about a second, entirely separate question: is this specific caller allowed to do this specific thing to this specific resource. An endpoint can pass the first check flawlessly and fail the second one completely, and from an attacker's perspective wielding a perfectly valid, perfectly authenticated account of their own, that failure is just as exploitable as no login requirement at all.
This lesson draws that line precisely, because every later lesson on object-level and function-level authorization in this course assumes the reader already holds this distinction cleanly. Authentication answers "who is this." Authorization answers "what may this identity do, to this resource, right now." They are implemented differently, they typically fail differently, and treating a passed authentication check as evidence that authorization was also handled is the single most common design mistake this course will return to.
Neither concept is exotic. What is genuinely easy to get wrong is where in the request pipeline each check belongs, and what happens — silently, and often for months — when one of them is missing while the other looks entirely fine in every manual test an engineer happens to run.
Analogy🏏Cricket
🏏 Think of it like cricket: A player walking through a stadium's players' entrance presents accreditation that confirms exactly one fact — this is a genuine, registered member of a touring squad, not an impostor. That accreditation, on its own, says nothing about whether this specific player is entitled to walk into the home team's dressing room, review the home side's confidential scouting reports, or sit in on the opposition's strategy meeting. A steward who only checks that the accreditation is genuine, and waves the player through every door in the building on that basis alone, has confirmed identity while granting an entirely unrelated and unearned level of access. Grounds hosting international fixtures draw this distinction explicitly: one checkpoint confirms who you are, a completely separate checkpoint, checking a different credential against a different door, confirms which specific rooms that identity is actually permitted to enter. Just as confirming a player's accreditation is genuine says nothing about which rooms they may enter, confirming a user's login is genuine says nothing about which resources that user may act on. Just as a steward who conflates the two ends up granting building-wide access to anyone with valid accreditation, an API that conflates the two ends up granting access to any authenticated user's data to any other authenticated user simply because both happened to log in successfully. The insight is that identity and permission are answers to two different questions, checked by two different mechanisms, and a system that only asks the first question has not actually asked the second one at all — it has just assumed the answer.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.