1. Zugriffs-Authentifizierung (Access Authentication)
1.1 Abhängigkeit von der HTTP/1.1-Spezifikation (Reliance on the HTTP/1.1 Specification)
Diese Spezifikation ist ein Begleitdokument zur HTTP/1.1-Spezifikation [2]. Sie verwendet die erweiterte BNF von Abschnitt 2.1 dieses Dokuments und stützt sich sowohl auf die in diesem Dokument definierten Nicht-Terminale als auch auf andere Aspekte der HTTP/1.1-Spezifikation.
1.2 Zugriffs-Authentifizierungsframework (Access Authentication Framework)
HTTP bietet einen einfachen Challenge-Response-Authentifizierungsmechanismus (Challenge-Response Authentication Mechanism), den ein Server verwenden kann, um eine Client-Anfrage herauszufordern, und den der Client verwenden kann, um Authentifizierungsinformationen bereitzustellen. Es verwendet ein erweiterbares, nicht zwischen Groß- und Kleinschreibung unterscheidendes Token (Token), um das Authentifizierungsschema (Authentication Scheme) zu identifizieren, gefolgt von einer durch Kommas getrennten Liste von Attribut-Wert-Paaren, die die Parameter tragen, die zur Authentifizierung über dieses Schema erforderlich sind.
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
Der Origin-Server (Origin Server) verwendet eine 401 (Unauthorized) Antwortnachricht, um die Autorisierung des User-Agents herauszufordern. Diese Antwort muss ein WWW-Authenticate-Header-Feld enthalten, das mindestens eine Challenge enthält, die auf die angeforderte Ressource anwendbar ist. Ein Proxy (Proxy) verwendet eine 407 (Proxy Authentication Required) Antwortnachricht, um die Autorisierung des Clients herauszufordern, und muss ein Proxy-Authenticate-Header-Feld enthalten, das mindestens eine Proxy-Challenge enthält, die auf die angeforderte Ressource anwendbar ist.
challenge = auth-scheme 1*SP 1#auth-param
Hinweis: Wenn der Wert des WWW-Authenticate- oder Proxy-Authenticate-Header-Feldes mehrere Challenges enthält oder mehrere WWW-Authenticate-Header-Felder bereitgestellt werden, muss der User-Agent beim Parsen besondere Vorsicht walten lassen, da der Inhalt der Challenge selbst eine durch Kommas getrennte Liste von Authentifizierungsparametern enthalten kann.
Der Authentifizierungsparameter realm (Bereich) ist für alle Authentifizierungsschemata definiert:
realm = "realm" "=" realm-value
realm-value = quoted-string
Die Realm-Direktive (nicht zwischen Groß- und Kleinschreibung unterscheidend) ist für alle Authentifizierungsschemata erforderlich, die eine Challenge ausgeben. Der Realm-Wert (zwischen Groß- und Kleinschreibung unterscheidend) definiert in Kombination mit der kanonischen Root-URL (der absoluteURI für den Server, dessen abs_path leer ist; siehe Abschnitt 5.1.2 von [2]) des zugreifenden Servers den Schutzbereich (Protection Space). Diese Realms ermöglichen es, die geschützten Ressourcen auf einem Server in eine Reihe von Schutzbereichen zu unterteilen, von denen jeder sein eigenes Authentifizierungsschema und/oder seine eigene Autorisierungsdatenbank hat. Der Realm-Wert ist eine Zeichenkette, die im Allgemeinen vom Origin-Server zugewiesen wird und möglicherweise zusätzliche für das Authentifizierungsschema spezifische Semantik hat. Bitte beachten Sie, dass es mehrere Challenges mit demselben auth-scheme, aber unterschiedlichen Realms geben kann.
Ein User-Agent, der sich bei einem Origin-Server authentifizieren möchte -- normalerweise, aber nicht notwendigerweise, nach Erhalt eines 401 (Unauthorized) -- kann dies tun, indem er ein Authorization-Header-Feld mit der Anfrage einbezieht. Ein Client, der sich bei einem Proxy authentifizieren möchte -- normalerweise, aber nicht notwendigerweise, nach Erhalt eines 407 (Proxy Authentication Required) -- kann dies tun, indem er ein Proxy-Authorization-Header-Feld mit der Anfrage einbezieht. Sowohl der Wert des Authorization-Feldes als auch der Wert des Proxy-Authorization-Feldes bestehen aus Anmeldedaten (Credentials), die die Authentifizierungsinformationen des Clients für den Realm der angeforderten Ressource enthalten. Der User-Agent muss wählen, die Challenge mit dem stärksten auth-scheme zu verwenden, das er versteht, und Anmeldedaten vom Benutzer basierend auf dieser Challenge anfordern.
credentials = auth-scheme #auth-param
Hinweis: Viele Browser erkennen nur die Basis-Authentifizierung (Basic) und verlangen, dass sie das erste präsentierte auth-scheme ist. Server sollten die Basis-Authentifizierung nur einbeziehen, wenn sie der minimale akzeptable Standard ist.
Der Schutzbereich bestimmt die Domäne, in der Anmeldedaten automatisch angewendet werden können. Wenn eine frühere Anfrage autorisiert wurde, können dieselben Anmeldedaten für alle anderen Anfragen innerhalb dieses Schutzbereichs für einen Zeitraum wiederverwendet werden, der durch das Authentifizierungsschema, die Parameter und/oder die Benutzerpräferenz bestimmt wird. Sofern vom Authentifizierungsschema nicht anders definiert, kann sich ein einzelner Schutzbereich nicht über seinen Server hinaus erstrecken.
Wenn der Origin-Server die mit einer Anfrage gesendeten Anmeldedaten nicht akzeptieren möchte, sollte er eine 401 (Unauthorized) Antwort zurückgeben. Die Antwort muss ein WWW-Authenticate-Header-Feld enthalten, das mindestens eine (möglicherweise neue) Challenge enthält, die auf die angeforderte Ressource anwendbar ist. Wenn ein Proxy die mit einer Anfrage gesendeten Anmeldedaten nicht akzeptiert, sollte er ein 407 (Proxy Authentication Required) zurückgeben. Die Antwort muss ein Proxy-Authenticate-Header-Feld enthalten, das eine (möglicherweise neue) Challenge enthält, die auf die angeforderte Ressource anwendbar ist.
Das HTTP-Protokoll beschränkt Anwendungen nicht auf diesen einfachen Challenge-Response-Mechanismus für die Zugriffauthentifizierung. Zusätzliche Mechanismen können verwendet werden, wie z. B. Transport-Layer-Verschlüsselung oder über Nachrichtenkapselung und mit zusätzlichen Header-Feldern, die Authentifizierungsinformationen spezifizieren. Diese zusätzlichen Mechanismen werden jedoch von dieser Spezifikation nicht definiert.
Proxies müssen bezüglich der User-Agent-Authentifizierung mit dem Origin-Server vollständig transparent sein. Das heißt, sie müssen die WWW-Authenticate- und Authorization-Header unverändert weiterleiten und den Regeln in Abschnitt 14.8 von [2] folgen. Sowohl die Proxy-Authenticate- als auch die Proxy-Authorization-Header-Felder sind Hop-by-Hop-Header (Hop-by-Hop Headers) (siehe Abschnitt 13.5.1 von [2]).