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[1] — 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).
Also instantiates¶
The same broker serves two further archetypes; the problem each solves is different even though the tool is one.
Evidence-Bound Authentication — Capability provisioning asks how much access to grant; this archetype asks a prior question — is the asserted identity even bound to the caller in front of us? The broker fills the authentication half of its own work here: before any grant is contemplated, it decides whether a name, token, or federated assertion actually ties to the present principal at the present moment. That is a distinct discipline from least-privilege scoping — a valid-but-stolen credential, a signature minted for the wrong audience, or a replayed token all pass a scope check yet fail a binding check, and it is the binding check the broker owns.
asserted_identity_or_origin_claim— the broker states precisely what is being claimed (this request comes from this account holder) before it admits any evidence.admissible_evidence_standard— its authentication-strength and step-up settings are the evidence standard: a password for low-risk reads, MFA or continuous verification for sensitive actions.evidence_to_claim_binding_rule— it binds the presented factor to the present claimant and checks freshness, revocation, and replay, so a genuine-but-misbound credential is caught rather than honored.authentication_verdict_taxonomy— it emits more than pass/fail — accepted, rejected, expired, revoked, or step-up-required — letting a legitimate edge case be remediated without lowering the bar.
Gateway Mediation — Here the broker is not a capacity-sharing device but the identity gate of a governed boundary crossing: it sits at the perimeter of a protected domain and makes passage conditional, so no caller reaches an internal service without first being received, checked, and recorded. The angle that differs from both facets above is the boundary itself — the broker exists to keep a meaningful boundary permeable-but-controlled, standing in front of many downstream services so each need not improvise its own gate.
gateway_node— the broker is the controlled mediation point through which identity-bearing traffic must pass to cross the boundary.validation_rule— it checks that an incoming request is authenticated and well-formed before forwarding it, keeping unauthorized crossings from reaching the protected side.access_policy— it decides who or what may cross and under which conditions, centralizing a rule every downstream service would otherwise duplicate.monitoring_and_audit_signal— the record of who was granted what, and when, is the gateway's audit trail, making the crossing point observable and contestable.
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: 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, making its operative form a state-dependent executable control that senses, filters, routes, or actuates during operation.
Independent corroboration: The frozen evidence defines Authentication Broker as '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', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Identity brokers and security-token services are canonical software architecture components for scoped delegated authentication.
Related originating lineages:
- Security Studies & Intelligence Analysis — Security practice supplies least privilege, identity assurance, and short-lived credential requirements.
Review resolution: Computer science is the agreed primary lineage. Identity and access security is the material alternate behind scoped short-lived tokens; legal delegation is a downstream analogy rather than an independent origin of the broker architecture.
Review outcome: Reconciled after independent review; high confidence.
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¶
[1] Hardy, N. "The Confused Deputy: (or why capabilities might have been invented)". ACM SIGOPS Operating Systems Review 22(4), 36–38 (1988). Shows how a caller can exploit a privileged program's ambient authority, inducing it to exercise that authority for a purpose the caller could not authorize directly. registry ↩