2. Schéma d'authentification de base (Basic Authentication Scheme)

Le schéma d'authentification « basic » est basé sur le modèle selon lequel le client doit s'authentifier avec un identifiant utilisateur et un mot de passe pour chaque domaine (Realm). La valeur du realm devrait être considérée comme une chaîne opaque qui ne peut être comparée qu'à l'égalité avec d'autres realms sur ce serveur. Le serveur ne traitera la requête que s'il peut valider l'identifiant utilisateur et le mot de passe pour l'espace de protection du Request-URI. Il n'y a pas de paramètres d'authentification optionnels.

Pour l'authentification de base (Basic), le cadre ci-dessus est utilisé comme suit :

challenge   = "Basic" realm
credentials = "Basic" basic-credentials

Lors de la réception d'une requête non autorisée pour un URI dans l'espace de protection, le serveur d'origine peut répondre avec un défi comme suit :

WWW-Authenticate: Basic realm="WallyWorld"

où « WallyWorld » est la chaîne attribuée par le serveur pour identifier l'espace de protection du Request-URI. Un proxy peut répondre avec le même défi en utilisant le champ d'en-tête Proxy-Authenticate.

Pour recevoir l'autorisation, le client envoie l'identifiant utilisateur et le mot de passe, séparés par un seul caractère deux-points (« : »), dans une chaîne encodée en base64 [7] dans les identifiants.

basic-credentials = base64-user-pass
base64-user-pass  = <base64 [4] encoding of user-pass,
                     except not limited to 76 char/line>
user-pass   = userid ":" password
userid      = *<TEXT excluding ":">
password    = *TEXT

Les identifiants utilisateur peuvent être sensibles à la casse.

Si l'agent utilisateur souhaite envoyer l'identifiant utilisateur « Aladdin » et le mot de passe « open sesame », il utiliserait le champ d'en-tête suivant :

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Le client devrait supposer que tous les chemins à la profondeur de l'élément symbolique terminal ou plus profonds dans le champ path du Request-URI se trouvent également dans l'espace de protection spécifié par la valeur Basic realm du défi actuel. Le client peut envoyer de manière préventive l'en-tête Authorization correspondant avec les requêtes pour les ressources dans cet espace sans recevoir un autre défi du serveur. De même, lorsqu'un client envoie une requête à un proxy, il peut réutiliser un identifiant utilisateur et un mot de passe dans le champ d'en-tête Proxy-Authorization sans recevoir un autre défi du serveur proxy. Voir la section 4 pour les considérations de sécurité associées à l'authentification de base.

---