1001Ferramentas
🔑 Dev

Authorization Header Parser

Identify the scheme (Basic, Bearer, Digest) of an Authorization header and extract the payload, decoding Basic from base64.

Reading the Authorization header: Basic, Bearer and Digest

Authorization has two parts: the scheme and the credentials, and the credential format depends entirely on the scheme. The page recognises the three commonest and decodes what can be decoded — for Basic, the username and password pair; for Bearer, the token; for Digest, each named parameter.

The commonest misconception is that Basic protects something. It merely joins username and password with a colon and runs base64 over it, which is encoding, not encryption — anyone who sees the header recovers the password instantly. Basic is only acceptable over TLS, and even then the password travels on every request, which multiplies the exposure.

A detail that bites implementers: since the separator is the first colon, a password may contain colons but a username may not. A parser splitting on the last colon, or using a plain split, breaks on exactly the strongest passwords. The page splits on the first occurrence, which is what the standard requires.

Frequently asked questions

Is Bearer with a JWT secure?
The scheme is only transport — the security lives in the token. The recipient must verify signature, issuer, audience and expiry; reading the claims without verifying the signature means accepting whatever the client invents. And since Bearer means bearer, whoever holds the token is the owner: intercepting it is enough to use it.
Is Digest still worth it?
Rarely. It avoids sending the password in the clear via challenge and response, which made sense before ubiquitous TLS, but it requires the server to store the password in a form that allows recomputing the hash — the opposite of today's advice. With TLS, Bearer with a short-lived token solves it better.
Why do I see a header with two schemes?
Because the server may offer several in WWW-Authenticate for the client to choose from, and that response lists the options. The Authorization the client sends carries one scheme only — if you see two there, something probably concatenated two headers, and the server will reject it.

Related Tools