2. Le schéma d'authentification 'Basic'
Le schéma d'authentification Basic est basé sur le modèle selon lequel le client doit s'authentifier avec un user-id et un mot de passe pour chaque espace de protection ("realm"). La valeur du realm est une chaîne de forme libre qui ne peut être comparée qu'en termes d'égalité avec d'autres realms sur ce serveur. Le serveur ne traitera la demande que s'il peut valider le user-id et le mot de passe pour l'espace de protection s'appliquant à la ressource demandée.
Le schéma d'authentification Basic utilise le cadre d'authentification comme suit.
Dans les challenges:
- Le nom du schéma est "Basic".
- Le paramètre d'authentification 'realm' est OBLIGATOIRE (REQUIRED) ([RFC7235], section 2.2).
- Le paramètre d'authentification 'charset' est OPTIONNEL (OPTIONAL) (voir section 2.1).
- Aucun autre paramètre d'authentification n'est défini -- les paramètres inconnus DOIVENT être ignorés par les destinataires, et de nouveaux paramètres ne peuvent être définis qu'en révisant cette spécification.
Voir également la section 4.1 de [RFC7235], qui discute de la complexité de l'analyse correcte des challenges.
Notez que les noms de schéma et de paramètre sont comparés sans tenir compte de la casse.
Pour les informations d'identification, la syntaxe "token68" définie dans la section 2.1 de [RFC7235] est utilisée. La valeur est calculée en fonction du user-id et du mot de passe comme défini ci-dessous.
À la réception d'une demande pour un URI dans l'espace de protection qui manque d'informations d'identification, le serveur peut répondre avec un challenge utilisant le code de statut 401 (Unauthorized) ([RFC7235], section 3.1) et le champ d'en-tête WWW-Authenticate ([RFC7235], section 4.1).
Par exemple:
HTTP/1.1 401 Unauthorized
Date: Mon, 04 Feb 2014 16:50:53 GMT
WWW-Authenticate: Basic realm="WallyWorld"
où "WallyWorld" est la chaîne assignée par le serveur pour identifier l'espace de protection.
Un proxy peut répondre avec un challenge similaire utilisant le code de statut 407 (Proxy Authentication Required) ([RFC7235], section 3.2) et le champ d'en-tête Proxy-Authenticate ([RFC7235], section 4.3).
Pour recevoir l'autorisation, le client
- obtient le user-id et le mot de passe de l'utilisateur,
- construit le user-pass en concaténant le user-id, un seul caractère deux-points (":"), et le mot de passe,
- encode le user-pass en une séquence d'octets (voir ci-dessous pour une discussion sur les schémas d'encodage de caractères),
- et obtient les basic-credentials en encodant cette séquence d'octets en utilisant Base64 ([RFC4648], section 4) en une séquence de caractères US-ASCII ([RFC0020]).
La définition originale de ce schéma d'authentification n'a pas spécifié le schéma d'encodage de caractères utilisé pour convertir le user-pass en une séquence d'octets. En pratique, la plupart des implémentations ont choisi soit un encodage spécifique à la locale tel que ISO-8859-1 ([ISO-8859-1]), soit UTF-8 ([RFC3629]). Pour des raisons de rétrocompatibilité, cette spécification continue de laisser l'encodage par défaut non défini, tant qu'il est compatible avec US-ASCII (mappant tout caractère US-ASCII à un seul octet correspondant au code de caractère US-ASCII).
Le user-id et le mot de passe NE DOIVENT PAS contenir de caractères de contrôle (voir "CTL" dans l'annexe B.1 de [RFC5234]).
De plus, un user-id contenant un caractère deux-points est invalide, car le premier deux-points dans une chaîne user-pass sépare le user-id et le mot de passe l'un de l'autre; le texte après le premier deux-points fait partie du mot de passe. Les user-ids contenant des deux-points ne peuvent pas être encodés dans des chaînes user-pass.
Notez que de nombreux agents utilisateurs produisent des chaînes user-pass sans vérifier que les user-ids fournis par les utilisateurs ne contiennent pas de deux-points; les destinataires traiteront alors une partie de la saisie du nom d'utilisateur comme faisant partie du mot de passe.
Si l'agent utilisateur souhaite envoyer le user-id "Aladdin" et le mot de passe "open sesame", il utiliserait le champ d'en-tête suivant:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
2.1. Le paramètre auth-param 'charset'
Dans les challenges, les serveurs peuvent utiliser le paramètre d'authentification 'charset' pour indiquer le schéma d'encodage de caractères qu'ils attendent que l'agent utilisateur utilise lors de la génération de "user-pass" (une séquence d'octets). Cette information est purement consultative.
La seule valeur autorisée est "UTF-8"; elle doit être comparée sans tenir compte de la casse (voir [RFC2978], section 2.3). Elle indique que le serveur s'attend à ce que les données de caractères soient converties en forme de normalisation Unicode C ("NFC"; voir section 3 de [RFC5198]) et encodées en octets en utilisant le schéma d'encodage de caractères UTF-8 ([RFC3629]).
Pour le user-id, les destinataires DOIVENT prendre en charge tous les caractères définis dans le profil "UsernameCasePreserved" défini dans la section 3.3 de [RFC7613], à l'exception du caractère deux-points (":").
Pour le mot de passe, les destinataires DOIVENT prendre en charge tous les caractères définis dans le profil "OpaqueString" défini dans la section 4.2 de [RFC7613].
Les autres valeurs sont réservées pour une utilisation future.
Note: Le 'charset' n'est défini que dans les challenges, car l'authentification Basic utilise un jeton unique pour les informations d'identification (syntaxe 'token68'); ainsi, la syntaxe des informations d'identification n'est pas extensible.
Note: Le nom 'charset' a été choisi pour la cohérence avec la section 2.1.1 de [RFC2831]. Un meilleur nom aurait été 'accept-charset', car il ne concerne pas le message dans lequel il apparaît, mais l'attente du serveur.
Dans l'exemple ci-dessous, le serveur demande une authentification dans le realm "foo", en utilisant l'authentification Basic, avec une préférence pour le schéma d'encodage de caractères UTF-8:
WWW-Authenticate: Basic realm="foo", charset="UTF-8"
Notez que la valeur du paramètre peut être soit un token, soit une chaîne entre guillemets; dans ce cas, le serveur a choisi d'utiliser la notation de chaîne entre guillemets.
Le nom de l'utilisateur est "test", et le mot de passe est la chaîne "123" suivie du caractère Unicode U+00A3 (POUND SIGN). En utilisant le schéma d'encodage de caractères UTF-8, le user-pass devient:
't' 'e' 's' 't' ':' '1' '2' '3' pound
74 65 73 74 3A 31 32 33 C2 A3
L'encodage de cette séquence d'octets en Base64 ([RFC4648], section 4) donne:
dGVzdDoxMjPCow==
Ainsi, le champ d'en-tête Authorization serait:
Authorization: Basic dGVzdDoxMjPCow==
Ou, pour l'authentification proxy:
Proxy-Authorization: Basic dGVzdDoxMjPCow==
2.2. Réutilisation des informations d'identification
Étant donné l'URI absolu ([RFC3986], section 4.3) d'une demande authentifiée, la portée d'authentification de cette demande est obtenue en supprimant tous les caractères après le dernier caractère barre oblique ("/") du composant de chemin ("hier_part"; voir [RFC3986], section 3). Un client DEVRAIT supposer que les ressources identifiées par des URIs avec une correspondance de préfixe de la portée d'authentification se trouvent également dans l'espace de protection spécifié par la valeur du realm de cette demande authentifiée.
Un client PEUT envoyer de manière préventive le champ d'en-tête Authorization correspondant avec des demandes de ressources dans cet espace sans recevoir un autre challenge du serveur. De même, lorsqu'un client envoie une demande à un proxy, il PEUT réutiliser un user-id et un mot de passe dans le champ d'en-tête Proxy-Authorization sans recevoir un autre challenge du serveur proxy.
Par exemple, étant donné une demande authentifiée à:
http://example.com/docs/index.html
les demandes aux URIs ci-dessous pourraient utiliser les informations d'identification connues:
http://example.com/docs/
http://example.com/docs/test.doc
http://example.com/docs/?page=1
alors que les URIs
http://example.com/other/
https://example.com/docs/
seraient considérés comme étant en dehors de la portée d'authentification.
Notez qu'un URI peut faire partie de plusieurs portées d'authentification (telles que "http://example.com/" et "http://example.com/docs/"). Cette spécification ne définit pas laquelle de celles-ci devrait être traitée avec une priorité plus élevée.