Why does an API gateway need a separate authorization service?

An API gateway needs a separate authorization service because a gateway can confirm who is calling and which route they may reach, but not whether that caller may act on a specific record. That second decision depends on data behind the API, such as the resource owner or the state of the record. Externalized authorization moves the decision to a policy decision point that every gateway and service calls, so the rule has one definition.

Does Cerbos support the AuthZEN Authorization API?

Cerbos supports the AuthZEN Authorization API and implements it for single and batch evaluation. AuthZEN is the OpenID standard for asking an authorization question, so any enforcement point that speaks it can request a decision from Cerbos without being written against a vendor API. That also means a gateway can be replaced without rewriting the policies behind it.

What does Cerbos Synapse do for API gateway authorization?

Cerbos Synapse is the data layer of the Cerbos authorization platform, and it assembles the context an authorization decision needs at the moment the decision is made. It fetches identity, resource and relationship data from identity providers, databases and APIs, so a gateway holding only a token and some claims can still ask a question that depends on a user's department or a resource owner. Synapse also speaks the native protocols of gateways and proxies including Kong and Envoy.

Cerbos Included in the KuppingerCole Leadership Compass on API Security and Management

Cerbos is included as a vendor in the KuppingerCole Leadership Compass on API Security and Management, published in July 2025.

Cerbos is an authorization platform, not a gateway, and the API edge is usually where a team first notices it has two different answers to the same access question.

A gateway knows who is calling, not what they are allowed to do

API gateways are good at authentication, rate limiting and routing. Given a token, a gateway can tell you the request came from a valid user and belongs on this route. What it cannot tell you is whether that user is allowed to act on this specific record, because that depends on the data behind the API, not on the request.

So the check gets split. The gateway allows the route, and the service behind it decides whether the caller can touch the object. Both halves are real authorization, written by different teams, in different languages, with no shared definition of the rule. That is how two services end up disagreeing about who owns a resource, and why externalizing the decision is easier than reconciling them later.

One decision point, enforced wherever the request arrives

The pattern that holds up is a single policy decision point that both the gateway and the services call. The gateway stays an enforcement point, and the rule lives in policy that is reviewed and tested outside any one service. Cerbos implements the AuthZEN Authorization API for single and batch evaluation. That is the open standard for asking an authorization question, so an enforcement point that speaks it can get a decision without being written against our API, and a gateway can be swapped without rewriting the rules.

In practice the gateway rarely has everything the policy needs. A token carries a user ID and some claims, while the rule depends on the user's department, the resource owner or the state of the record. Cerbos Synapse, the data layer of the platform, fetches that context at decision time from your identity provider, databases and APIs, so the gateway can ask a question it has no data to answer by itself. Synapse also speaks the native protocols of the gateways and proxies teams already run, including Kong and Envoy, so there is no glue code to keep alive at the edge.

One decision point is also one place to produce evidence from. Every call writes an audit record naming the principal, the action, the resource and the policy that was applied, rather than a gateway log that proves a request was routed and a service log that proves something happened afterwards.

The number of places one rule lives is the argument for moving it out

If your API surface grew service by service, pick one rule and count where it is implemented. Teams running microservices usually find more copies than they expected, and the copies have quietly diverged.

Try Cerbos to see how one set of policies covers your gateway and the services behind it, or book a call to talk through your API architecture with our team.

Cerbos is included as a vendor in the KuppingerCole Leadership Compass on API Security and Management (Alexei Balaganski, July 2025). Source, KuppingerCole Analysts.