An API Gateway Is Not an Authorization System

“The gateway validates the token, so authorization is centralized.”

Hold on.

That is one promotion away from becoming a platform principle.

An API gateway is not an authorization system.

Your gateway can authenticate a request.

Validate a token.

Reject an oversized body with 413.

Throttle a caller with 429.

Route to the correct backend.

Apply a scope or ACL.

All useful.

None of it tells your gateway whether account A may see invoice B.

Whether that invoice is still in a state that can be refunded. Whether this approval would exceed the authority assigned to the caller.

Those are authorization decisions.

They depend on the object and the business operation. Not on the route that happened to carry them.

Your gateway sees an envelope.

Method, path, headers, claims, perhaps a body.

Your service owns the record state, your tenant relationship, the transaction rules.

A purpose-built authorization service can evaluate that context when it sits outside your service. Your directory owns the lifecycle that decides which claims exist at all.

Putting the first control in one place doesn’t centralize every later decision.

A hotel receptionist checking a key card doesn’t know whether the person carrying it may approve a wire transfer.

This should not be controversial.

Yet add an OAuth token and suddenly the lobby is apparently the finance department.

1. “But It Can Enforce Scopes.”

Yes.

A scope can be a proper function-level grant: this caller may use this route family, or this operation.

That is useful, because function-level authorization asks whether a role or scope may invoke an HTTP method plus route, an RPC operation, or a GraphQL operation at all.

A DELETE only an administrator may call should fail before it reaches your backend.

But your pipeline has a separate object-level checkpoint for a reason.

Object-level authorization asks whether the specific object.

Named by a path parameter, query string, header or body field. Belongs to, or is otherwise reachable by, the authenticated caller.

Your endpoint serves a different object on every request.

A prior scope check can’t turn every possible identifier into the caller’s record.

That failure returns 403.

Or sometimes 404, when you deliberately avoid confirming the object exists.

The status code isn’t the important part.

The timing is.

Your service, or your policy decision point, has to decide access to this object before business logic treats it as available.

Function-level and object-level authorization don’t even have one canonical order.

Some deployments reject a disallowed operation first, because it is cheap and independent of data.

Others test object access first, because there is no purpose in checking an operation against an already-forbidden target.

Both are defensible.

Omitting either isn’t.

A scope answers whether the caller may approach the door. It does not decide what is in every room.

2. “But It Has an ACL Plugin.”

An ACL plugin is the same useful, narrower control stated in product language.

It can decide whether an authenticated consumer or configured group may use a route.

That belongs at the edge, and it beats letting every authenticated identity call every administrative operation.

Kong documents authentication, ACL or authorization, request validation and rate-limiting plugins in a single access phase.

Their relative order comes from a per-plugin priority, not from separate phase boundaries.

That is an implementation detail with architectural consequences.

A neat row of gateway plugins is one request-processing pipeline. It is not five independent judgments that acquire business knowledge by standing next to each other.

The ACL gives you the function-level answer.

It can say a billing operator may call POST /refunds. It can say a reporting consumer may call an export route.

It doesn’t know whether the requested refund belongs to the caller’s business unit.

Whether the invoice was already settled.

Whether a transaction rule permits the action now.

Those facts aren’t a configuration label attached to a route.

Somebody still has to evaluate subject, object, operation and context.

NIST SP 800-162 calls that attribute-based access control.

Authorization derives from attributes of the subject, the object, the requested operation, and sometimes your environment.

A route ACL can be an input, or a coarse boundary, within that design.

Call it the whole design and billing-operator becomes a master key with nicer YAML.

3. “But Every Route Has an Authenticated Consumer.”

Good.

Authentication has to run first.

No object-level, function-level or schema check can meaningfully evaluate permissions for an unknown caller.

What authentication hands forward is a set of claims.

User ID.

Roles.

Scopes.

Not a green light.

The consumer identity is also a valuable rate-limit key.

Kong’s rate-limiting plugin defaults to an authenticated Consumer where a route has authentication configured.

It falls back to client IP from X-Real-IP or X-Forwarded-For only when no authentication layer exists.

That distinction protects different things.

