11. HTTP-Authentifizierung (HTTP Authentication)

11.1. Authentifizierungsschema (Authentication Scheme)

HTTP bietet über eine erweiterbare Sammlung von Challenge-Response-Authentifizierungsschemata einen allgemeinen Rahmen für Zugriffskontrolle und Authentifizierung, den ein Server verwenden kann, um eine Client-Anfrage herauszufordern, und den ein Client verwenden kann, um Authentifizierungsinformationen bereitzustellen. Es verwendet ein Groß-/Kleinschreibung-unempfindliches Token zur Identifikation des Authentifizierungsschemas:

auth-scheme    = token

Abgesehen vom allgemeinen Rahmen spezifiziert dieses Dokument keine Authentifizierungsschemata. Neue und bestehende Authentifizierungsschemata werden unabhängig spezifiziert und sollten in der „Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" registriert werden. Zum Beispiel sind die Authentifizierungsschemata „basic" und „digest" durch [RFC7617] bzw. [RFC7616] definiert.

11.2. Authentifizierungsparameter (Authentication Parameters)

Einem Authentifizierungsschema folgen zusätzliche Informationen, die zur Durchführung der Authentifizierung über dieses Schema erforderlich sind, entweder als durch Kommas getrennte Liste von Parametern oder als einzelne Zeichenfolge, die base64-codierte Informationen enthalten kann.

token68        = 1*( ALPHA / DIGIT /
                     "-" / "." / "_" / "~" / "+" / "/" ) *"="

Die token68-Syntax erlaubt die 66 nicht reservierten URI-Zeichen ([URI]) plus einige andere, sodass sie base64-, base64url- (URL- und dateinamesicheres Alphabet), base32- oder base16- (Hexadezimal-) Kodierung mit oder ohne Auffüllung enthalten kann, jedoch ohne Leerzeichen ([RFC4648]).

Authentifizierungsparameter sind Name/Wert-Paare, wobei das Namenstoken Groß-/Kleinschreibung-unempfindlich abgeglichen wird, und jeder Parametername kann nur einmal pro Challenge auftreten.

auth-param     = token BWS "=" BWS ( token / quoted-string )

Parameterwerte können entweder als „token" oder als „quoted-string" ausgedrückt werden (Abschnitt 5.6). Authentifizierungsschema-Definitionen müssen beide Notationen für Sender und Empfänger akzeptieren, um Empfängern die Verwendung generischer Parsing-Komponenten unabhängig vom Authentifizierungsschema zu ermöglichen.

Für Abwärtskompatibilität können Authentifizierungsschema-Definitionen das Format für Sender auf eine der beiden Varianten beschränken. Dies kann wichtig sein, wenn bekannt ist, dass bereitgestellte Implementierungen fehlschlagen, wenn sie auf eines der beiden Formate stoßen.

11.3. Challenge und Response (Challenge and Response)

Ein Origin-Server verwendet die 401-Antwort (Unauthorized), um die Autorisierung eines User-Agents herauszufordern, einschließlich eines WWW-Authenticate-Header-Feldes, das mindestens eine Challenge enthält, die auf die angeforderte Ressource anwendbar ist.

Ein Proxy verwendet die 407-Antwort (Proxy Authentication Required), um die Autorisierung eines Clients herauszufordern, einschließlich eines Proxy-Authenticate-Header-Feldes, das mindestens eine Challenge enthält, die auf den Proxy für die angeforderte Ressource anwendbar ist.

challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

