What are the signs that an authentication design is doing too much work that belongs in authorization?

When authentication starts making access decisions it cannot fully prove

Authentication should establish who or what is presenting a credential, then hand off to authorization for the question of whether that actor may do a specific thing. A healthy design keeps those responsibilities separate. When token contents are being treated as the final access decision, the system is usually carrying authorization logic inside the sign-in layer instead of in a policy layer that can evaluate the target resource and action.

A useful way to spot the drift is to ask whether the design can still answer, “may this subject perform this action on this resource right now?” without relying on claims that were minted earlier and may already be stale. If the answer is no, authentication is doing policy work it was not meant to do.

Why token bloat is usually a design smell

Token bloat is not just an efficiency problem. It often means the application is stuffing roles, entitlements, tenant flags, resource lists, or other downstream decision inputs into the authentication artifact so later code can avoid checking an authorization service or resource policy. That creates a brittle coupling between sign-in time and access time, and it makes permissions harder to change without reissuing or invalidating tokens.

There is also a practical limit to how much access context belongs in a token. The more claims you add, the more likely you are to expose unnecessary information, increase replay value, or create inconsistent behavior across services that interpret the token differently. If a claim is needed only after the request has been scoped to a specific operation, it probably belongs in authorization rather than authentication.

For teams comparing policy models, a clean split is easier to maintain when the authorization layer is expressed explicitly, as in Authorisation Models Guide. If the answer to “can I do this?” depends on resource attributes, relationships, or action context, that logic should not be embedded in a generic login token.

What a better boundary looks like in practice

A better design lets authentication produce a trustworthy subject assertion and then lets authorization evaluate the request against the current resource, action, and policy. In practice, that means short-lived credentials or assertions, a minimal token surface, and an explicit policy decision at the point of access. The request should be evaluated with the smallest amount of identity material needed to locate the subject, not with every permission the subject might ever need.

This is especially important when the subject can change state after sign-in. A user may lose a role, a service account may be rotated, or an agent may have its permissions narrowed while a token is still valid. If access decisions are embedded in the token alone, the system cannot easily reflect those changes until expiry or reissuance. Teams building agent-facing systems should also keep delegated authority separate from sign-in artifacts; AI Agent Authorisation Guide is a good reference for task-scoped and per-action authorization patterns.

When the boundary is healthy, authorization can be changed without redesigning the authentication flow. That separation lowers blast radius, makes policy review easier, and reduces the temptation to turn tokens into miniature databases of permissions.

Risk and Threat Considerations

When authentication is overloaded with access logic, stale claims, over-shared claims, and token reuse become more dangerous because a compromise yields both identity proof and implied authority. The weakness is not only technical complexity, it is the possibility that a stolen or over-privileged token can authorize more than the issuer intended for longer than intended.

Failure mechanism: The application trusts claims that were valid when the token was issued, but it does not re-evaluate the request against the resource, action, or current policy state. That can turn a replayed token, an oversized claim set, or a mis-scoped session into broad unauthorized access.

Impact: Attackers get a larger and longer-lived window to abuse access, while defenders lose the ability to revoke, narrow, or challenge permissions cleanly. Operationally, it also makes permission changes risky because teams must coordinate token expiry, reissuance, and policy updates across multiple services.

Practitioner Guidance

What to verify: Check whether the system can authorize the same request correctly if you strip the token down to identity proof only. If access still depends on embedded roles, resource lists, or entitlements in the token, the design is probably carrying authorization work in the wrong place.

Common mistake: Treating a rich token as a shortcut for policy evaluation because it seems faster or easier to implement. That pattern often looks efficient early on, but it becomes painful when permissions change, tokens are replayed, or multiple services need different access rules.

Practitioner takeaway: Keep authentication responsible for asserting identity, and keep authorization responsible for deciding access in context. If a token has become the place where policy lives, the design is already too tightly coupled.

Related resources from NHI Mgmt Group

• What are the signs that a remote office authentication design is becoming too brittle to support hybrid work?
• What are the signs that biometric authentication is creating too much friction for users?
• What are the signs that authentication and authorization are too tightly coupled in a backend?
• What are the signs that legacy authentication is creating too much risk in retail and hospitality?