Authorization is the step that decides what an already-identified user is permitted to do: which buttons they can press, which pages they can open, which records they can change. It runs right after identity is confirmed, and it is where most real-world security policy actually lives.
A hotel makes the split obvious. Checking in proves who you are, that is authentication. The keycard you receive is authorization: it opens your room and the gym, but not the staff office or someone else’s door. Same guest, different doors, all decided by what your card is allowed to do. In software the “card” is a set of permissions attached to your account.
Most systems group these permissions into roles so they stay manageable, a pattern called RBAC. When you need to go finer, limiting someone to only their own customers or region, row-level security enforces that deep in the database. Authorization is also the heart of how access control works in practice.
The classic mistake is checking permissions only in the interface. If the “delete” button is hidden but the underlying request behind it is not guarded, a curious user can still call that request directly from their browser and the record is gone. So the rule must be enforced on the server, on every request, not just hidden in the screen. When one app acts on your behalf in another, like a tool posting to your calendar, OAuth handles that delegated permission without ever sharing your password.
At TopDevs we map out authorization rules before writing the first feature, so every user reaches exactly what they should and bumps into a polite “not allowed” everywhere else.
