2. Rahmenwerk für Zugriffsauthentifizierung (Access Authentication Framework)
2.1 Challenge und Antwort (Challenge and Response)
HTTP bietet ein einfaches Challenge-Response-Authentifizierungsrahmenwerk, das von einem Server verwendet werden kann, um eine Client-Anfrage mit einer Challenge zu versehen, und von einem Client, um Authentifizierungsinformationen bereitzustellen. Es verwendet ein Token ohne Beachtung der Groß- und Kleinschreibung, um das Authentifizierungsschema zu identifizieren, gefolgt von zusätzlichen Informationen, die erforderlich sind, um die Authentifizierung über dieses Schema zu erreichen. Letztere können entweder eine kommagetrennte Liste von Parametern oder eine einzelne Zeichenfolge sein, die base64-kodierte Informationen aufnehmen kann.
Authentifizierungsparameter sind name=value-Paare, wobei das name-Token ohne Beachtung der Groß- und Kleinschreibung verglichen wird und jeder Parametername nur einmal pro Challenge vorkommen darf (MUST).
auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string )
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
Die token68-Syntax erlaubt die 66 unreservierten URI-Zeichen ([RFC3986]) sowie einige weitere, sodass sie eine base64-, base64url- (URL- und dateinamensicheres Alphabet), base32- oder base16-(Hex-)Kodierung mit oder ohne Padding, aber ohne Leerraum aufnehmen kann ([RFC4648]).
Eine 401-(Unauthorized-)Antwortnachricht wird von einem Ursprungsserver verwendet, um die Autorisierung eines Benutzeragenten mit einer Challenge zu versehen, und enthält ein Header-Feld WWW-Authenticate mit mindestens einer Challenge, die auf die angeforderte Ressource anwendbar ist.
Eine 407-(Proxy Authentication Required-)Antwortnachricht wird von einem Proxy verwendet, um die Autorisierung eines Clients mit einer Challenge zu versehen, und enthält ein Header-Feld Proxy-Authenticate mit mindestens einer Challenge, die für die angeforderte Ressource auf den Proxy anwendbar ist.
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Hinweis: Vielen Clients gelingt es nicht, eine Challenge zu analysieren, die ein unbekanntes Schema enthält. Ein Ausweg aus diesem Problem besteht darin, gut unterstützte Schemata (wie "basic") zuerst aufzulisten.
Ein Benutzeragent, der sich gegenüber einem Ursprungsserver authentifizieren möchte — üblicherweise, aber nicht notwendigerweise, nachdem er eine 401 (Unauthorized) empfangen hat —, kann dies tun, indem er ein Header-Feld Authorization in die Anfrage aufnimmt.
Ein Client, der sich gegenüber einem Proxy authentifizieren möchte — üblicherweise, aber nicht notwendigerweise, nachdem er eine 407 (Proxy Authentication Required) empfangen hat —, kann dies tun, indem er ein Header-Feld Proxy-Authorization in die Anfrage aufnimmt.
Sowohl der Wert des Feldes Authorization als auch der Wert des Feldes Proxy-Authorization enthalten die Anmeldedaten des Clients für den Realm der angeforderten Ressource, basierend auf einer Challenge, die in einer Antwort (möglicherweise zu einem früheren Zeitpunkt) empfangen wurde. Beim Erzeugen dieser Werte sollte der Benutzeragent die Challenge mit dem auswählen, was er für das sicherste ihm bekannte auth-scheme hält, und die Anmeldedaten gegebenenfalls vom Benutzer einholen. Die Übertragung von Anmeldedaten innerhalb von Header-Feldwerten bringt erhebliche Sicherheitsüberlegungen hinsichtlich der Vertraulichkeit der zugrunde liegenden Verbindung mit sich, wie in Abschnitt 6.1 beschrieben.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Beim Empfang einer Anfrage nach einer geschützten Ressource, die Anmeldedaten weglässt, ungültige Anmeldedaten (z. B. ein falsches Passwort) oder teilweise Anmeldedaten (z. B. wenn das Authentifizierungsschema mehr als einen Umlauf erfordert) enthält, sollte ein Ursprungsserver eine 401-(Unauthorized-)Antwort senden, die ein Header-Feld WWW-Authenticate mit mindestens einer (möglicherweise neuen) Challenge enthält, die auf die angeforderte Ressource anwendbar ist (SHOULD).
Ebenso sollte ein Proxy, der eine Authentifizierung verlangt, beim Empfang einer Anfrage, die Proxy-Anmeldedaten weglässt oder ungültige oder teilweise Proxy-Anmeldedaten enthält, eine 407-(Proxy Authentication Required-)Antwort erzeugen, die ein Header-Feld Proxy-Authenticate mit mindestens einer (möglicherweise neuen) Challenge enthält, die auf den Proxy anwendbar ist (SHOULD).
Ein Server, der gültige Anmeldedaten empfängt, die nicht ausreichen, um Zugang zu erhalten, sollte mit dem Statuscode 403 (Forbidden) antworten (Abschnitt 6.5.3 von [RFC7231]).
HTTP beschränkt Anwendungen nicht auf dieses einfache Challenge-Response-Rahmenwerk für die Zugriffsauthentifizierung. Es können zusätzliche Mechanismen verwendet werden, etwa Authentifizierung auf der Transportschicht oder über Nachrichtenkapselung, sowie zusätzliche Header-Felder, die Authentifizierungsinformationen angeben. Solche zusätzlichen Mechanismen werden von dieser Spezifikation jedoch nicht definiert.
2.2 Schutzbereich (Realm) (Protection Space (Realm))
Der Authentifizierungsparameter "realm" ist für die Verwendung durch Authentifizierungsschemata reserviert, die einen Schutzumfang angeben möchten.
Ein Schutzbereich wird durch die kanonische Wurzel-URI (die scheme- und authority-Komponenten der effektiven Anfrage-URI; siehe Abschnitt 5.5 von [RFC7230]) des Servers, auf den zugegriffen wird, in Kombination mit dem realm-Wert, falls vorhanden, definiert. Diese Realms erlauben es, die geschützten Ressourcen auf einem Server in eine Menge von Schutzbereichen aufzuteilen, von denen jeder sein eigenes Authentifizierungsschema und/oder seine eigene Autorisierungsdatenbank hat. Der realm-Wert ist eine Zeichenkette, die im Allgemeinen vom Ursprungsserver zugewiesen wird und zusätzliche, für das Authentifizierungsschema spezifische Semantik haben kann. Beachten Sie, dass eine Antwort mehrere Challenges mit demselben auth-scheme, aber unterschiedlichen Realms haben kann.
Der Schutzbereich bestimmt die Domäne, über die Anmeldedaten automatisch angewendet werden können. Wenn eine frühere Anfrage autorisiert wurde, kann der Benutzeragent dieselben Anmeldedaten für alle anderen Anfragen innerhalb dieses Schutzbereichs für einen Zeitraum wiederverwenden, der durch das Authentifizierungsschema, die Parameter und/oder Benutzereinstellungen (etwa ein konfigurierbarer Inaktivitäts-Timeout) bestimmt wird (MAY). Sofern das Authentifizierungsschema dies nicht ausdrücklich erlaubt, kann sich ein einzelner Schutzbereich nicht über den Bereich seines Servers hinaus erstrecken.
Aus historischen Gründen darf ein Sender nur die quoted-string-Syntax erzeugen (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.