An IP-based limit is what your unauthenticated password-reset path can use.

A consumer-keyed limit can contain one abusive credential without throttling every caller behind the same corporate NAT.

Neither kind of counting answers whether consumer C may read object O.

It counts how often the consumer asks.

A rate limit is a resource-protection control.

Authentication is an identity-establishment control.

Object policy is an entitlement decision.

That all three can run at a gateway does not fuse them into one control.

Any more than putting a smoke detector, a door lock and a coffee machine in the same hallway creates a fire department.

The wider limit still matters.

AWS API Gateway documents a default account-level throttle of 10,000 requests per second per Region and a 5,000-request burst bucket, with lower defaults of 2,500 RPS and a 1,250-request burst in named newer Regions.

Those are dated, vendor-specific defaults.

Not recommended authorization settings.

They demonstrate the point.

Your edge can cap throughput very precisely while remaining unable to decide the business meaning of one authorized-looking request.

4. “But the Role Comes From the Corporate Directory.”

Then your directory is an input to authorization.

It isn’t the authorization system because your gateway can read a role claim.

RBAC assigns permissions to roles, and identities to one or more roles. Unified by NIST in 2000, adopted as ANSI/INCITS 359 in 2004, revised in 2012.

Its practical value is clear.

A baseline Finance role is easier to administer than dozens of individual grants.

Its failure mode is equally clear.

A role defined too broadly enforces excessive access faithfully.

Most enterprises layer RBAC for coarse baseline access with ABAC or a policy layer for fine-grained decisions.

“Finance” might establish eligibility to approach an accounts endpoint.

The decision to view a record can still depend on that record’s tenant, classification, workflow state, requested operation, or managed-device condition.

Your gateway does not infer that relationship because a token has a group claim in it.

A name badge doesn’t come with a map of every filing cabinet.

The role is also only as current as IAM makes it.

A joiner receives birthright access after a verified HR trigger, plus a request path for anything beyond baseline.

Research puts the average at 6 days for a new hire to receive full productive application access, because many entitlements still wait on manual approval.

That is your entitlement system, not gateway latency.

And it determines which claims exist when the first request arrives.

5. “But Putting Checks in Services Duplicates Policy.”

Duplicating enforcement isn’t duplicating policy.

Your gateway and your service see different facts.

Each should enforce the part it can actually decide.

Your gateway can validate issuer and audience, reject a request over a configured size, apply a route scope or ACL, and enforce a coarse per-IP or per-consumer rate.

OWASP’s REST Security Cheat Sheet says to define an appropriate request size limit and reject excess with 413.

Schema validation can require types, required fields, declared ranges and a strict field allowlist. In JSON Schema, additionalProperties: false means fields not explicitly named are not allowed.

That stops a stray property reaching your binding logic.

It does not decide whether the amount is permissible for this account.

Whether this workflow may transition today.

Whether the caller’s role applies to this tenant.

Your service knows its aggregate state.

It is where an object-level check has your data to be real rather than decorative.

A shared authorization service is appropriate when many services need the same resource and transaction policy.

That doesn’t mean every team should scatter ad hoc role comparisons through handlers.

It means a canonical policy model and entitlement source get evaluated at the layer that can see subject, object, action and context.

Your gateway can pass verified claims.

Your service, or the policy service, turns them into a decision.

And no.

Calling the second check “duplicate” does not make the missing object state materialize in your gateway.

Writing GET /accounts/123 in a route rule does not cause your gateway to discover who owns account 123.

Configuration is powerful.

Telepathy remains in preview.

6. “But a Policy Service Is Another Dependency.”

Correct.

So is your gateway.

So is the directory.

So is your database holding the object whose access you are deciding.

An architecture should name its dependencies and design their availability, change control and failure handling.

Pretending a route ACL eliminates your policy dependency doesn’t remove it.

It replaces it with an unexamined broad grant.

Which is also why gateway order deserves care.

A cheap structural check can run before authentication, rejecting malformed JSON or an obvious size violation without spending identity or database work.

The fuller schema-aware check still follows authorization, because a valid payload can depend on the caller’s role and allowed operation.

That is a performance optimization.

