Should authorization be deployed as a library or as a separate service?

What changes when authorization is a library versus a separate service?

Authorization is not just a code placement choice. A library keeps policy evaluation inside each application process, which is simpler to call and easier to ship with the app, but it can create policy drift and inconsistent enforcement. A separate service centralises decisions, which improves consistency and auditability, but introduces network dependence, latency, and availability as part of the control path.

That trade-off matters most when the same rules must apply across multiple services, teams, or runtime environments. It also matters when the application must tolerate policy changes without redeploying every caller. For a practical externalised model, see the Authorisation Models Guide, which covers policy-based access control and externalised authorisation patterns.

Why the deployment model changes the control boundary

When authorization lives in a library, the application owns the decision logic, the runtime dependency, and often the policy cache. That makes local failure modes easier to reason about, but it also means every application must be kept in sync. The model is strongest when the app and the policy logic are tightly coupled, and weakest when many codebases must interpret the same rules independently.

A separate service turns authorization into a shared control plane. That is useful when you need one decision source for several applications, especially where you want policy updates, decision logging, and rule administration to be centralised. The trade-off is that the request path now depends on a live policy service, so the design must account for timeout behaviour, fail-open versus fail-closed handling, and what happens when the policy engine is degraded.

For teams comparing broader access-control patterns, the IAM and IGA Basics guide is useful because it distinguishes authentication from authorization and frames access governance as an operating discipline, not just a code technique. If role design is part of the choice, Role Mining and Role Design Guide helps explain why a stable role model often matters more than where the check is executed.

When a library is the better fit, and when a service wins

A library is usually the better fit when latency is extremely tight, when the policy logic is small and stable, or when the application has a narrow trust boundary and a single owning team. It also works well when the application needs to keep enforcing rules even if it is temporarily disconnected from a central system. In those cases, the main operational burden is versioning: every deployment must carry the correct policy code and the correct assumptions.

A separate service is usually the better fit when policy must be consistent across many applications, when multiple languages or platforms are involved, or when policy changes need to be governed centrally. It becomes especially valuable when access decisions need to be observable and reviewed as a shared capability. The operational cost is coordination, because the authorization service becomes infrastructure that must be scaled, monitored, and protected like any other critical dependency.

The most practical architecture is often hybrid: keep coarse-grained guardrails close to the application, then call out to a central service for the high-value or frequently changing decision. That pattern limits blast radius while preserving policy consistency where it matters most. The AI Agent Authorisation Guide is a good example of why per-action, externalised decisions are valuable when access must be tightly scoped and revocable.

Practitioner Guidance

What to prioritise: decide first whether consistency or locality is the stronger requirement. If policy disagreement across applications is the real risk, a shared service is usually the cleaner answer; if latency, resilience, or offline operation is dominant, a library is safer.

What to verify: prove that the chosen model can handle failure deterministically. For a service, test timeout, retry, and fallback behaviour under load; for a library, test that policy versions are rolled out reliably and that callers do not silently diverge.

Common mistake: treating a central authorization service as a shortcut to governance maturity. Centralisation only helps if the policy model, ownership, and operational controls are equally disciplined; otherwise you just move inconsistency into one more critical dependency.

Practitioner takeaway: choose the deployment model that best matches your control boundary, then make the failure mode explicit, because authorization architecture is only as strong as its weakest decision path.

Related resources from NHI Mgmt Group

• Why do Active Directory service accounts complicate zero trust programs?
• When does querying authorization data inside the database create less friction than calling a separate authorization service from application code?
• What is the difference between a separate authorization service and embedding permissions inside each microservice?
• How should security teams separate authentication from authorization in practice?