Verify at the edge, not in the handler

Where you put the identity check decides how much of your system has to be trusted. Proving the caller before compute runs collapses the surface you have to reason about.

The usual shape is a gateway that forwards anything and a handler that decides, per route, whether the caller is allowed. It works. It also means every handler is a place the rule can be forgotten, and the answer to "is this endpoint protected?" is a code review rather than a property of the system.

Moving the check to the edge inverts that. The gateway proves identity before any compute is scheduled — a token that fails never reaches code, so a handler that forgets to check is not a vulnerability, because unauthenticated requests do not arrive.

What this buys you

• One place to audit. "Who can call this?" is answered by configuration, not by reading every resolver.
• Bad tokens cost nothing. Rejected requests never trigger a cold start or a database connection.
• The blast radius of a mistake shrinks. Forgetting a check inside the boundary is a bug; forgetting it at the boundary is a breach.

The part people skip

Edge verification proves who is calling. It does not prove what they may touch. Those are different questions, and collapsing them is how systems end up with an authenticated user reading another tenant's rows. Authorisation still belongs next to the data, close enough that no query path can bypass it.

Authentication at the edge, authorisation at the data. Two checks, two places, neither optional.