2. Das 'Basic' Authentifizierungsschema
Das Basic-Authentifizierungsschema basiert auf dem Modell, dass der Client sich mit einer Benutzer-ID und einem Passwort für jeden Schutzraum ("realm") authentifizieren muss. Der Realm-Wert ist eine Freiform-Zeichenkette, die nur auf Gleichheit mit anderen Realms auf diesem Server verglichen werden kann. Der Server wird die Anfrage nur bearbeiten, wenn er die Benutzer-ID und das Passwort für den Schutzraum validieren kann, der auf die angeforderte Ressource angewendet wird.
Das Basic-Authentifizierungsschema nutzt den Authentifizierungs-Framework wie folgt.
In Challenges:
- Der Schemaname ist "Basic".
- Der Authentifizierungsparameter 'realm' ist ERFORDERLICH (REQUIRED) ([RFC7235], Abschnitt 2.2).
- Der Authentifizierungsparameter 'charset' ist OPTIONAL ([RFC7235], siehe Abschnitt 2.1).
- Keine weiteren Authentifizierungsparameter sind definiert -- unbekannte Parameter MÜSSEN von Empfängern ignoriert werden, und neue Parameter können nur durch Überarbeitung dieser Spezifikation definiert werden.
Siehe auch Abschnitt 4.1 von [RFC7235], der die Komplexität der korrekten Analyse von Challenges diskutiert.
Beachten Sie, dass sowohl Schema- als auch Parameternamen ohne Berücksichtigung der Groß-/Kleinschreibung abgeglichen werden.
Für Anmeldeinformationen wird die "token68"-Syntax verwendet, die in Abschnitt 2.1 von [RFC7235] definiert ist. Der Wert wird basierend auf Benutzer-ID und Passwort wie unten definiert berechnet.
Nach Erhalt einer Anfrage für einen URI innerhalb des Schutzraums, der keine Anmeldeinformationen enthält, kann der Server mit einer Challenge unter Verwendung des 401 (Unauthorized) Statuscodes ([RFC7235], Abschnitt 3.1) und des WWW-Authenticate Header-Felds ([RFC7235], Abschnitt 4.1) antworten.
Zum Beispiel:
HTTP/1.1 401 Unauthorized
Date: Mon, 04 Feb 2014 16:50:53 GMT
WWW-Authenticate: Basic realm="WallyWorld"
wobei "WallyWorld" die vom Server zugewiesene Zeichenkette zur Identifizierung des Schutzraums ist.
Ein Proxy kann mit einer ähnlichen Challenge unter Verwendung des 407 (Proxy Authentication Required) Statuscodes ([RFC7235], Abschnitt 3.2) und des Proxy-Authenticate Header-Felds ([RFC7235], Abschnitt 4.3) antworten.
Um eine Autorisierung zu erhalten, führt der Client folgende Schritte durch:
- erhält die Benutzer-ID und das Passwort vom Benutzer,
- konstruiert den user-pass durch Verkettung der Benutzer-ID, eines einzelnen Doppelpunkt-Zeichens (":") und des Passworts,
- kodiert den user-pass in eine Oktett-Sequenz (siehe unten für eine Diskussion über Zeichenkodierungsschemata),
- und erhält die basic-credentials durch Kodierung dieser Oktett-Sequenz mit Base64 ([RFC4648], Abschnitt 4) in eine Sequenz von US-ASCII-Zeichen ([RFC0020]).
Die ursprüngliche Definition dieses Authentifizierungsschemas hat nicht spezifiziert, welches Zeichenkodierungsschema verwendet wird, um den user-pass in eine Oktett-Sequenz zu konvertieren. In der Praxis haben die meisten Implementierungen entweder eine lokale Kodierung wie ISO-8859-1 ([ISO-8859-1]) oder UTF-8 ([RFC3629]) gewählt. Aus Gründen der Rückwärtskompatibilität lässt diese Spezifikation die Standard-Kodierung weiterhin undefiniert, solange sie mit US-ASCII kompatibel ist (wobei jedes US-ASCII-Zeichen auf ein einzelnes Oktett abgebildet wird, das dem US-ASCII-Zeichencode entspricht).
Die Benutzer-ID und das Passwort DÜRFEN KEINE Steuerzeichen enthalten (siehe "CTL" in Anhang B.1 von [RFC5234]).
Darüber hinaus ist eine Benutzer-ID, die ein Doppelpunkt-Zeichen enthält, ungültig, da der erste Doppelpunkt in einer user-pass-Zeichenkette Benutzer-ID und Passwort voneinander trennt; Text nach dem ersten Doppelpunkt ist Teil des Passworts. Benutzer-IDs, die Doppelpunkte enthalten, können nicht in user-pass-Zeichenketten kodiert werden.
Beachten Sie, dass viele Benutzeragenten user-pass-Zeichenketten erstellen, ohne zu prüfen, ob von Benutzern bereitgestellte Benutzer-IDs keine Doppelpunkte enthalten; Empfänger werden dann einen Teil der Benutzernamen-Eingabe als Teil des Passworts behandeln.
Wenn der Benutzeragent die Benutzer-ID "Aladdin" und das Passwort "open sesame" senden möchte, würde er das folgende Header-Feld verwenden:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
2.1. Der 'charset' auth-param
In Challenges können Server den 'charset' Authentifizierungsparameter verwenden, um das Zeichenkodierungsschema anzugeben, das sie vom Benutzeragenten erwarten, wenn dieser "user-pass" (eine Oktett-Sequenz) generiert. Diese Information ist rein beratend.
Der einzige erlaubte Wert ist "UTF-8"; er muss ohne Berücksichtigung der Groß-/Kleinschreibung abgeglichen werden (siehe [RFC2978], Abschnitt 2.3). Er zeigt an, dass der Server erwartet, dass Zeichendaten in die Unicode-Normalisierungsform C ("NFC"; siehe Abschnitt 3 von [RFC5198]) konvertiert und mit dem UTF-8-Zeichenkodierungsschema ([RFC3629]) in Oktette kodiert werden.
Für die Benutzer-ID MÜSSEN Empfänger alle im "UsernameCasePreserved"-Profil definierten Zeichen unterstützen, das in Abschnitt 3.3 von [RFC7613] definiert ist, mit Ausnahme des Doppelpunkt-Zeichens (":").
Für das Passwort MÜSSEN Empfänger alle im "OpaqueString"-Profil definierten Zeichen unterstützen, das in Abschnitt 4.2 von [RFC7613] definiert ist.
Andere Werte sind für zukünftige Verwendung reserviert.
Hinweis: Das 'charset' ist nur in Challenges definiert, da die Basic-Authentifizierung ein einzelnes Token für Anmeldeinformationen ('token68'-Syntax) verwendet; daher ist die Anmeldeinformationen-Syntax nicht erweiterbar.
Hinweis: Der Name 'charset' wurde aus Konsistenzgründen mit Abschnitt 2.1.1 von [RFC2831] gewählt. Ein besserer Name wäre 'accept-charset' gewesen, da es nicht um die Nachricht geht, in der er erscheint, sondern um die Erwartung des Servers.
Im folgenden Beispiel fordert der Server eine Authentifizierung im "foo"-Realm an, unter Verwendung der Basic-Authentifizierung, mit einer Präferenz für das UTF-8-Zeichenkodierungsschema:
WWW-Authenticate: Basic realm="foo", charset="UTF-8"
Beachten Sie, dass der Parameterwert entweder ein Token oder eine Zeichenkette in Anführungszeichen sein kann; in diesem Fall hat sich der Server für die Notation mit Anführungszeichen entschieden.
Der Name des Benutzers ist "test", und das Passwort ist die Zeichenkette "123" gefolgt vom Unicode-Zeichen U+00A3 (POUND SIGN). Bei Verwendung des UTF-8-Zeichenkodierungsschemas wird der user-pass zu:
't' 'e' 's' 't' ':' '1' '2' '3' pound
74 65 73 74 3A 31 32 33 C2 A3
Die Kodierung dieser Oktett-Sequenz in Base64 ([RFC4648], Abschnitt 4) ergibt:
dGVzdDoxMjPCow==
Daher wäre das Authorization Header-Feld:
Authorization: Basic dGVzdDoxMjPCow==
Oder für Proxy-Authentifizierung:
Proxy-Authorization: Basic dGVzdDoxMjPCow==
2.2. Wiederverwendung von Anmeldeinformationen
Gegeben den absoluten URI ([RFC3986], Abschnitt 4.3) einer authentifizierten Anfrage wird der Authentifizierungsbereich dieser Anfrage durch Entfernen aller Zeichen nach dem letzten Schrägstrich ("/") der Pfadkomponente ("hier_part"; siehe [RFC3986], Abschnitt 3) erhalten. Ein Client SOLLTE annehmen, dass Ressourcen, die durch URIs mit einer Präfix-Übereinstimmung des Authentifizierungsbereichs identifiziert werden, sich ebenfalls im Schutzraum befinden, der durch den Realm-Wert dieser authentifizierten Anfrage angegeben ist.
Ein Client KANN das entsprechende Authorization Header-Feld mit Anfragen für Ressourcen in diesem Raum präventiv senden, ohne eine weitere Challenge vom Server zu erhalten. Ebenso KANN ein Client beim Senden einer Anfrage an einen Proxy eine Benutzer-ID und ein Passwort im Proxy-Authorization Header-Feld wiederverwenden, ohne eine weitere Challenge vom Proxy-Server zu erhalten.
Zum Beispiel, gegeben eine authentifizierte Anfrage an:
http://example.com/docs/index.html
könnten Anfragen an die folgenden URIs die bekannten Anmeldeinformationen verwenden:
http://example.com/docs/
http://example.com/docs/test.doc
http://example.com/docs/?page=1
während die URIs
http://example.com/other/
https://example.com/docs/
als außerhalb des Authentifizierungsbereichs liegend betrachtet würden.
Beachten Sie, dass ein URI Teil mehrerer Authentifizierungsbereiche sein kann (wie "http://example.com/" und "http://example.com/docs/"). Diese Spezifikation definiert nicht, welcher davon mit höherer Priorität behandelt werden sollte.