Hinweis: Viele Clients scheitern beim Parsen einer Challenge, die ein unbekanntes Schema enthält. Eine Umgehung für dieses Problem besteht darin, gut unterstützte Schemata (wie „basic") zuerst aufzulisten.

Ein User-Agent, der sich bei einem Origin-Server authentifizieren möchte – normalerweise, aber nicht notwendigerweise, nachdem er ein 401 (Unauthorized) erhalten hat – kann dies tun, indem er ein Authorization-Header-Feld mit der Anfrage einschließt.

Ein Client, der sich bei einem Proxy authentifizieren möchte – normalerweise, aber nicht notwendigerweise, nachdem er ein 407 (Proxy Authentication Required) erhalten hat – kann dies tun, indem er ein Proxy-Authorization-Header-Feld mit der Anfrage einschließt.

11.4. Credentials (Credentials)

Der Authorization-Feldwert und der Proxy-Authorization-Feldwert enthalten beide die Credentials des Clients für das Realm der angeforderten Ressource, basierend auf einer Challenge, die in einer Antwort empfangen wurde (möglicherweise zu einem Zeitpunkt in der Vergangenheit). Bei der Erstellung ihrer Werte sollte der User-Agent dies tun, indem er die Challenge mit dem auswählt, was er als das sicherste auth-scheme ansieht, das er versteht, und Credentials vom Benutzer angemessen erhält. Die Übertragung von Credentials in Header-Feldwerten impliziert wichtige Sicherheitsüberlegungen bezüglich der Vertraulichkeit der zugrunde liegenden Verbindung, wie in Abschnitt 17.16.1 beschrieben.

credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

Beim Empfang einer Anfrage für eine geschützte Ressource, die Credentials auslässt, ungültige Credentials enthält (z. B. ein falsches Passwort) oder teilweise Credentials (z. B. wenn das Authentifizierungsschema mehr als einen Roundtrip erfordert), sollte ein Origin-Server (SHOULD) eine 401-Antwort (Unauthorized) senden, die ein WWW-Authenticate-Header-Feld mit mindestens einer (möglicherweise neuen) Challenge enthält, die auf die angeforderte Ressource anwendbar ist.

Ebenso sollte ein Proxy, der Authentifizierung erfordert, beim Empfang einer Anfrage, die Proxy-Credentials auslässt oder ungültige oder teilweise Proxy-Credentials enthält, eine 407-Antwort (Proxy Authentication Required) generieren (SHOULD), die ein Proxy-Authenticate-Header-Feld mit mindestens einer (möglicherweise neuen) Challenge enthält, die auf den Proxy anwendbar ist.

Ein Server, der gültige, aber unzureichende Credentials für den Zugriff erhält, sollte mit dem Statuscode 403 (Forbidden) antworten (Abschnitt 15.5.4).

HTTP beschränkt Anwendungen nicht auf diesen einfachen Challenge-Response-Rahmen für die Zugriffauthentifizierung. Zusätzliche Mechanismen können verwendet werden, wie Authentifizierung auf Transportebene oder über Nachrichtenkapselung, und mit zusätzlichen Header-Feldern, die Authentifizierungsinformationen spezifizieren. Solche zusätzlichen Mechanismen sind jedoch nicht durch diese Spezifikation definiert.

Beachten Sie, dass verschiedene benutzerdefinierte Benutzerauthentifizierungsmechanismen unter Verwendung der in [COOKIE] definierten Set-Cookie- und Cookie-Header-Felder implementiert werden, um authentifizierungsbezogene Token zu übertragen.

11.5. Einrichtung eines Schutzraums (Realm) (Establishing a Protection Space (Realm))

Der „realm"-Authentifizierungsparameter ist für die Verwendung durch Authentifizierungsschemata reserviert, die einen Schutzumfang angeben möchten.

Ein Schutzraum wird durch den Origin (siehe Abschnitt 4.3.1) des Servers, auf den zugegriffen wird, in Kombination mit dem Realm-Wert, falls vorhanden, definiert. Diese Realms ermöglichen es, die geschützten Ressourcen auf einem Server in eine Reihe von Schutzräumen zu partitionieren, von denen jeder sein eigenes Authentifizierungsschema und/oder seine eigene Autorisierungsdatenbank hat. Der Realm-Wert ist eine Zeichenfolge, die normalerweise vom Origin-Server zugewiesen wird und zusätzliche, authentifizierungsschema-spezifische Semantik haben kann. Beachten Sie, dass eine Antwort mehrere Challenges mit demselben auth-scheme, aber unterschiedlichen Realms haben kann.

Der Schutzraum bestimmt die Domäne, über die Credentials automatisch angewendet werden können. Wenn eine frühere Anfrage autorisiert wurde, kann der User-Agent (MAY) dieselben Credentials für alle anderen Anfragen innerhalb dieses Schutzraums über einen Zeitraum wiederverwenden, der durch das Authentifizierungsschema, Parameter und/oder Benutzerpräferenzen bestimmt wird (wie ein konfigurierbares Inaktivitäts-Timeout).

Der Umfang eines Schutzraums und damit, wo ein Client Credentials automatisch anwenden könnte, ist für den Client nicht unbedingt bekannt, es sei denn, es gibt zusätzliche Informationen. Authentifizierungsschemata können Parameter definieren, die den Umfang eines Schutzraums beschreiben. Ein Schutzraum kann sich nicht über den Gültigkeitsbereich seines Servers hinaus erstrecken, es sei denn, das Authentifizierungsschema erlaubt es ausdrücklich.

Aus historischen Gründen MUSS ein Sender nur die quoted-string-Syntax generieren (MUST). Empfänger müssen möglicherweise sowohl die token- als auch die quoted-string-Syntax unterstützen, um maximale Interoperabilität mit bestehenden Clients zu erreichen, die beide Notationen seit langem akzeptieren.

11.6. Authentifizierung von Benutzern bei Origin-Servern (Authenticating Users to Origin Servers)

11.6.1. WWW-Authenticate

Das „WWW-Authenticate"-Antwort-Header-Feld gibt das oder die Authentifizierungsschema(ta) und Parameter an, die auf die Zielressource anwendbar sind.

WWW-Authenticate = #challenge

Ein Server, der eine 401-Antwort (Unauthorized) generiert, MUSS ein WWW-Authenticate-Header-Feld senden, das mindestens eine Challenge enthält (MUST). Ein Server KANN ein WWW-Authenticate-Header-Feld in anderen Antwortnachrichten generieren (MAY), um anzuzeigen, dass die Bereitstellung von Credentials (oder unterschiedlichen Credentials) die Antwort beeinflussen könnte.

Ein Proxy, der eine Antwort weiterleitet, DARF die WWW-Authenticate-Header-Felder in dieser Antwort NICHT ändern (MUST NOT).

User-Agents wird empfohlen, beim Parsen des Feldwerts besondere Vorsicht walten zu lassen, da er mehr als eine Challenge enthalten kann und jede Challenge eine durch Kommas getrennte Liste von Authentifizierungsparametern enthalten kann. Darüber hinaus kann das Header-Feld selbst mehrmals auftreten.

Zum Beispiel:

WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
                 type=1, title="Login to \"apps\""

Dieses Header-Feld enthält zwei Challenges, eine für das „Basic"-Schema mit einem Realm-Wert von „simple" und eine andere für das „Newauth"-Schema mit einem Realm-Wert von „apps". Es enthält auch zwei zusätzliche Parameter, „type" und „title".

Einige User-Agents erkennen diese Form jedoch nicht. Daher kann das Senden eines WWW-Authenticate-Feldwerts mit mehreren Mitgliedern in derselben Feldzeile möglicherweise nicht interoperabel sein.

Hinweis: Die Challenge-Grammatikproduktion verwendet ebenfalls die Listensyntax. Daher kann eine Folge von Komma, Leerzeichen und Komma als auf die vorhergehende Challenge anwendbar oder als leerer Eintrag in der Challenge-Liste betrachtet werden. In der Praxis beeinflusst diese Mehrdeutigkeit die Semantik des Header-Feldwerts nicht und ist daher harmlos.

11.6.2. Authorization

Das „Authorization"-Header-Feld ermöglicht es einem User-Agent, sich bei einem Origin-Server zu authentifizieren – normalerweise, aber nicht notwendigerweise, nachdem er eine 401-Antwort (Unauthorized) erhalten hat. Sein Wert besteht aus Credentials, die die Authentifizierungsinformationen des User-Agents für das Realm der angeforderten Ressource enthalten.

Authorization = credentials

Wenn eine Anfrage authentifiziert ist und ein Realm angegeben ist, wird angenommen, dass dieselben Credentials für alle anderen Anfragen innerhalb dieses Realms gültig sind (vorausgesetzt, das Authentifizierungsschema selbst erfordert nicht anderweitig, wie Credentials, die sich nach einem Challenge-Wert ändern, oder die Verwendung von synchronisierten Uhren).

Ein Proxy, der eine Anfrage weiterleitet, DARF die Authorization-Header-Felder in dieser Anfrage NICHT ändern (MUST NOT). Siehe Abschnitt 3.5 von [CACHING] für Details und Anforderungen zur Behandlung des Authorization-Header-Feldes durch HTTP-Caches.

11.6.3. Authentication-Info

HTTP-Authentifizierungsschemata können das „Authentication-Info"-Antwortfeld verwenden, um Informationen zu übermitteln, nachdem die Authentifizierungs-Credentials des Clients akzeptiert wurden. Diese Informationen können eine abschließende Nachricht vom Server enthalten (z. B. können sie die Server-Authentifizierung enthalten).

Der Feldwert ist eine Liste von Parametern (Name/Wert-Paaren), unter Verwendung der in Abschnitt 11.3 definierten „auth-param"-Syntax. Diese Spezifikation beschreibt nur das allgemeine Format; Authentifizierungsschemata, die Authentication-Info verwenden, definieren die einzelnen Parameter. Zum Beispiel definiert das „Digest"-Authentifizierungsschema mehrere Parameter in Abschnitt 3.5 von [RFC7616].

Authentication-Info = #auth-param

Das Authentication-Info-Feld kann in jeder HTTP-Antwort verwendet werden, unabhängig von der Anfragemethode und dem Statuscode. Seine Semantik wird durch das Authentifizierungsschema definiert, das durch das Authorization-Header-Feld (Abschnitt 11.6.2) der entsprechenden Anfrage angegeben wird.

Ein Proxy, der eine Antwort weiterleitet, darf den Feldwert in keiner Weise ändern.

Authentication-Info kann als Trailer-Feld (Abschnitt 6.5) gesendet werden, sobald klar wird, dass der Nachrichtentext gesendet wird (z. B. die Authentifizierung nicht abgelehnt wird), wenn das Authentifizierungsschema dies ausdrücklich erlaubt.

11.7. Authentifizierung von Clients bei Proxys (Authenticating Clients to Proxies)

11.7.1. Proxy-Authenticate

Das „Proxy-Authenticate"-Header-Feld besteht aus mindestens einer Challenge, die das oder die Authentifizierungsschema(ta) und Parameter angibt, die auf den Proxy für diese Anfrage anwendbar sind. Ein Proxy MUSS in jeder 407-Antwort (Proxy Authentication Required), die er generiert, mindestens ein Proxy-Authenticate-Header-Feld senden (MUST).

Proxy-Authenticate = #challenge

Im Gegensatz zu WWW-Authenticate gilt das Proxy-Authenticate-Header-Feld nur für den nächsten ausgehenden Client in der Antwortkette. Dies liegt daran, dass nur der Client, der einen bestimmten Proxy gewählt hat, wahrscheinlich über die für die Authentifizierung erforderlichen Credentials verfügt. Wenn jedoch mehrere Proxys innerhalb derselben Verwaltungsdomäne verwendet werden, wie Büro- und regionale Caching-Proxys in einem großen Unternehmensnetzwerk, ist es üblich, dass Credentials vom User-Agent generiert und durch die Hierarchie weitergegeben werden, bis sie verbraucht werden. Daher scheint es in einer solchen Konfiguration, als würde Proxy-Authenticate weitergeleitet, da jeder Proxy denselben Challenge-Satz senden wird.

Beachten Sie, dass die Parsing-Überlegungen für WWW-Authenticate auch auf dieses Header-Feld zutreffen; siehe Abschnitt 11.6.1 für Details.

11.7.2. Proxy-Authorization

Das „Proxy-Authorization"-Header-Feld ermöglicht es dem Client, sich (oder seinen Benutzer) bei einem Proxy zu identifizieren, der Authentifizierung erfordert. Sein Wert besteht aus Credentials, die die Authentifizierungsinformationen des Clients für den Proxy und/oder das Realm der angeforderten Ressource enthalten.

Proxy-Authorization = credentials

Im Gegensatz zu Authorization gilt das Proxy-Authorization-Header-Feld nur für den nächsten eingehenden Proxy, der die Authentifizierung mit dem Proxy-Authenticate-Header-Feld angefordert hat. Wenn mehrere Proxys in einer Kette verwendet werden, wird das Proxy-Authorization-Header-Feld vom ersten eingehenden Proxy verbraucht, der erwartete, Credentials zu erhalten. Ein Proxy KANN die Credentials von der Client-Anfrage an den nächsten Proxy weiterleiten (MAY), wenn dies der Mechanismus ist, durch den Proxys zusammenarbeiten, um eine bestimmte Anfrage zu authentifizieren.

11.7.3. Proxy-Authentication-Info

Das „Proxy-Authentication-Info"-Antwort-Header-Feld entspricht Authentication-Info, außer dass es auf die Proxy-Authentifizierung (Abschnitt 11.3) anwendbar ist und seine Semantik durch das Authentifizierungsschema definiert wird, das durch das Proxy-Authorization-Header-Feld (Abschnitt 11.7.2) der entsprechenden Anfrage angegeben wird:

Proxy-Authentication-Info = #auth-param

Im Gegensatz zu Authentication-Info gilt das Proxy-Authentication-Info-Header-Feld jedoch nur für den nächsten ausgehenden Client in der Antwortkette. Dies liegt daran, dass nur der Client, der einen bestimmten Proxy gewählt hat, wahrscheinlich über die für die Authentifizierung erforderlichen Credentials verfügt. Wenn jedoch mehrere Proxys innerhalb derselben Verwaltungsdomäne verwendet werden, wie Büro- und regionale Caching-Proxys in einem großen Unternehmensnetzwerk, ist es üblich, dass Credentials vom User-Agent generiert und durch die Hierarchie weitergegeben werden, bis sie verbraucht werden. Daher scheint es in einer solchen Konfiguration, als würde Proxy-Authentication-Info weitergeleitet, da jeder Proxy denselben Feldwert senden wird.

Proxy-Authentication-Info kann als Trailer-Feld (Abschnitt 6.5) gesendet werden, sobald klar wird, dass der Nachrichtentext gesendet wird, wenn das Authentifizierungsschema dies ausdrücklich erlaubt.