Challenge, credentials and validation
01A client asks for a protected resource; the origin server can ask it to authenticate before serving that resource.
In a valid example the server serves the resource. Invalid credentials do not gain access; the separate failure branch remains challenged. Never infer acceptance from Base64 syntax alone.
Source for this drawing: RFC 7617 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Challenge
- A response asking the client to authenticate using a named scheme.
- Realm
- A server-defined protection-space label, compared for equality on that server.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Separates the Basic definition and adds an advisory charset parameter. Companion framework/Digest documents also participate in obsoleting RFC 2617; this does not replace Digest with Basic.
Read the updated RFC section ↗A Basic challenge requires realm, a name for a protection space. Realm strings are compared for equality on that server; they are not global user identities.
- A Basic challenge requires realm, a name for a protection space. Realm strings are compared for equality on that server; they are not global user identities.
- The origin challenge uses 401 and WWW-Authenticate. A proxy challenge instead uses 407 and Proxy-Authenticate; proxy credentials use Proxy-Authorization.
- Scheme and parameter names are case-insensitive. Recipients MUST ignore unknown challenge parameters. Only realm and optional charset are defined here.
- The server services the request only if it validates the user-id and password for the applicable protection space. Merely decoding Base64 is not validation.
Assume HTTPS to api.example and a fictional picnic realm. The final state shows separate valid and invalid credential cases, not two responses to one request. A 200 is a chosen successful response, not a mandatory result of sending Authorization. Basic does not specify a login form, session cookie, logout UI or password database algorithm.
Read the RFC section ↗