State and authentication

Use Basic authentication

Send Basic authentication over verified HTTPS without embedding credentials in a shared URL.

10 minute lesson

~~~

HTTP Basic authentication is the oldest and simplest auth scheme on the web: the client sends a username and password in an Authorization header with every request. The pair is joined with a colon and Base64-encoded — encoded, not encrypted. Base64 is trivially reversible, so the scheme itself protects nothing. HTTPS must protect the connection, or you are broadcasting a password.

You still meet Basic auth constantly: staging environments behind a shared password, internal dashboards, webhooks, and countless APIs that use it for token-plus-empty-password schemes.

Authenticate a request

Use a disposable lab credential against an endpoint built for practice:

curl --user 'student:practice-only' https://httpbin.org/basic-auth/student/practice-only

A matching credential returns success:

{
  "authenticated": true,
  "user": "student"
}

Change the password and run it again. The server answers 401 Unauthorized and curl prints nothing useful — add --write-out '%{response_code}\n' to see the status, or --fail to turn the 401 into exit code 22 a script can act on.

What actually happened: curl took student:practice-only, Base64-encoded it to c3R1ZGVudDpwcmFjdGljZS1vbmx5, and sent Authorization: Basic c3R1ZGVudDpwcmFjdGljZS1vbmx5. Run echo 'c3R1ZGVudDpwcmFjdGljZS1vbmx5' | base64 -d and the password stares back at you. That is why the HTTPS requirement is absolute.

Add -v only in a private terminal, because verbose output can reveal the Authorization header.

Keep the password out of history

The command above stores the password in your shell history. For real credentials, give --user only the username and let curl prompt:

curl --user student https://httpbin.org/basic-auth/student/practice-only
# Enter host password for user 'student':

The password never touches history, process listings, or your screen.

Avoid the other tempting shortcut too: credentials embedded in the URL, like https://student:[email protected]/.... URLs end up in logs, browser history, and pasted messages, and a URL-shaped secret gets copied around without anyone noticing it contains a password.

My advice is a simple hierarchy. Prefer a prompt for interactive use, a protected configuration file or secret manager for automation, and never a credential typed inline in a shared terminal or committed script.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →