1. Authentification d'accès (Access Authentication)
1.1 Dépendance à la spécification HTTP/1.1 (Reliance on the HTTP/1.1 Specification)
Cette spécification est un document d'accompagnement de la spécification HTTP/1.1 [2]. Elle utilise la notation BNF augmentée de la section 2.1 de ce document et s'appuie à la fois sur les non-terminaux définis dans ce document et sur d'autres aspects de la spécification HTTP/1.1.
1.2 Cadre d'authentification d'accès (Access Authentication Framework)
HTTP fournit un mécanisme d'authentification défi-réponse simple (Challenge-Response Authentication Mechanism) qu'un serveur peut utiliser pour défier une requête client, et que le client peut utiliser pour fournir des informations d'authentification. Il utilise un jeton (Token) extensible et insensible à la casse pour identifier le schéma d'authentification (Authentication Scheme), suivi d'une liste séparée par des virgules de paires attribut-valeur qui transportent les paramètres nécessaires pour réaliser l'authentification via ce schéma.
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
Le serveur d'origine (Origin Server) utilise un message de réponse 401 (Unauthorized) pour défier l'autorisation de l'agent utilisateur. Cette réponse doit inclure un champ d'en-tête WWW-Authenticate contenant au moins un défi applicable à la ressource demandée. Un proxy (Proxy) utilise un message de réponse 407 (Proxy Authentication Required) pour défier l'autorisation du client, et doit inclure un champ d'en-tête Proxy-Authenticate contenant au moins un défi proxy applicable à la ressource demandée.
challenge = auth-scheme 1*SP 1#auth-param
Note : Si la valeur du champ d'en-tête WWW-Authenticate ou Proxy-Authenticate contient plusieurs défis, ou si plusieurs champs d'en-tête WWW-Authenticate sont fournis, l'agent utilisateur doit faire très attention lors de l'analyse, car le contenu du défi lui-même peut contenir une liste de paramètres d'authentification séparés par des virgules.
Le paramètre d'authentification realm (domaine) est défini pour tous les schémas d'authentification :
realm = "realm" "=" realm-value
realm-value = quoted-string
La directive realm (insensible à la casse) est requise pour tous les schémas d'authentification qui émettent un défi. La valeur realm (sensible à la casse), en combinaison avec l'URL racine canonique (l'absoluteURI pour le serveur dont l'abs_path est vide ; voir section 5.1.2 de [2]) du serveur accédé, définit l'espace de protection (Protection Space). Ces realms permettent de partitionner les ressources protégées sur un serveur en un ensemble d'espaces de protection, chacun ayant son propre schéma d'authentification et/ou 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 spécifique au schéma d'authentification. Veuillez noter qu'il peut y avoir plusieurs défis avec le même auth-scheme mais des realms différents.
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 un 401 (Unauthorized) -- peut le faire en incluant un champ d'en-tête Authorization avec la requête. Un client qui souhaite s'authentifier auprès d'un proxy -- généralement, mais pas nécessairement, après avoir reçu un 407 (Proxy Authentication Required) -- peut le faire en incluant un champ d'en-tête Proxy-Authorization avec la requête. La valeur du champ Authorization et la valeur du champ Proxy-Authorization consistent toutes deux en des identifiants (Credentials), contenant les informations d'authentification du client pour le realm de la ressource demandée. L'agent utilisateur doit choisir d'utiliser le défi avec l'auth-scheme le plus fort qu'il comprend et demander des identifiants à l'utilisateur en fonction de ce défi.
credentials = auth-scheme #auth-param
Note : De nombreux navigateurs ne reconnaissent que l'authentification de base (Basic) et exigent qu'elle soit le premier auth-scheme présenté. Les serveurs ne devraient inclure l'authentification de base que lorsqu'elle est la norme minimale acceptable.
L'espace de protection détermine le domaine dans lequel les identifiants peuvent être automatiquement appliqués. Si une requête précédente a été autorisée, les mêmes identifiants peuvent être réutilisés pour toutes les autres requêtes dans cet espace de protection pendant une période de temps déterminée par le schéma d'authentification, les paramètres et/ou les préférences de l'utilisateur. Sauf définition contraire par le schéma d'authentification, un seul espace de protection ne peut pas s'étendre au-delà de son serveur.
Si le serveur d'origine ne souhaite pas accepter les identifiants envoyés avec une requête, il devrait renvoyer une réponse 401 (Unauthorized). La réponse doit inclure un champ d'en-tête WWW-Authenticate contenant au moins un défi (éventuellement nouveau) applicable à la ressource demandée. Si un proxy n'accepte pas les identifiants envoyés avec une requête, il devrait renvoyer un 407 (Proxy Authentication Required). La réponse doit inclure un champ d'en-tête Proxy-Authenticate contenant un défi (éventuellement nouveau) applicable à la ressource demandée.
Le protocole HTTP ne restreint pas les applications à ce mécanisme simple défi-réponse pour l'authentification d'accès. Des mécanismes supplémentaires peuvent être utilisés, tels que le chiffrement de la couche transport ou via l'encapsulation de messages, et avec des champs d'en-tête supplémentaires spécifiant les informations d'authentification. Cependant, ces mécanismes supplémentaires ne sont pas définis par cette spécification.
Les proxies doivent être complètement transparents concernant l'authentification de l'agent utilisateur avec le serveur d'origine. C'est-à-dire qu'ils doivent transmettre les en-têtes WWW-Authenticate et Authorization sans modification, et suivre les règles de la section 14.8 de [2]. Les champs d'en-tête Proxy-Authenticate et Proxy-Authorization sont tous deux des en-têtes saut par saut (Hop-by-Hop Headers) (voir section 13.5.1 de [2]).