WWW-Authenticate header

Syntax

WWW-Authenticate: <challenge>

Dabei besteht eine <challenge> aus einem <auth-scheme>, gefolgt von einem optionalen <token68> oder einer durch Kommas getrennten Liste von <auth-params>:

challenge = <auth-scheme> <auth-param>, …, <auth-paramN>
challenge = <auth-scheme> <token68>

Zum Beispiel:

WWW-Authenticate: <auth-scheme>
WWW-Authenticate: <auth-scheme> token68
WWW-Authenticate: <auth-scheme> auth-param1=param-token1
WWW-Authenticate: <auth-scheme> auth-param1=param-token1, …, auth-paramN=param-tokenN

Das Vorhandensein eines token68 oder von Authentifizierungsparametern hängt vom ausgewählten <auth-scheme> ab. Beispielsweise erfordert die Basic-Authentifizierung ein <realm> und erlaubt die optionale Verwendung des Schlüssels charset, unterstützt jedoch kein token68:

WWW-Authenticate: Basic realm="Dev", charset="UTF-8"

Mehrere Challenges können in einer durch Kommas getrennten Liste gesendet werden:

WWW-Authenticate: <challenge>, …, <challengeN>

Mehrere Header können auch in einer einzelnen Antwort gesendet werden:

WWW-Authenticate: <challenge>
WWW-Authenticate: <challengeN>

Direktiven

<auth-scheme>

Ein Token ohne Beachtung der Groß- und Kleinschreibung, das das verwendete Authentifizierungsschema angibt. Zu den häufigeren Typen gehören Basic, Digest, Negotiate und AWS4-HMAC-SHA256. IANA verwaltet eine Liste von Authentifizierungsschemas, es gibt jedoch auch andere von Hostdiensten angebotene Schemata.

<auth-param> Optional

Ein Authentifizierungsparameter, dessen Format vom <auth-scheme> abhängt. <realm> wird unten beschrieben, da es bei vielen Authentifizierungsschemas ein häufiger Authentifizierungsparameter ist.

<realm> Optional

Die Zeichenfolge realm, gefolgt von = und einer Zeichenfolge in Anführungszeichen, die einen geschützten Bereich beschreibt, beispielsweise realm="staging environment". Ein Realm ermöglicht es einem Server, die Bereiche, die er schützt, zu unterteilen (wenn dies von einem Schema unterstützt wird, das eine solche Unterteilung erlaubt). Einige Clients zeigen diesen Wert dem Benutzer an, um ihn darüber zu informieren, welche bestimmten Anmeldedaten erforderlich sind — die meisten Browser haben dies jedoch eingestellt, um Phishing entgegenzuwirken. Der einzig zuverlässig unterstützte Zeichensatz für diesen Wert ist us-ascii. Wenn kein Realm angegeben ist, zeigen Clients stattdessen häufig einen formatierten Hostnamen an.

<token68> Optional

Ein Token, das für einige Schemata nützlich sein kann. Das Token erlaubt die 66 nicht reservierten URI-Zeichen sowie einige weitere. Es kann eine base64-, base64url-, base32- oder base16-(hex)-Codierung mit oder ohne Padding enthalten, jedoch keine Leerzeichen. Die token68-Alternative zu auth-param-Listen wird aus Konsistenzgründen mit älteren Authentifizierungsschemas unterstützt.

Im Allgemeinen müssen Sie die jeweiligen Spezifikationen prüfen, um die für jedes <auth-scheme> erforderlichen Authentifizierungsparameter zu ermitteln. Die folgenden Abschnitte beschreiben Token- und Authentifizierungsparameter für einige gängige Authentifizierungsschemas.

Basic-Authentifizierungsdirektiven

<realm>

Ein <realm> wie oben beschrieben. Beachten Sie, dass der Realm für die Basic-Authentifizierung obligatorisch ist.

charset="UTF-8" Optional

Teilt dem Client das bevorzugte Codierungsschema des Servers mit, wenn ein Benutzername und ein Passwort übermittelt werden. Der einzig zulässige Wert ist die Zeichenfolge UTF-8 ohne Beachtung der Groß- und Kleinschreibung. Dies bezieht sich nicht auf die Codierung der Realm-Zeichenfolge.

