What Is Basic Auth: How HTTP Basic Works

Basic Auth is a password on every request

HTTP Basic authentication is one of the oldest ways an HTTP client proves identity. The client joins a username and password with a colon, Base64-encodes the pair, and sends it in the Authorization header behind the scheme word Basic.

GET /reports/daily HTTP/1.1
Host: billing.internal.example
Authorization: Basic c3ZjX3JlcG9ydGluZzpzM2NyZXQ=

Decode that header value and you get svc_reporting:s3cret in plaintext. Base64 is not encryption. It is a reversible encoding chosen so the bytes survive HTTP headers. Anyone who can read the header can recover the password.

That is why Basic Auth is only acceptable over TLS. Without HTTPS, the password is on the wire. With HTTPS, TLS provides the confidentiality the scheme itself does not.

Why it still exists

Basic Auth survives because it is universally implemented and has no token lifecycle. Every HTTP client, from curl to a 15-year-old Java library, can send it. Internal tools, appliance APIs, and a surprising number of SaaS “machine users” still document it as the only option.

The cost of that simplicity is paid at leak time. A stolen Basic header is the password. Revoking it means changing the password on the upstream account – which breaks every other client sharing that account. There is no exp claim, no refresh, no scope narrower than “whatever this user can do.”

Compare that with a short-lived OAuth access token, which you can let expire, or an API key you can delete without resetting a human password. For the scheme comparison, see API authentication methods explained.

What goes on the wire

RFC 7617 is strict about the encoding:

1. Take username and password as UTF-8 (historically ISO-8859-1; modern servers expect UTF-8).
2. Concatenate username + ":" + password.
3. Base64-encode the bytes.
4. Send Authorization: Basic <encoded>.

Usernames must not contain a colon; the first colon is the split. Passwords may contain colons. There is no realm negotiation required on the client once you already know the credentials – the WWW-Authenticate: Basic realm="..." challenge is how a server asks, not how a machine client typically authenticates.

A gateway does not need to parse the encoded header on the way out. It stores username and password separately and builds the header per request. In RequestRocket that is credentialAuthType: "basic" with a secret of:

{
    "credentialType": "target",
    "credentialAuthType": "basic",
    "credentialName": "legacy-billing-basic",
    "credentialRegion": "us-east-1",
    "credentialSecret": {
        "username": "svc_reporting",
        "password": "s3cret"
    }
}

Those two fields are required. Optional additionalHeaders, additionalQueryParams, and additionalData cover vendors that want Basic and a static extra header. The password is encrypted at rest with AES-256-GCM and is not returned on later GET calls – once saved, you cannot read it back.

The same basic type is valid on proxy credentials: callers authenticate to the gateway with a username and password the gateway checks, then the gateway uses a different target credential toward upstream. Do not reuse the upstream password as the proxy password. That collapses inbound and outbound identity into one secret.

Where Basic Auth is the wrong default

Do not choose Basic because it is familiar if the vendor also offers OAuth client credentials or an API key you can rotate independently of a user account. Do not put Basic credentials in query strings or request bodies – the scheme is a header. Do not log Authorization values; a Base64 dump is the password.

If you are wrapping a legacy system that will never grow another scheme, Basic at the gateway is still the right move: the application holds a proxy credential, the password lives in one encrypted record, and you can rotate it without a code change. That operational split is the point of upstream credential types.

Finally, if you’re ingesting data into Power BI - fun fact - it only offers support for securing, AD Oauth2, X-API-Key, and Basic Authentication credentials. Consider translating from the upstream service into one of these for easier and more secure connectivity.

Next steps

Configure Basic as a target credential when the upstream has no better option, and keep the password off developer laptops. Details are in the credentials guide. RequestRocket is runtime access control for AI agents and apps calling APIs you don’t own – every call gets a least-privilege credential, a policy check, and an audit record, with no code changes.