Skip to content

Authentication Broker

Identity and authorization service — instantiates Request–Response Capability Provisioning

Sits between clients and the capability, verifies who is asking, and issues a scoped, short-lived credential that grants exactly the access the request needs — and no more.

Before a client may draw on a shared capability, something has to decide whether this caller is allowed this action, right now. Authentication Broker is that gatekeeper: it verifies the requester's identity, evaluates the request against an access policy, and — this is its defining move — mints a scoped, expiring capability (a token) granted in response to the specific request rather than handing out standing access. The grant unlocks only what the request needs and then evaporates, so there is no durable privilege lying around to be misused or forgotten. It is the mechanism that turns "give this team access to the database" into "give this caller a one-hour, read-only key to this one dataset."

Example

A data analyst needs to run a query against a cloud warehouse. Instead of holding a permanent warehouse login, she asks the broker for access. The broker authenticates her against the company identity provider, checks policy — analysts in her group may read the sales schema for reporting — and issues a token scoped to exactly that: read-only, sales schema, valid for one hour. The token itself carries the authorization, so the warehouse can honor it without keeping its own copy of who-may-do-what. When the hour ends the capability simply lapses; there is nothing to revoke, and had the token leaked, it would have unlocked only one schema for sixty minutes. Multiply that across hundreds of analysts and the difference between standing credentials and request-scoped grants is the whole security posture.

How it works

The broker resolves each request through a fixed spine, and what distinguishes it is where the grant lives:

  • Authenticate the principal — establish who is really asking, against a trusted identity source.
  • Evaluate access policy — decide, from the request's context (who, what resource, what action, when), whether to grant and at what scope.
  • Mint a scoped, time-boxed capability — issue a token that encodes the narrow permission, rather than writing a durable entry into an access list.
  • Let the token carry the authority — the capability provider trusts the token, so it need not hold shared state about every client's rights.

The distinctive property is least-privilege-by-construction: the default is no access, and each grant is the minimal, expiring answer to one request.

Tuning parameters

  • Token lifetime — minutes versus hours versus days. Shorter grants shrink the blast radius of a leak but add re-authentication traffic; match it to how sensitive the capability is.
  • Scope granularity — whole-service versus single-resource-and-action. Finer scope tightens least privilege but multiplies the policy surface to maintain.
  • Authentication strength / step-up — password, MFA, or continuous verification, possibly escalating for sensitive requests. Buys assurance at the cost of friction.
  • Delegation depth — whether a held capability may be re-delegated (and only ever attenuated, never widened). Enables multi-hop workflows but complicates reasoning about who holds what.
  • Revocation model — pure expiry versus an active revocation list. Active revocation is immediate but forces providers to consult live state, quietly reintroducing the shared dependency expiry avoids.

When it helps, and when it misleads

Its strength is that it replaces broad, standing, hard-to-audit access with narrow grants that are scoped to a request and expire on their own, and it concentrates the authorization decision in one place so every provider need not reinvent it. The failure modes are subtle. A broker that authenticates but under-scopes — verifying identity yet granting more than the request needs — recreates the over-privilege it was meant to end. And a broker that acts on ambient authority can be turned into a confused deputy[^confused]: tricked into using its own privilege on behalf of a caller who should not have it. The classic misuse is treating the broker as an identity checkpoint only — answering "are you who you say?" while skipping "should you get this?" The discipline is to scope every grant to the specific request and default to deny.

How it implements the components

Authentication Broker fills the identity-and-authorization subset of the archetype's machinery — the components that govern who may invoke the capability:

  • request_context_and_identity — it establishes and binds the verified identity and request context (who, from where, for what) that every downstream decision keys on.
  • access_policy — it evaluates the request against policy and renders the allow/deny-and-scope decision.
  • isolation_boundary — the scoped, unforgeable token confines each client to exactly the capability granted, isolating it from everything it was not given (capability-based security).

It does not shape or de-duplicate the request itself — that is Idempotent API; it does not advertise where the capability lives (Central Registry); and it neither sizes nor schedules the provider (Autoscaling Worker Pool, Weighted Fair Queue).

  • Instantiates: Request–Response Capability Provisioning — the broker supplies the access-control gate that lets the shared capability be offered to many clients without granting any of them more than a request warrants.
  • Sibling mechanisms: Central Registry · API or RPC Endpoint · Idempotent API · Safe Retry Protocol · Autoscaling Worker Pool · Parallel Server Activation · Rate Limit with Burst Allowance · Weighted Fair Queue · Service-Level Agreement · Service-Level Monitor · Intake Portal · Shared Service Desk · Ticketing System · Cache or Read Replica

Notes

Expiry and active revocation pull in opposite directions. Pure expiry keeps providers stateless — they trust any unexpired token — but cannot claw back a grant early. Adding a revocation list gives immediate cutoff at the price of making every provider check live shared state on each call, which is exactly the opaque coupling the request–response contract is meant to avoid. Keep tokens short-lived enough that expiry alone is usually sufficient, and reserve active revocation for the rare high-stakes grant.

References

The confused deputy problem — a privileged program induced to misuse its authority on behalf of a less-privileged caller (Norm Hardy, 1988). Capability-based designs mitigate it by passing narrow authority with the request rather than letting the broker act on ambient privilege.