Digest-Authentifizierungsdirektiven

<realm> Optional

Ein <realm> wie oben beschrieben, das angibt, welcher Benutzername bzw. welches Passwort verwendet werden soll. Es sollte mindestens den Hostnamen enthalten, kann jedoch auch die Benutzer oder Gruppe angeben, die Zugriff haben.

domain Optional

Eine Zeichenfolge in Anführungszeichen mit einer durch Leerzeichen getrennten Liste von URI-Präfixen, die alle Orte definiert, an denen die Authentifizierungsinformationen verwendet werden können. Wenn dieser Schlüssel nicht angegeben ist, können die Authentifizierungsinformationen überall im Web-Root verwendet werden.

nonce

Eine vom Server angegebene Zeichenfolge in Anführungszeichen, mit der der Server die Gültigkeitsdauer steuern kann, innerhalb derer bestimmte Anmeldedaten als gültig betrachtet werden. Sie muss bei jeder 401-Antwort eindeutig generiert werden und kann häufiger neu generiert werden (beispielsweise, um die Verwendung eines Digest nur einmal zu erlauben). Die Spezifikation enthält Hinweise zu möglichen Algorithmen für die Generierung dieses Werts. Der Wert nonce ist für den Client undurchsichtig.

opaque

Eine vom Server angegebene Zeichenfolge in Anführungszeichen, die unverändert im Authorization zurückgegeben werden soll. Sie ist für den Client undurchsichtig. Dem Server wird empfohlen, Base64- oder hexadezimale Daten einzuschließen.

stale Optional

Ein Flag ohne Beachtung der Groß- und Kleinschreibung, das angibt, dass die vorherige Anfrage des Clients abgelehnt wurde, weil der verwendete nonce zu alt (stale) ist. Wenn dies true ist, kann die Anfrage mit demselben Benutzernamen/Passwort erneut versucht werden, verschlüsselt mit dem neuen nonce. Hat es einen anderen Wert, sind Benutzername/Passwort ungültig und müssen erneut beim Benutzer angefordert werden.

algorithm Optional

Eine Zeichenfolge, die den zur Erstellung eines Digest verwendeten Algorithmus angibt. Gültige Nicht-Sitzungswerte sind: MD5 (Standard, wenn algorithm nicht angegeben ist), SHA-256, SHA-512. Gültige Sitzungswerte sind: MD5-sess, SHA-256-sess, SHA-512-sess.

qop

Zeichenfolge in Anführungszeichen, die die vom Server unterstützte Schutzqualität angibt. Diese muss angegeben werden, und nicht erkannte Optionen müssen ignoriert werden.

• "auth": Authentifizierung
• "auth-int": Authentifizierung mit Integritätsschutz

charset="UTF-8" Optional

Teilt dem Client das bevorzugte Codierungsschema des Servers mit, wenn ein Benutzername und ein Passwort übermittelt werden. Der einzig zulässige Wert ist die Zeichenfolge UTF-8 ohne Beachtung der Groß- und Kleinschreibung.

userhash Optional

Ein Server kann "true" angeben, um anzuzeigen, dass er das Hashing von Benutzernamen unterstützt (Standard ist "false").

HTTP Origin-Bound Authentication (HOBA)

<challenge>

Eine Menge von Paaren im Format <len>:<value>, die miteinander verkettet werden, um sie einem Client zu übergeben. Die Challenge besteht aus einem Nonce, Algorithmus, Origin, Realm, Schlüsselbezeichner und der Challenge.

<max-age>

Die Anzahl der Sekunden ab dem Zeitpunkt, an dem die HTTP-Antwort ausgegeben wird, für die Antworten auf diese Challenge akzeptiert werden können.

<realm> Optional

Wie oben im Abschnitt Direktiven.

Beispiele

Mehrere Authentifizierungs-Challenges ausgeben

Mehrere Challenges können in einem einzelnen Antwort-Header angegeben werden:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: challenge1, …, challengeN

Mehrere Challenges können in separaten WWW-Authenticate-Headern in derselben Antwort gesendet werden:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: challenge1
WWW-Authenticate: challengeN

Basic-Authentifizierung

