Authorization Header

What the Authorization Header Does

The Authorization header is the HTTP mechanism that carries a caller’s credentials or token to the receiving service. In bearer-token designs, it usually contains the access token value, and the server uses that value to determine who is calling and what rights the request should receive.

Its placement in the request is operationally important. If the token is sent in the wrong place, omitted, duplicated, or exposed in logs and intermediaries, the service may reject the request or, worse, sensitive access material may leak beyond the intended trust boundary.

Because the header is part of the HTTP exchange itself, it is one of the most common places where API authentication and request authorisation intersect. That makes it a small syntactic detail with a large security impact.

Bearer Tokens, Caller Identity, and Access Decisions

In practice, the Authorization header is often paired with OAuth 2.0-style access tokens, where the token represents an already-authenticated caller. The service inspects the token, validates it, and then applies access policy based on the identity and scopes encoded in or associated with that token.

This is why the header is not just a container for text. It is the handoff point between authentication and authorisation, and the service’s handling of that value determines whether the request is treated as anonymous, authenticated, privileged, or denied.

Where bearer semantics are used, possession of the token is usually enough to use it. That makes token handling highly sensitive: anyone who can copy the value may be able to replay it until it expires or is revoked.

For a broader view of how access decisions are structured, the Authorisation Models Guide explains how RBAC, ABAC, ReBAC and policy-based approaches shape what a request is allowed to do.

How the Header Is Commonly Used in APIs

API clients typically send the header as part of every authenticated request, which makes it a foundational transport for machine-to-machine access. In modern systems, it can also appear in browser-based apps, backend services, service-to-service calls, and agent-driven workflows where a runtime needs to present credentials to an API.

The receiving service should treat the header as security-sensitive input, not ordinary metadata. It may need to validate the token format, verify issuer and audience expectations, enforce scope or policy, and reject requests that try to pass credentials in unsupported ways.

When the header is part of a broader token-based design, the surrounding platform matters too. OAuth resource servers, protected resource metadata, and client authentication choices all shape how the token is acquired and checked before the API ever sees the request.

For the underlying protocol mechanics, RFC 6749: The OAuth 2.0 Authorization Framework defines the core framework for access tokens used in this pattern, while RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants covers JWT-based client authentication flows.

Handling, Exposure, and Operational Consequences

The biggest practical danger is accidental exposure. Authorization headers can be copied into application logs, reverse-proxy traces, crash reports, browser tooling, HAR files, or support bundles if redaction is incomplete. Once exposed, a bearer token can become a ready-made replay credential.

That is why good handling is less about the header name itself and more about the lifecycle of the value it carries. Teams need to assume the header may be inspected by middleware, debugging tools, and observability systems unless controls are deliberately designed to prevent that.

Post-compromise review should therefore focus on where the token appeared, how long it may have been valid, what rights it conferred, and whether the same credential was reused across multiple systems or sessions. In many cases, the right response is to revoke the token and review adjacent secrets, keys, or sessions that may have been exposed with it.

For leak triage and revocation guidance, JWT and Session Tokens in Code and Logs Guide covers bearer token exposure patterns across code, logs, traces and support artefacts.

Common Implementation Mistakes and Better Practice

A frequent mistake is to treat the Authorization header as interchangeable with query parameters, form fields, or custom headers. The standard location matters because API gateways, clients, libraries, and security tools are built to inspect the canonical header path first.

Another common error is to assume “token present” means “request is safe”. A valid-looking token can still be overprivileged, expired, audience-mismatched, or copied from an unintended context. The header only transports the credential; it does not guarantee that the credential is appropriate for the request.

Teams should also avoid designing systems that encourage manual copying of Authorization values between tools, environments, or users. That pattern weakens traceability and increases the chance that an access token will outlive the session or intent that created it.

If the API itself is the security boundary, OWASP API Security Top 10 is a useful companion for understanding how authentication and authorisation failures show up at the API layer.

Related resources from NHI Mgmt Group

• How do HTTP header based capability models compare with SDK bound integrations for application authorization?
• What breaks when an API is protected only by a mock login header instead of real authorization?
• HTTP Header Based Authorization
• Authorization: Bearer Header