"Are you logged in?" and "are you allowed to do this?" are two completely different questions, and confusing them is how security holes are born. A shocking number of apps nail the first and wave through the second — they check who you are at the door and then trust you everywhere inside. Building DineGuru as a multi-role platform forced me to keep those two questions rigorously separate.
Authentication is the door; authorization is every room
Authentication answers who are you — it happens once, at login, and hands you a proven identity. Authorization answers what may you touch — and it has to be asked again on every single action, because identity alone tells you nothing about permission.
A restaurant platform makes the gap obvious. A customer, a kitchen staffer, a manager, and an owner are all legitimately "logged in." But a customer must never edit the menu, a staffer must never see the revenue dashboard, and a manager at one outlet must never touch another's data. Knowing they're authenticated is useless here — the whole game is what each role is permitted to do.
Enforce roles at the boundary, on every request
The failure mode is checking permissions in the UI — hiding a button the user isn't allowed to press — and calling it done. Hiding a button is a courtesy, not a control; the API behind it is still there for anyone who sends the request directly. Real authorization lives on the server, at the boundary, and it runs whether or not the UI ever showed the option.
- Roles carry permissions, not just labels. A role isn't a title on a profile; it's a concrete set of allowed operations the backend checks before it does anything.
- Deny by default. Every protected action starts from "no," and access is granted only when the caller's role explicitly permits it — so forgetting to add a check fails closed, not open.
- Never trust the client's claim. The front end can request anything; the server decides. Authorization that can be bypassed by crafting a raw request isn't authorization at all.
The takeaway
Login is the easy, visible half of access control. The hard, invisible half is the permission check that has to fire correctly on every request, for every role, forever — and it's invisible precisely because when it works, nothing happens. Treating authentication and authorization as one problem is how "logged in" quietly becomes "allowed to do anything."
DineGuru taught me to design the permission model as deliberately as the data model. The full multi-role architecture is on the project page.
👉 See it: www.divyakush.com/projects/dineguru
Divyakush Punjabi — Full-Stack & AI Systems Engineer
🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub
Top comments (0)