Ein Server, der nur Basic-Authentifizierung unterstützt, kann einen WWW-Authenticate-Antwort-Header haben, der wie folgt aussieht:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Staging server", charset="UTF-8"

Ein User-Agent, der diesen Header empfängt, fordert den Benutzer zunächst zur Eingabe seines Benutzernamens und Passworts auf und fragt die Ressource dann erneut an, wobei die codierten Anmeldedaten im Authorization-Header enthalten sind. Der Authorization-Header könnte wie folgt aussehen:

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Für die Basic-Authentifizierung werden die Anmeldedaten erstellt, indem zuerst Benutzername und Passwort mit einem Doppelpunkt kombiniert werden (aladdin:opensesame) und die resultierende Zeichenfolge dann in `base64` codiert wird (YWxhZGRpbjpvcGVuc2VzYW1l).

Digest-Authentifizierung mit SHA-256 und MD5

Der Client versucht, auf ein Dokument unter der URI http://www.example.org/dir/index.html zuzugreifen, das über Digest-Authentifizierung geschützt ist. Der Benutzername für dieses Dokument ist „Mufasa“ und das Passwort ist „Circle of Life“ (beachten Sie das einzelne Leerzeichen zwischen den Wörtern).

Beim ersten Anfordern des Dokuments durch den Client wird kein Authorization-Header-Feld gesendet. Hier antwortet der Server mit einer HTTP-401-Nachricht, die für jeden unterstützten Digest-Algorithmus in seiner bevorzugten Reihenfolge (SHA256 und dann MD5) eine Challenge enthält.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
    realm="http-auth@example.org",
    qop="auth, auth-int",
    algorithm=SHA-256,
    nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
    opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
    realm="http-auth@example.org",
    qop="auth, auth-int",
    algorithm=MD5,
    nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
    opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

Der Client fordert den Benutzer zur Eingabe seines Benutzernamens und Passworts auf und antwortet dann mit einer neuen Anfrage, die die Anmeldedaten im Authorization-Header-Feld codiert. Wenn der Client den MD5-Digest auswählt, könnte das Authorization-Header-Feld wie unten dargestellt aussehen:

Authorization: Digest username="Mufasa",
    realm="http-auth@example.org",
    uri="/dir/index.html",
    algorithm=MD5,
    nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
    nc=00000001,
    cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
    qop=auth,
    response="8ca523f5e9506fed4657c9700eebdbec",
    opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

Wenn der Client den SHA-256-Digest auswählt, könnte das Authorization-Header-Feld wie unten dargestellt aussehen:

Authorization: Digest username="Mufasa",
    realm="http-auth@example.org",
    uri="/dir/index.html",
    algorithm=SHA-256,
    nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
    nc=00000001,
    cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
    qop=auth,
    response="753927fa0e85d155564e2e272a28d1802ca10daf449
        6794697cf8db5856cb6c1",
    opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

HOBA-Authentifizierung

Ein Server, der HOBA-Authentifizierung unterstützt, kann einen WWW-Authenticate-Antwort-Header haben, der wie folgt aussieht:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: HOBA max-age="180", challenge="16:MTEyMzEyMzEyMw==1:028:https://www.example.com:8080:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz"

Die zu signierende Blob-Challenge wird aus diesen Teilen erstellt: www.example.com mit Port 8080, der Nonce ist 1123123123, der Algorithmus für die Signierung ist RSA-SHA256, der Schlüsselbezeichner ist 123 und schließlich lautet die Challenge 68147c97-461b-4310-be9b-4c707237ab53.

Ein Client würde diesen Header empfangen, die Challenge extrahieren, sie mit seinem privaten Schlüssel signieren, der in unserem Beispiel dem Schlüsselbezeichner 123 entspricht, wobei RSA-SHA256 verwendet wird, und das Ergebnis dann im Authorization-Header als durch Punkte getrennte Schlüssel-ID, Challenge, Nonce und Signatur senden.

Authorization: 123.16:MTEyMzEyMzEyMw==1:028:https://www.example.com:8080:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz.1123123123.<signature-of-challenge>

Spezifikationen

Browser-Kompatibilität

Siehe auch

• HTTP-Authentifizierung
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401, 403, 407