2. Cadre d'authentification d'accès
2.1 Défi et réponse
HTTP fournit un cadre d'authentification défi-réponse simple qui peut être utilisé par un serveur pour défier une requête d'un client et par un client pour fournir des informations d'authentification. Il utilise un jeton insensible à la casse pour identifier le schéma d'authentification, suivi des informations supplémentaires nécessaires pour réussir l'authentification au moyen de ce schéma. Ces dernières peuvent être soit une liste de paramètres séparés par des virgules, soit une séquence unique de caractères capable de contenir des informations encodées en base64.
Les paramètres d'authentification sont des paires nom=valeur, où le jeton du nom est comparé sans tenir compte de la casse et chaque nom de paramètre ne doit apparaître qu'une seule fois par défi (MUST).
auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string )
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
La syntaxe token68 autorise les 66 caractères d'URI non réservés ([RFC3986]), plus quelques autres, de sorte qu'elle peut contenir un encodage base64, base64url (alphabet sûr pour les URL et les noms de fichiers), base32 ou base16 (hexadécimal), avec ou sans remplissage, mais à l'exclusion des espaces ([RFC4648]).
Un message de réponse 401 (Unauthorized) est utilisé par un serveur d'origine pour défier l'autorisation d'un agent utilisateur, et comprend un champ d'en-tête WWW-Authenticate contenant au moins un défi applicable à la ressource demandée.
Un message de réponse 407 (Proxy Authentication Required) est utilisé par un mandataire pour défier l'autorisation d'un client, et comprend un champ d'en-tête Proxy-Authenticate contenant au moins un défi applicable au mandataire pour la ressource demandée.
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Remarque : De nombreux clients ne parviennent pas à analyser un défi qui contient un schéma inconnu. Une solution à ce problème consiste à énumérer en premier les schémas bien pris en charge (comme "basic").
Un agent utilisateur qui souhaite s'authentifier auprès d'un serveur d'origine — généralement, mais pas nécessairement, après avoir reçu une réponse 401 (Unauthorized) — peut le faire en incluant un champ d'en-tête Authorization dans la requête.
Un client qui souhaite s'authentifier auprès d'un mandataire — généralement, mais pas nécessairement, après avoir reçu une réponse 407 (Proxy Authentication Required) — peut le faire en incluant un champ d'en-tête Proxy-Authorization dans la requête.
La valeur du champ Authorization et celle du champ Proxy-Authorization contiennent toutes deux les informations d'authentification du client pour le domaine de la ressource demandée, sur la base d'un défi reçu dans une réponse (éventuellement à un moment antérieur). Lors de la création de ces valeurs, l'agent utilisateur devrait choisir le défi dont le schéma d'authentification lui semble le plus sûr parmi ceux qu'il comprend, et obtenir les informations d'authentification auprès de l'utilisateur le cas échéant. La transmission d'informations d'authentification dans les valeurs de champs d'en-tête implique d'importantes considérations de sécurité concernant la confidentialité de la connexion sous-jacente, comme décrit à la section 6.1.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
À la réception d'une requête portant sur une ressource protégée qui omet les informations d'authentification, contient des informations d'authentification invalides (par exemple un mot de passe erroné) ou partielles (par exemple lorsque le schéma d'authentification exige plus d'un aller-retour), un serveur d'origine devrait envoyer une réponse 401 (Unauthorized) contenant un champ d'en-tête WWW-Authenticate avec au moins un défi (éventuellement nouveau) applicable à la ressource demandée (SHOULD).
De même, à la réception d'une requête qui omet les informations d'authentification de mandataire ou contient des informations d'authentification de mandataire invalides ou partielles, un mandataire qui exige une authentification devrait générer une réponse 407 (Proxy Authentication Required) contenant un champ d'en-tête Proxy-Authenticate avec au moins un défi (éventuellement nouveau) applicable au mandataire (SHOULD).
Un serveur qui reçoit des informations d'authentification valides mais insuffisantes pour obtenir l'accès devrait répondre avec le code d'état 403 (Forbidden) (section 6.5.3 de la [RFC7231]).
HTTP ne limite pas les applications à ce cadre simple de défi-réponse pour l'authentification d'accès. D'autres mécanismes peuvent être utilisés, tels que l'authentification au niveau du transport ou par encapsulation de messages, avec des champs d'en-tête supplémentaires spécifiant les informations d'authentification. Toutefois, ces mécanismes supplémentaires ne sont pas définis par la présente spécification.
2.2 Espace de protection (realm)
Le paramètre d'authentification "realm" est réservé à l'usage des schémas d'authentification qui souhaitent indiquer une portée de protection.
Un espace de protection est défini par l'URI racine canonique (les composantes scheme et authority de l'URI de requête effective ; voir la section 5.5 de la [RFC7230]) du serveur auquel on accède, en combinaison avec la valeur realm si elle est présente. Ces domaines permettent de partitionner les ressources protégées d'un serveur en un ensemble d'espaces de protection, chacun disposant de son propre schéma d'authentification et/ou de sa propre base de données d'autorisation. La valeur realm est une chaîne, généralement attribuée par le serveur d'origine, qui peut avoir une sémantique supplémentaire propre au schéma d'authentification. Notez qu'une réponse peut comporter plusieurs défis avec le même auth-scheme mais des domaines différents.
L'espace de protection détermine le domaine sur lequel les informations d'authentification peuvent être appliquées automatiquement. Si une requête antérieure a été autorisée, l'agent utilisateur peut réutiliser les mêmes informations d'authentification pour toutes les autres requêtes de cet espace de protection pendant une période déterminée par le schéma d'authentification, les paramètres et/ou les préférences de l'utilisateur (comme un délai d'inactivité configurable) (MAY). Sauf autorisation explicite du schéma d'authentification, un espace de protection unique ne peut pas s'étendre au-delà de la portée de son serveur.
Pour des raisons historiques, un émetteur ne doit générer que la syntaxe quoted-string (MUST). Les destinataires peuvent devoir prendre en charge à la fois la syntaxe token et la syntaxe quoted-string pour une interopérabilité maximale avec les clients existants qui acceptent ces deux notations depuis longtemps.