WWW-Authenticate header

WWW-Authenticate: <challenge>

Wobei ein <challenge> aus einem <auth-scheme> besteht, 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. Zum Beispiel erfordert die Basic-Authentifizierung ein <realm> und erlaubt die optionale Verwendung des charset Schlüssels, unterstützt aber kein token68:

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

Mehrere Herausforderungen können in einer durch Kommata getrennten Liste gesendet werden

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

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

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

<auth-scheme>

Ein nicht casesensitives Token, das das verwendete Authentifizierungsschema angibt. Einige der gängigeren Typen sind Basic, Digest, Negotiate und AWS4-HMAC-SHA256. IANA führt eine Liste von Authentifizierungsschemata, aber es gibt auch andere Schemata, die von Host-Diensten angeboten werden.

<auth-param> Optional

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

<realm> Optional

Der String realm gefolgt von = und einem umschlossenen String, der einen geschützten Bereich beschreibt, z.B. realm="Testumgebung". Ein Realm ermöglicht es einem Server, die Bereiche zu unterteilen, die er schützt (falls unterstützt durch ein Schema, das eine solche Unterteilung erlaubt). Manche Clients zeigen diesen Wert dem Benutzer an, um ihn darüber zu informieren, welche speziellen Anmeldedaten erforderlich sind – obwohl die meisten Browser dies aus Phishing-Schutzgründen nicht mehr tun. Der einzige verlässlich unterstützte Zeichensatz für diesen Wert ist us-ascii. Wenn kein Realm angegeben ist, zeigen Clients oft einen formatierten Hostnamen an.

<token68> Optional

Ein Token, das für einige Schemas nützlich sein kann. Das Token erlaubt die 66 unreservierten URI-Zeichen plus einige andere. Es kann eine base64, base64url, base32 oder base16 (hex) Codierung enthalten, mit oder ohne Padding, jedoch ohne Leerzeichen. Die Alternative token68 zu Authentifizierungsparameterlisten wird für die Konsistenz mit älteren Authentifizierungsschemata unterstützt.

Im Allgemeinen müssen Sie die relevanten Spezifikationen für die Authentifizierungsparameter prüfen, die für jedes <auth-scheme> benötigt werden. Die folgenden Abschnitte beschreiben Token- und Authentifizierungsparameter für einige gängige Authentifizierungsschemata.

<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 Kodierschema des Servers beim Einreichen eines Benutzernamens und Passworts mit. Der einzige erlaubte Wert ist der nicht-case-sensitive String UTF-8. Dies bezieht sich nicht auf die Kodierung des Realm-Strings.

<realm> Optional

Ein <realm> wie oben beschrieben, welcher den zu verwendenden Benutzernamen/das Passwort angibt. Sollte mindestens den Hostnamen enthalten, könnte aber die Benutzer oder Gruppen angeben, die Zugriff haben.

domain Optional

Eine durch Leerzeichen getrennte Liste von URI-Präfixen, die alle Orte definieren, an denen die Authentifizierungsinformationen verwendet werden können. Wenn dieser Schlüssel nicht angegeben ist, können die Authentifizierungsinformationen überall im Webroot verwendet werden.

nonce

Ein vom Server spezifizierter String, den der Server verwenden kann, um die Lebensdauer zu kontrollieren, in der bestimmte Anmeldedaten als gültig betrachtet werden. Dieser muss jedes Mal, wenn eine 401-Antwort erfolgt, einzigartig generiert werden und kann öfter regeneriert werden (z.B. eine Digest nur einmal zulassen). Die Spezifikation enthält Hinweise auf mögliche Algorithmen zur Erstellung dieses Wertes. Der Nonce-Wert ist für den Client undurchsichtig.

opaque

Ein vom Server angegebener String, der unverändert in der Authorization zurückgegeben werden sollte. Dies ist für den Client ebenfalls undurchsichtig. Der Server wird empfohlen, Base64 oder hexadezimale Daten einzuschließen.

