WWW-Authenticate

Verwendung

Fordert ein Client eine geschützte Ressource ohne gültige Anmeldedaten an, antwortet der Server mit dem Statuscode 401 und fügt den WWW-Authenticate-Header hinzu. Dieser Header transportiert eine oder mehrere Authentifizierungsaufforderungen, von denen jede ein Schema und alle Parameter angibt, die der Client zum Erstellen gültiger Anmeldedaten benötigt.

Nach Erhalt der Aufforderung sendet der Client die Anfrage erneut, diesmal mit einem Authorization-Header, der die gemäß dem gewählten Schema formatierten Anmeldedaten enthält. Der Server prüft die Anmeldedaten und liefert bei Erfolg die angeforderte Ressource aus.

Mehrere Aufforderungen in einer einzelnen Antwort erlauben es dem Server, gleichzeitig mehrere Schemata anzubieten. Der Client wählt das stärkste Schema, das beide Seiten unterstützen. Die Aufforderungen erscheinen auf getrennten Header-Zeilen oder in einer einzelnen, durch Kommas getrennten Zeile.

Der entsprechende Header für die Authentifizierung auf Proxy-Ebene ist Proxy-Authenticate, der eine 407-Antwort statt einer 401-Antwort auslöst.

scheme

Das Schema benennt die Authentifizierungsmethode. Die registrierten Schemata werden von der IANA gepflegt. Die in der Praxis gebräuchlichsten Schemata werden im Folgenden beschrieben.

Basic sendet ein Base64-kodiertes Paar aus username:password. Das Schema akzeptiert einen realm-Parameter und einen optionalen charset-Parameter (typischerweise UTF-8).

Bearer authentifiziert mit einem undurchsichtigen Zugriffstoken, das meist über einen OAuth-Ablauf ausgestellt wird. Das Schema unterstützt die Parameter realm, scope und error. Der Parameter scope listet die Berechtigungen auf, die das Token tragen muss. Der Parameter error übermittelt konkrete Fehlerursachen wie invalid_token oder insufficient_scope.

Digest verbessert Basic, indem es die Anmeldedaten mit einem vom Server bereitgestellten nonce hasht und so verhindert, dass das Passwort im Klartext übertragen wird. Zu den erforderlichen Parametern gehören realm, nonce und qop (quality of protection). Optionale Parameter sind algorithm, opaque und stale.

Negotiate startet eine SPNEGO-basierte Authentifizierung, die in Unternehmensumgebungen typischerweise durch Kerberos oder NTLM gestützt wird. Das Schema führt ein Base64-kodiertes SPNEGO-Token mit, solange die Aushandlung läuft.

realm

Der Parameter realm ist eine optionale Zeichenkette, die den Schutzbereich definiert. Der Wert hilft Nutzern zu erkennen, welche Anmeldedaten benötigt werden. Ein Server, der unterschiedliche Bereiche schützt, vergibt für jeden davon einen eigenen realm-Wert.

token68

Die token68-Syntax ist eine alternative Kodierung für Anmeldedaten, die das HTTP-Authentifizierungs-Framework zulässt. Der Wert verwendet einen eingeschränkten Zeichensatz (alphanumerische Zeichen, -, ., _, ~, +, /) mit optionaler abschließender =-Auffüllung.

Beispiel

Ein Server, der eine Ressource mit Basic-Authentifizierung schützt, liefert eine Aufforderung samt des dem Nutzer angezeigten realm-Namens zurück.

WWW-Authenticate: Basic realm="Staging Environment"

Eine Bearer-Token-Aufforderung teilt den erforderlichen scope mit und signalisiert über den Parameter error ein abgelaufenes Token.

WWW-Authenticate: Bearer realm="api.example.re", scope="read write", error="invalid_token"

Eine Digest-Aufforderung enthält den vom Server erzeugten nonce sowie die Einstellung zur Schutzqualität.

WWW-Authenticate: Digest realm="admin@example.re", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", qop="auth", algorithm=SHA-256

Ein Server, der mehrere Schemata anbietet, listet sie auf, damit der Client die stärkste Option wählt.

WWW-Authenticate: Negotiate
WWW-Authenticate: Bearer realm="api.example.re"
WWW-Authenticate: Basic realm="api.example.re"

Ein vollständiger Basic-Authentifizierungs-Handshake. Der Client fordert zunächst eine geschützte Ressource ohne Anmeldedaten an:

GET /admin HTTP/1.1
Host: example.re

Der Server antwortet mit 401 und einer Basic-Aufforderung:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="API"

Der Client versucht es erneut mit einem Authorization-Header, der das Base64-kodierte Paar aus username:password enthält:

GET /admin HTTP/1.1
Host: example.re
Authorization: Basic dXNlcjpwYXNz

Der Server prüft die Anmeldedaten und liefert die Ressource aus:

HTTP/1.1 200 OK
Content-Type: text/html