Authorization

Authentication IANA permanent request 3 spellings

Authorization is where HTTP puts credentials, and after thirty years it is still the single most-declared header in published API contracts. It takes a scheme and a credential — Bearer, Basic, Digest, and lately DPoP — and the scheme matters as much as the value, because it tells the recipient how to validate what follows.

The interesting thing about Authorization in the catalog is not how often it appears. It is how it appears. An enormous number of contracts declare it as an ordinary header parameter — a string, required, described as “your API token” — rather than as a securityScheme. Both produce a working request. Only one produces a generated client that knows it is holding a credential, a documentation renderer that offers an auth box, and an agent that understands it needs to acquire something before it can call.

The registry

Listed in the IANA HTTP Field Name Registry as a permanent entry. Defined in RFC 9110, Section 11.6.2: HTTP Semantics.

In the catalog

Declared by 1,176 providers across 36,354 published specification files in the API Evangelist catalog, where it appears as a request header — sent by the client.

It is spelled 3 different ways across those contracts — Authorization, authorization, AUTHORIZATION. HTTP field names are case-insensitive (RFC 9110, §5.1), so every one of these is the same header. They are not the same string, which is why generated clients disagree about it.

Using it

Declare it as a securityScheme, never as a parameter. In OpenAPI that means type: http with scheme: bearer for tokens, or type: oauth2 with the flows spelled out. If you find yourself writing name: Authorization, in: header in a parameters block, you are describing the wire correctly and the contract wrongly.

Do not put credentials in the query string as an alternative. A URL travels into browser history, proxy logs, referrer headers and error reports; a header does not.