Base64 Credential Scheme

## What Basic authentication is Basic is the simplest scheme in the HTTP authentication framework, defined today by RFC 7617 (it updates the older RFC 2617 text). It transmits a user id and a password on each request. There is no challenge computation, no nonce, no signature — the client hands over the secret itself and the server checks it. ## Building the header value The algorithm is fully mechanical: 1. Concatenate the user id, a single `:` (colon, U+003A), and the password. 2. Encode that string to bytes (UTF-8, see the `charset` parameter). 3. Base64-encode those bytes. 4. Send `Authorization: Basic <that base64 string>`. For `alice` / `s3cret` the joined string is `alice:s3cret`, whose base64 form is `YWxpY2U6czNjcmV0`. The scheme name (`Basic`) is case-insensitive; exactly one space separates it from the credentials. ## Encoding is not protection This is the single point interviewers are checking. Base64 is a binary-to-text encoding: it maps three bytes onto four printable characters so that bytes outside the header's allowed character set (spaces, non-ASCII, control characters) can travel in an HTTP header. It uses no key, so it is trivially reversible — `echo YWxpY2U6czNjcmV0 | base64 -d` prints `alice:s3cret`. It is not encryption (no key, no confidentiality) and not hashing (it is reversible, unlike a one-way digest). Anyone who can read the request — a passive tap on plaintext HTTP, a logging proxy, an APM tool that captures headers, a browser extension — reads the password. The consequence: Basic must run inside TLS, and access logs and telemetry must scrub the `Authorization` header. RFC 7617 is explicit that Basic provides no confidentiality on its own and must be paired with a secure channel. ## The colon rule and empty values The separator is the *first* colon. Therefore the **user id must not contain a colon** — if it does, the server cannot parse the pair unambiguously and the credential is invalid. The password may contain colons freely: `bob:a:b:c` is user `bob`, password `a:b:c`. Empty halves are legal at the syntax level: `bob:` (`Ym9iOg==`) is user `bob` with an empty password, and `:onlypass` (`Om9ubHlwYXNz`) is an empty user id — some APIs use this shape to carry a single API key in the password field (`curl -u :$TOKEN`). ## Sent on every request Basic is stateless. HTTP itself has no memory between requests, and Basic adds none: there is no server-side session created by authenticating. The client therefore attaches the same `Authorization` header to every request in the protected space. Two consequences follow. First, the exposure window is not "one login" but "every single request" — any one captured request leaks the password. Second, the server pays the password-verification cost on every request, which matters when the stored password is a deliberately slow hash. ## Where the realm fits When the server wants to prompt for credentials it replies `401 Unauthorized` with `WWW-Authenticate: Basic realm="Reports API", charset="UTF-8"`. `realm` is a human-readable label that names the *protection space*: clients (and browsers) cache credentials against origin + realm and reuse them for other URLs under the same space. It carries no security by itself; it exists so a client knows which stored credential applies and so a browser dialog can say what it is asking for. `charset="UTF-8"` tells the client to encode the credentials as UTF-8 before base64. ## Tooling `curl -u alice:s3cret https://api.example.com/x` builds the header and, for Basic, sends it **preemptively** on the first request rather than waiting for a 401. `curl -u alice` prompts for the password so it does not land in your shell history or the process list — a real operational detail, since command lines are visible to other users via `ps` and end up in `~/.zsh_history`. ## When Basic is still reasonable Despite its reputation, Basic is fine for machine-to-machine calls over TLS with a high-entropy generated secret rather than a human password: it is trivially implementable in any client, needs no library, and has no token lifecycle. It is a poor fit for browser-facing user login (no logout, no session control, credentials cached by the browser, no MFA path) and for anything crossing a network you do not control unencrypted.