← All anti-patterns
Architecture anti-pattern

Authorisation checked at the entrance

Published by ArchitectMentor

The gateway validates a token, while downstream layers assume that an authenticated user may access any referenced resource.

Fictional example. This does not describe a particular organisation or incident.

Situation

An API gateway validates the token and forwards a request to services. Teams assume the user is “already authorised”. The reporting service loads a resource by ID, the cache omits tenant identity, and an export worker trusts the tenant identifier in a message. Every component follows its local instruction, but the end-to-end path does not enforce one access boundary.

Warning signs

  • tests cover invalid and valid tokens but never ask whether a valid user can read another tenant's resource;
  • roles such as admin are not bound to a tenant or scope;
  • a cache hit, export or search path bypasses the check used for database queries;
  • tenant identity comes from a request parameter or message without being bound to trusted identity;
  • the security review ends at the gateway diagram.

Consequences

A correctly authenticated user may read or alter another tenant's data. The defect can be hard to see because logs show a valid token and a 200 response. A central gateway creates an impression of control but does not know the meaning of every report, file or job.

A better decision

  1. Define trusted tenant and operation context. Bind roles to scope and decide access for the particular resource.
  2. Enforce scope on every data path: writes, reads, caches, indexes, exports and messages. Add an independent data-layer barrier where risk warrants it.
  3. Deny by default. Missing or ambiguous context stops the operation; it does not select a “default tenant”.
  4. Test identifier collisions, role changes, delayed jobs and warm caches. Observe decisions without copying protected content into logs.
  5. Plan migration after changing the mechanism: invalidate old sessions and cache entries, inspect queued messages and establish the possible scope of prior exposure.

A central policy can reduce drift but must be available, versioned and understandable to services. Local checks may be simpler but need a shared contract and tests. In either design, “the gateway checked it” is not evidence.

Authentication opens the system door. It does not automatically provide a key to every room.