Visual RFC.
ALL RFCs / RFC 7617
Read the RFC ↗

RFC 7617 / START HERE

HTTP Basic, before the details

HTTP Basic authentication: Basic is a scheme name; HTTP means Hypertext Transfer Protocol.

Basic lets an HTTP client present a user-id and password to a server. The server can first send a challenge naming a realm, its protection space, then validate the credential on the retried request.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Server challenges

  2. Client encodes credentials

  3. HTTPS protects the path

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

RFC 7617 defines the Basic credential format and an optional UTF-8 preference. It helps explain password-based HTTP access and its limits. It replaces the earlier Basic definition alongside companion documents; it is different from OAuth bearer access tokens and from Digest authentication.

A familiar example

A fictional HTTPS picnic API challenges an application with realm="picnic". The application sends a Base64-encoded user-id:password. The server must validate it: Base64 is reversible and HTTPS is needed to protect it on the network. The server still sees the password.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

HTTPRFC 9110 · beginner overview ↗Base encodingsRFC 4648 · beginner overview ↗TLS 1.3RFC 8446 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Challenge, credentials and validationA client asks for a protected resource; the origin server can ask it to authenticate before serving that resource.
  2. From user and password to Base64Basic serializes a user-id, a colon separator and a password, then encodes their bytes as Base64 text.
  3. Advertise UTF-8 without changing the defaultA server can advertise how it wants non-ASCII credentials encoded, while old clients may keep their existing behavior.
  4. Reuse credentials within the inferred scopeAfter a successful authenticated request, a client can infer where the same credentials might apply and optionally send them before another challenge.
  5. Protect transport and check the recipientThe same Basic value can cross an exposed network or an HTTPS-protected connection. The server still receives the password in either case.
Start with chapter one →

This introduction explains RFC 7617 (2015). Read the original RFC ↗