Falsehoods Programmers Believe About Authorization

If you ask any programmer who implemented authorization, they will tell you:

Authorization is a deceptively difficult problem to solve.

Modeling your policy, keeping the permissions synced across multiple services, picking the right point in the stack for enforcement, error handling, testing the edges, creating an interface other teams of engineers want to use are just a few of the challenges that must be solved with an effective authorization system.

After even a few cycles exploring the problem, authorization shifts from another enterprise yak-shave to a genuinely intimidating technical challenge. It means solving a combination graph / sync problem that gets trickier with every requirement collected. Then that solution must satisfy all the availability and performance requirements that any call on the critical path of every application request demands. On top of all that, authorization carries all the elevated stakes with the fundamental security of your data and your customers.

If you get it right, you check an entirely undifferentiated box from the needs of the new enterprise customers you aim to serve.

If you get it wrong, your product is slow, your customers’ experience is frustrating and your data is vulnerable.

Over the past few weeks, I asked some of the smartest folks I know who implement authorization (authz) systems about the common misconceptions they once held that evaporated once they started turning stories into code.

Unsurprisingly, they shared many.

1. Authz is just an if statement.
2. Authz is just a WHERE clause.
3. Authz is just a view.
4. I can build this in a weekend.
5. I can build this in a week.
6. I can build this in a quarter.
7. I can build this myself.
8. Users only belong to one team.
9. Users only belong to one organization.
10. Users have only one job.
11. Users have only one manager.
12. Users only act on their own behalf.
13. If I know who the user is, I know what they should be able to do.
14. All we need is roles (Role Based Access Control).
15. All we need is relationships (Relationship Based Access Control).
16. All we need is entitlements (Attribute Based Access Control).
17. We must choose either RBAC, ReBAC or ABAC.
18. Our authz needs are unique.
19. We should implement authz at the API gateway.
20. We should implement authz in our authentication layer.
21. We should implement authz in the ORM.
22. We should implement authz in only one layer.
23. We don’t need list filtering.
24. We don’t change permissions that often.
25. We don’t add roles that often.
26. We don’t add users that often.
27. Postgres already has Row Level Security - that should be enough.
28. We can just display: none; on the front end - that should be enough.
29. We can just use JSON Web Tokens - that should be enough.
30. Authorization is just feature flags.
31. The app will never need a recursive authz check
32. The user will never inherit permissions from another user.
33. The authz model for the application will be the same as our infrastructure.
34. The rules and the data are the same thing.
35. The app logic and the authz logic are the same thing.
36. The app version and the policy version are the same thing.
37. We must hardcode the authz rules for performance.
38. We must cache the authz data for performance.
39. We must check authz less frequently for performance.
40. All authz tools are the same.

In the universe of technical challenges a programmer is likely to encounter over a career, there are few that get as hairy as fast as authorization. These were just a few of the falsehoods programmers we’ve encountered - what were some of yours?

Share some with us over in our community Slack channel.

Finding your journey into authorization tricky and would like some coaching? Sign up for 30 minutes with one of our engineers - we’d be happy to pair on your problem and share what we’ve learned.