stale Optional

Eine nicht casesensitive Kennzeichnung, die anzeigt, dass die vorherige Anfrage vom Client abgelehnt wurde, weil der verwendete nonce zu alt (veraltet) ist. Wenn dies true ist, kann die Anfrage mit demselben Benutzernamen/Passwort erneut verschlüsselt mit dem neuen nonce gesendet werden. Wenn es einen anderen Wert hat, sind der Benutzername/das Passwort ungültig und müssen vom Benutzer erneut angefordert werden.

algorithm Optional

Ein String, der den Algorithmus angibt, der zur Erstellung eines Digest verwendet wird. Gültige Non-Session-Werte sind: MD5 (Standard, wenn algorithm nicht angegeben), SHA-256, SHA-512. Gültige Session-Werte sind: MD5-sess, SHA-256-sess, SHA-512-sess.

qop

Ein String, der die Qualität der vom Server unterstützten Schutzmaßnahmen angibt. Dies muss angegeben werden, unbekannte Optionen müssen ignoriert werden.

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

charset="UTF-8" Optional

Teilt dem Client das bevorzugte Kodierschema des Servers mit beim Einreichen eines Benutzernamens und Passworts. Der einzige erlaubte Wert ist der nicht-case-sensitive String "UTF-8".

userhash Optional

Ein Server kann "true" angeben, um zu zeigen, dass er die Hashbildung von Benutzernamen unterstützt (Standard ist "false")

<challenge>

Ein Satz von Paaren im Format <len>:<value>, die zusammengefügt werden, um dem Client gegeben zu werden. Die Herausforderung besteht aus einem Nonce, einem Algorithmus, einem Ursprung, einem Realm, einem Schlüsselkennzeichen und der Herausforderung.

<max-age>

Die Anzahl der Sekunden ab dem Zeitpunkt, zu dem die HTTP-Anwort gesendet wird, für die Antworten auf diese Herausforderung akzeptiert werden können.

<realm> Optional

Wie oben im Abschnitt Direktiven beschrieben.

Mehrere Herausforderungen können in einem einzigen Antwortheader angegeben werden:

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

Mehrere Herausforderungen können in separaten WWW-Authenticate Headers in derselben Antwort gesendet werden:

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

Ein Server, der nur Basic-Authentifizierung unterstützt, könnte einen WWW-Authenticate Antwort-Header haben, der folgendermaßen aussieht:

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

Ein Benutzeragent, der diesen Header empfängt, würde zuerst den Benutzer nach seinem Benutzernamen und Passwort fragen und dann die Ressource erneut anfordern mit den kodierten Anmeldedaten im Authorization Header. Der Authorization Header könnte so aussehen:

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

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

Der Client versucht, auf ein Dokument bei 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 lautet "Circle of Life" (beachten Sie den einzelnen Leerraum zwischen jedem der Wörter).

Beim ersten Mal, wenn der Client das Dokument anfordert, wird kein Authorization Header-Feld gesendet. Hier antwortet der Server mit einer HTTP 401-Nachricht, die eine Herausforderung für jeden von ihm unterstützten Digest-Algorithmus beinhaltet, in der Reihenfolge seiner Präferenz (SHA256 und dann MD5)

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 gewählt hat, könnte das Authorization Header-Feld wie unten gezeigt 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 gewählt hat, könnte das Authorization Header-Feld wie unten gezeigt 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"

Ein Server, der HOBA-Authentifizierung unterstützt, könnte einen WWW-Authenticate Antwort-Header haben, der folgendermaßen 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"

Der zu signierende Blob-Challenge besteht aus diesen Teilen: www.example.com mit Port 8080, der Nonce ist 1123123123, der Algorithmus zum Signieren ist RSA-SHA256, das Schlüsselkennzeichen ist 123, und schließlich die Herausforderung ist 68147c97-461b-4310-be9b-4c707237ab53.

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

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

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