Lesson 5 of 6 · About 6 minutes
Logging in does not grant every permission
Learn the concept.
Authentication establishes a claimed identity. Authorization decides whether that identity can do this particular thing to this particular resource.
One identity. Two access decisions.
Lee is signed in. This fictional policy permits owners to read their own notes.
- Note 17Allow
Owner is Lee. Return the permitted content.
- Note 18Deny
Owner is Maya. Do not return her note content.
Read the visualLee changes /api/notes/17 to /api/notes/18, which belongs to Maya. What must the server do?
The example policy allows an owner to read their own private note. Lee’s session does not authorize access to Maya’s note.
Check the object as well as the role
A signed-in learner may read their own private note without being allowed to read another learner’s note. Changing a note ID in a request must not bypass that boundary.
Enforce the rule on every request
The server must check access even when the interface hides a button. Use the application’s approved policy, including resource ownership or other relationships, rather than trusting an ID or role supplied by the browser.
Test both sides of the boundary
A useful check demonstrates the intended access and a denied request outside it. An allowed read alone does not show that another person’s data stays private.
Put it in context
In the lab, Lee owns note 17 and Maya owns note 18. Both requests arrive with Lee’s valid session. The server returns Lee’s note but refuses the other one without including its contents.
Make a decision.
Explore the practice space, then answer the check-in below. A correct answer lets you save this lesson to your progress.
YOUR PRACTICE SPACE
Try the idea for yourself.
Enable JavaScript to explore this fictional exercise. The explanation and visual above remain available.
Take this with you.
A valid sign-in is only the start. Check permission for the specific action and resource.
Next lesson: Treat application input as untrusted