Home / Knowledge hub / Authorization
Knowledge hub
Authorization
Deciding what a proven user is then allowed to do.
What it means
Authorisation decides what a proven user may then do. Authentication gets somebody through the front door. Authorisation keeps them out of the rooms marked private.
Your server has to check it on every request, against the specific thing being touched. Not 'is this person an administrator' in general, but 'may this person read this record, right now'.
Roles are a shorthand, not the answer. The record decides, not the job title.
Why it matters
This failure costs the most and gets tested the least. It needs no malware and no clever payload. One ordinary account, one changed identifier, and somebody else's data comes back in a normal response. Your monitoring sees nothing unusual, because nothing unusual happened.
The second cost is the time afterwards. When a check is missing, you rarely know how long it was missing or who used it. The question turns from what to fix into what to tell people.
Authorisation also scales badly. Every new role and every new feature adds cells to check, so an application that was correct at three roles is rarely correct at seven.
How it shows up
It breaks in places that look finished. An endpoint checks that you logged in but not whose record you asked for. A menu hides a page while the route behind it stays open. A role check guards the first step of a flow and not the second.
Two accounts are the minimum for an honest test. One login shows you that a page loads. Two show you whose data it loaded.
We built the company around this one. See how we test it.
Questions people ask
Authorization, answered
Where in our application should the authorisation check live?
In the code that does the work, on the server, as close to the data as you can put it. Not in the controller alone, and never in the interface.
The reason is second routes. A check at the door holds until somebody adds a bulk export, a scheduled job or a new API version that reaches the same function another way.
Can we put a user's roles in their login token and trust that?
You can carry them there, and you still have to decide what they mean on each request. A token states what was true when it was issued. It does not know that somebody left the company an hour ago.
Keep tokens short-lived if roles ride inside them, and check the specific record as well. A role in a token never answers whether this invoice belongs to this customer.
Two departments share a role. Can roles keep them apart?
Roles alone cannot. A role says what kind of work somebody does. It says nothing about which slice of the data they may do it on.
Add a scope to every check: this person, this role, this department, this record. Teams usually build the role half, ship it, and find the missing half when two customers turn up in one view.
What are the downsides of role based access control?
It grows. Every exception becomes a new role, and after a few years you hold dozens that nobody can explain. People then get the nearest role that works, which is almost always wider than they need.
It also hides gaps. A tidy list of roles looks like proof that access is under control, right up to the moment somebody tests one role against a record it should never reach.
When somebody is refused, should we send them to the login page?
Not if they are already logged in. Sending an authenticated person to a login page tells them the thing exists and leaves them confused. Answer plainly that they may not have it.
Keep the wording identical whether the record exists or not, so the response never confirms what is there. And check that the redirect is not the only thing stopping them, because the request behind it still reached your server.
Related
Terms that sit next to this one
Access control
The rules deciding which person can see or do which thing in your app.
Broken access control
An application failing to enforce its own rules about who may do what.
IDOR
Changing an id in a request and getting back someone else's record.
BOLA
An API returns a record just because you asked for it by number.
Privilege escalation
Gaining rights you were never given, sideways or upwards.
Does your app check who asks?
We built the company around this one. We map a role by resource matrix, test every cell, then hand back the request, the response and the source line. Ask about a 30 day pilot.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.