Sarah from Sales just logged in. She's authenticated. That part worked.
Now she clicks 'Approve' on her own $15,000 expense report.
The system accepts it. Nobody flagged it until month-end close.
Being logged in doesn't mean you can do anything.
FOUNDATIONAL - Every action in your system should check "is this user ALLOWED to do this?"
Authorization answers the question: 'Can THIS user do THIS action on THIS resource?' Authentication proved who they are. Authorization controls what they can do.
Without it, 'logged in' means 'full access.' The intern can delete the customer database. The sales rep can approve their own expenses. A contractor can see everyone's salary. Authorization prevents all of this.
Authentication and authorization are two different things. Confusing them is how security breaches happen.
Authorization solves a universal problem: how do you control what actions are allowed without hardcoding rules everywhere?
Check permissions at the point of action. User requests something. System checks policy. Policy returns allow/deny. Action proceeds or stops. This pattern applies whether you're protecting a button click or an API endpoint.
Try having Sarah approve her own expense. See what happens.
Assign users to roles, roles have permissions
Users get a role (Admin, Manager, Employee). Each role has a predefined set of permissions. Simple to understand and manage for most organizations.
Decisions based on user, resource, and context attributes
Policies reference attributes: "Allow if user.department == resource.department AND request.time is during business hours." More flexible but more complex.
Permissions based on relationships between entities
Access defined by relationships: "User can edit documents they own or that are shared with their team." Common in collaborative apps like Google Docs.
Your CFO discovers this during month-end close. Without authorization rules, anyone can do anything once they're logged in. This flow ensures the right people can only do what they're supposed to do - automatically enforced, not just policy.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
Hiding a button doesn't stop someone from calling the API directly. If 'Delete' is hidden but the /api/delete endpoint is unprotected, you have no security.
Instead: Always enforce authorization on the backend. UI hiding is convenience, not security.
Your nightly sync job runs as 'admin' because it was easier. Now that account can do anything, and if it's compromised, everything is exposed.
Instead: Create service accounts with minimum required permissions. The sync job only needs read access to CRM and write access to one table.
"Sarah can view invoices" doesn't mean she should see EVERY invoice. Without scoping, she sees competitor deals, executive expenses, everything.
Instead: Scope permissions to resources: "Sarah can view invoices WHERE department = 'Sales' OR assigned_to = 'sarah'."
You've learned how permissions control what users can do. The natural next step is understanding how to track what they actually did.