Teams deciding whether to buy an authorization service or keep the logic in the application.
Whether externalised authorization is worth the latency and the dependency for your workload.
The control gap
The case for externalising is strong and usually undersold: one place to change a rule, one audit trail, and permissions that stop being scattered through application code. The case against is also real and usually ignored until the first outage. An authorization service in the request path is a dependency with your uptime attached to it, and the answer to what happens when it is unreachable is very often nothing anyone has written down.
What good looks like
Authorization is centralised where that genuinely helps, with latency measured, outage behaviour defined per action class, and the availability trade made deliberately.
- Measure the added latency at your real call rate before committing, not at a demo rate.
- Define fail-closed and fail-open per action class. Reading a record and issuing a refund do not deserve the same answer during an outage.
- Cache only decisions whose inputs are stable, and make revocation faster than the cache lifetime.
- Keep the platform's own permissions in place, so an outage in the decision layer does not remove every boundary at once.
A production workflow
- Start with one action class and one enforcement point rather than a platform-wide rollout.
- Run in shadow mode and compare the service's decisions with current behaviour.
- Enforce for that class, with the outage path tested rather than assumed.
- Expand class by class, keeping the decision record complete at each step.
Evidence to require
- Decision latency at the enforcement point, at the percentile that matters.
- Decisions served from cache, with the cache age at the moment of use.
- Behaviour observed during a real dependency failure, per action class.
- The rule, version, and reason for every decision, exportable without vendor assistance.
Buyer checklist
- What happens to each action class when the service is unreachable, and has that been tested?
- How much latency is acceptable, and what does the service add at your rate?
- Can you export decisions and policies in a form another system could read?
- Which boundaries remain if the authorization layer is removed entirely?
Practical answers
Common implementation questions
Is buying always better than building?
No. Building is reasonable when the rules are few and stable and the team owning them is the team writing the code. It gets expensive at the point where rules multiply, reviewers arrive, and someone asks for an audit trail.
Does this have to be in the request path?
For enforcement, yes. A decision made after the action is monitoring. The design choice is where the decision point runs, not whether the decision precedes the effect.
What should we insist on before making it load-bearing?
A tested outage path, an export you can read without the vendor, and a decision record that includes the reason and the policy version. Those three make the dependency reversible.