← 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.

Discuss this article

Share a constructive observation or an anonymised example. Comments are checked by AI before publication. Uncertain cases go to the moderator.

Discuss ideas, not people. Do not include confidential details or personal data. By submitting, you accept the data notice.