Arcade Headers Mode is an authentication approach that sends a gateway credential and a verified end-user identifier in request headers on every call. It is used when browser-based OAuth support is unreliable or incomplete in the client. This pattern preserves per-user authorization while keeping downstream secrets out of local prompt and config surfaces.
What Arcade Headers Mode Actually Does
Arcade Headers Mode is an authentication pattern that places a gateway credential and a verified end-user identifier into request headers on each call. The client relies on the gateway to preserve per-user context when browser-based OAuth support is unreliable or incomplete.
This is not just a transport detail. The pattern is doing two jobs at once: authenticating the request path to the gateway and carrying user identity downstream so authorization decisions can still be made per user rather than per shared integration.
Why This Pattern Exists
Teams use this pattern when the preferred browser OAuth flow is fragile, unavailable, or awkward in a given client runtime. Instead of forcing local token handling, the client sends a gateway credential and lets the gateway inject a trusted user identity into the next hop.
The practical value is that downstream services can continue to distinguish one user from another without exposing secrets in local prompt, config, or application surfaces. That keeps the integration usable in constrained clients while preserving a separation between gateway trust and end-user context.
How It Preserves Authorization Context
The key design idea is that the gateway credential authenticates the calling path, while the verified end-user identifier represents the user on whose behalf the request is made. Those two values are related but not interchangeable.
If implemented well, this gives downstream services a stable user context for logging, policy evaluation, and authorization checks. It also means the gateway becomes a trust boundary, because downstream services must rely on it to assert that the user identifier is genuine and current.
Where It Fits Best, and Where It Does Not
Arcade Headers Mode is best suited to controlled enterprise workflows, brokered integrations, and clients that cannot consistently complete interactive browser OAuth. It is a pragmatic pattern for preserving per-user access semantics without pushing sensitive authentication material into brittle client state.
It is a poor fit when the gateway cannot be strongly trusted, when downstream systems cannot validate the header-bearing context, or when the organization needs a fully standards-native browser authorization flow end to end. In those cases, the convenience of header-based propagation can create a false sense of identity assurance.
Risk and Threat Considerations
This pattern concentrates trust in the gateway and in the integrity of the headers it emits. If an attacker can forge, replay, or alter the end-user identifier, the downstream system may authorize actions as the wrong person while believing the request is authenticated.
Failure mechanism: Header trust can fail if the gateway credential is stolen, if intermediate services accept client-supplied identity headers, or if identity propagation is not cryptographically or operationally constrained end to end.
Impact: The result can be account impersonation, privilege misuse, incorrect audit trails, and authorization decisions that no longer match the real caller.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Per-user request handling depends on authenticating the human caller behind the gateway. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | The pattern preserves an end-user identity across a brokered request path. | |
| IA-5 — Authenticator Management | Gateway credentials and propagated identity material must be issued, protected, rotated, and revoked. | |
| Recommendation — Authenticate organizational users before accepting requests that carry user context through the gateway. Validate the user identity asserted through the brokered path before authorizing downstream actions. Manage gateway credentials and related identity material with strict lifecycle controls. | ||
Practitioner Guidance
Why practitioners should care: The main design decision is not whether headers are convenient, but whether the downstream system can safely treat the user identifier as gateway-issued truth. The pattern only works when that trust boundary is explicit and consistently enforced.
What to watch for: Treat any place where client code can set identity headers directly as a red flag, and be careful when multiple hops can mutate or forward those values. The more uncontrolled the path, the less this pattern behaves like authentication and the more it becomes a spoofable convention.
Practitioner takeaway: Use the pattern as a brokered trust mechanism, not as a shortcut for authentication design. The gateway must be the single source of identity assertion, and downstream services should only consume identity they can reasonably trust.