It is not an argument that your edge knows the transaction.

The same discipline applies to rate limits.

Cloudflare documents plan-tier windows from 10 seconds on Free through 60 on Pro and 600 on Business, up to 65,535 seconds on Enterprise.

Kong can set separate second, minute, hour, day, month and year windows.

Those controls change abuse resistance and backend cost.

They do not make an allowed request entitled to perform an action.

So an explicit policy service is a deliberate dependency when policy needs facts outside your request envelope.

It needs tests, availability design, a clear failure model and an audited administration path.

Your gateway is a deliberate dependency too.

The answer is not to declare either one a replacement for the other because it makes the diagram tidier.

7. No, This Does Not Mean Gateways Should Enforce Nothing.

Of course your gateway should enforce coarse access policy.

Reject an invalid issuer or audience.

Require an authenticated consumer where the route needs one.

Apply route scope or ACL rules.

Set size ceilings and structural validation.

Use an edge IP limit before authentication and a consumer-keyed limit after it.

Those are exactly the controls that save your service from traffic it should never have to interpret.

The five checkpoints are not a menu.

Authentication, object-level authorization, function-level authorization, schema validation and a rate-limit gate all have work to do. Your gateway may implement several, or all, of them.

The point is that a route-level decision cannot replace your data and business context held by your service, or by a purpose-built authorization service.

Nor does centralizing policy definition require centralizing every byte of enforcement in one appliance.

Define permissions as resource-and-action pairs.

Keep a canonical entitlement source.

Map directory groups to bounded roles.

Use ABAC-style policy where a decision needs subject, object, operation and environment.

Then place enforcement where the relevant facts exist.

That isn’t surrendering centralization.

It is centralizing your policy without pretending every enforcement point has the same eyes.

8. What You Should Actually Do

At the gateway, validate only what the gateway can verify. Issuer and audience.

Authenticated consumer.

Route scope or ACL.

Request rate.

Body size.

Structural shape.

Make the order explicit, in Kong, check the configured plugin priorities, because all of those plugins share the access phase.

A gateway with the right plugins in the wrong effective order isn’t a pipeline.

It is a raffle with HTTP headers.

At the authorization layer, define which subjects may perform which operations on which objects, in which context. Keep function-level and object-level checks distinct.

A scope may permit GET /invoices; the object rule still decides whether this caller may read this tenant’s invoice.

A role may permit an approval operation; the business rule still decides whether that transaction is in an approvable state.

Make IAM part of the access path, not a separate annual PowerPoint ritual.

Provision birthright access from the HR trigger.

For movers, grant the new role and revoke the old one. For leavers, disable the IdP account and explicitly revoke non-federated access.

Microsoft Entra access reviews support weekly, monthly, quarterly and annual recurrence, and its inactive-user recommendation appears after 30 days without a tenant sign-in.

That is review evidence.

Not proof an entitlement remains justified.

Audit the administrative changes that alter the path. Routes.

Plugin priorities.

ACL memberships.

Scope mappings.

Schemas.

Rate policies.

Directory-to-role mappings.

Authorization policies.

The beta host in OWASP API9:2023 is the unglamorous warning. beta.api.socialnetwork.owasp.org lacked the rate limit its production sibling enforced.

A correct checkpoint deployed inconsistently is still a gap.

9. The Model Is Not Complicated.

Your gateway decides what it can see at the request envelope.

Whether a verified claim may use a route.

Whether the request has an acceptable shape and size.

Whether it arrives too often.

Your IAM decides how identities acquire, retain, review, elevate and lose the entitlements that become those claims.

RBAC supplies coarse grants.

ABAC or a policy layer evaluates object, operation and context.

Your service enforces the decision where the resource state and transaction rules actually exist.

API security supplies the ordered checkpoints. IAM supplies the identities and entitlements those checkpoints consume. Authorization supplies the decision about this action on this object.

Use your gateway.

Use the directory.

Use lifecycle controls.

Use a policy service where the system needs one.

Then ask the question that usually clears the room.

What fact makes this caller entitled to this object right now?

If the only answer is “your gateway saw a valid token,” you have authenticated a request and wandered away before authorization began.