11. Authentification HTTP (HTTP Authentication)
11.1. Schéma d'Authentification (Authentication Scheme)
HTTP fournit un cadre général pour le contrôle d'accès et l'authentification via un ensemble extensible de schémas d'authentification défi-réponse, qu'un serveur peut utiliser pour défier une requête client et qu'un client peut utiliser pour fournir des informations d'authentification. Il utilise un jeton insensible à la casse pour identifier le schéma d'authentification :
auth-scheme = token
Outre le cadre général, ce document ne spécifie aucun schéma d'authentification. Les nouveaux schémas d'authentification et les schémas existants sont spécifiés indépendamment et devraient être enregistrés dans le « Registre des Schémas d'Authentification du Protocole de Transfert Hypertexte (HTTP) ». Par exemple, les schémas d'authentification « basic » et « digest » sont définis respectivement par [RFC7617] et [RFC7616].
11.2. Paramètres d'Authentification (Authentication Parameters)
Un schéma d'authentification est suivi d'informations supplémentaires nécessaires pour réaliser l'authentification via ce schéma, soit sous forme de liste de paramètres séparés par des virgules, soit sous forme de séquence unique de caractères capable de contenir des informations encodées en base64.
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
La syntaxe token68 permet les 66 caractères URI non réservés ([URI]), 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 excluant les espaces ([RFC4648]).
Les paramètres d'authentification sont des paires nom/valeur, où le jeton de nom est mis en correspondance sans distinction de casse, et chaque nom de paramètre ne peut apparaître qu'une seule fois par défi.
auth-param = token BWS "=" BWS ( token / quoted-string )
Les valeurs de paramètre peuvent être exprimées soit comme « token » soit comme « quoted-string » (Section 5.6). Les définitions de schéma d'authentification doivent accepter les deux notations, tant pour les expéditeurs que pour les destinataires, pour permettre aux destinataires d'utiliser des composants d'analyse génériques indépendamment du schéma d'authentification.
Pour la compatibilité descendante, les définitions de schéma d'authentification peuvent restreindre le format pour les expéditeurs à l'une des deux variantes. Cela peut être important lorsqu'on sait que les implémentations déployées échoueront en rencontrant l'un des deux formats.
11.3. Défi et Réponse (Challenge and Response)
Un serveur d'origine utilise le message de réponse 401 (Unauthorized) pour défier l'autorisation d'un agent utilisateur, incluant un champ d'en-tête WWW-Authenticate contenant au moins un défi applicable à la ressource demandée.
Un proxy utilise le message de réponse 407 (Proxy Authentication Required) pour défier l'autorisation d'un client, incluant un champ d'en-tête Proxy-Authenticate contenant au moins un défi applicable au proxy pour la ressource demandée.
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Note : De nombreux clients échouent à analyser un défi contenant un schéma inconnu. Une solution de contournement à ce problème consiste à lister d'abord les schémas bien supportés (tels que « 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 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.
11.4. Informations d'Identification (Credentials)
La valeur du champ Authorization et la valeur du champ Proxy-Authorization contiennent toutes deux les informations d'identification du client pour le royaume de la ressource demandée, basées sur un défi reçu dans une réponse (possiblement à un moment donné dans le passé). Lors de la création de leurs valeurs, l'agent utilisateur devrait le faire en sélectionnant le défi avec ce qu'il considère comme l'auth-scheme le plus sécurisé qu'il comprend, obtenant les informations d'identification de l'utilisateur de manière appropriée. La transmission d'informations d'identification dans les valeurs de champ d'en-tête implique des considérations de sécurité importantes concernant la confidentialité de la connexion sous-jacente, comme décrit dans la Section 17.16.1.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
À la réception d'une requête pour une ressource protégée qui omit les informations d'identification, contient des informations d'identification invalides (par exemple, un mauvais mot de passe) ou des informations d'identification partielles (par exemple, lorsque le schéma d'authentification nécessite plus d'un aller-retour), un serveur d'origine DEVRAIT (SHOULD) envoyer une réponse 401 (Unauthorized) qui contient un champ d'en-tête WWW-Authenticate avec au moins un défi (éventuellement nouveau) applicable à la ressource demandée.
De même, à la réception d'une requête qui omit les informations d'identification du proxy ou contient des informations d'identification du proxy invalides ou partielles, un proxy qui nécessite une authentification DEVRAIT (SHOULD) générer une réponse 407 (Proxy Authentication Required) qui contient un champ d'en-tête Proxy-Authenticate avec au moins un défi (éventuellement nouveau) applicable au proxy.
Un serveur qui reçoit des informations d'identification valides mais inadéquates pour obtenir l'accès devrait répondre avec le code d'état 403 (Forbidden) (Section 15.5.4).
HTTP ne limite pas les applications à ce simple cadre de défi-réponse pour l'authentification d'accès. Des mécanismes supplémentaires peuvent être utilisés, tels que l'authentification au niveau transport ou via l'encapsulation de messages, et avec des champs d'en-tête supplémentaires spécifiant les informations d'authentification. Cependant, de tels mécanismes supplémentaires ne sont pas définis par cette spécification.
Notez que divers mécanismes d'authentification utilisateur personnalisés sont implémentés en utilisant les champs d'en-tête Set-Cookie et Cookie, définis dans [COOKIE], pour transporter des jetons liés à l'authentification.
11.5. Établissement d'un Espace de Protection (Royaume) (Establishing a Protection Space (Realm))
Le paramètre d'authentification « realm » est réservé à l'usage par les schémas d'authentification qui souhaitent indiquer une portée de protection.
Un espace de protection est défini par l'origine (voir Section 4.3.1) du serveur auquel on accède, en combinaison avec la valeur realm si elle est présente. Ces royaumes permettent de partitionner les ressources protégées sur un serveur en un ensemble d'espaces de protection, chacun avec 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. Notez qu'une réponse peut avoir plusieurs défis avec le même auth-scheme mais avec des royaumes différents.
L'espace de protection détermine le domaine sur lequel les informations d'identification peuvent être automatiquement appliquées. Si une requête précédente a été autorisée, l'agent utilisateur PEUT (MAY) réutiliser les mêmes informations d'identification 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 (comme un délai d'inactivité configurable).
L'étendue d'un espace de protection, et donc où les informations d'identification pourraient être automatiquement appliquées par un client, n'est pas nécessairement connue par le client à moins qu'il n'y ait des informations supplémentaires. Les schémas d'authentification peuvent définir des paramètres qui décrivent l'étendue d'un espace de protection. Un espace de protection ne peut pas s'étendre en dehors de la portée de son serveur sauf autorisation spécifique du schéma d'authentification.
Pour des raisons historiques, un expéditeur DOIT (MUST) générer uniquement la syntaxe quoted-string. Les destinataires peuvent devoir supporter à la fois la syntaxe token et quoted-string pour une interopérabilité maximale avec les clients existants qui acceptent les deux notations depuis longtemps.
11.6. Authentification des Utilisateurs auprès des Serveurs d'Origine (Authenticating Users to Origin Servers)
11.6.1. WWW-Authenticate
Le champ d'en-tête de réponse « WWW-Authenticate » indique le ou les schémas d'authentification et paramètres applicables à la ressource cible.
WWW-Authenticate = #challenge
Un serveur générant une réponse 401 (Unauthorized) DOIT (MUST) envoyer un champ d'en-tête WWW-Authenticate contenant au moins un défi. Un serveur PEUT (MAY) générer un champ d'en-tête WWW-Authenticate dans d'autres messages de réponse pour indiquer que la fourniture d'informations d'identification (ou d'informations d'identification différentes) pourrait affecter la réponse.
Un proxy transférant une réponse NE DOIT PAS (MUST NOT) modifier les champs d'en-tête WWW-Authenticate dans cette réponse.
Il est conseillé aux agents utilisateurs de faire particulièrement attention lors de l'analyse de la valeur du champ, car elle peut contenir plus d'un défi, et chaque défi peut contenir une liste de paramètres d'authentification séparés par des virgules. De plus, le champ d'en-tête lui-même peut apparaître plusieurs fois.
Par exemple :
WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
type=1, title="Login to \"apps\""
Ce champ d'en-tête contient deux défis, un pour le schéma « Basic » avec une valeur realm de « simple », et un autre pour le schéma « Newauth » avec une valeur realm de « apps ». Il contient également deux paramètres supplémentaires, « type » et « title ».
Cependant, certains agents utilisateurs ne reconnaissent pas cette forme. Par conséquent, l'envoi d'une valeur de champ WWW-Authenticate avec plusieurs membres sur la même ligne de champ peut ne pas être interopérable.
Note : La production grammaticale du défi utilise également la syntaxe de liste. Par conséquent, une séquence de virgule, espace blanc et virgule peut être considérée comme s'appliquant au défi précédent, ou comme étant une entrée vide dans la liste des défis. En pratique, cette ambiguïté n'affecte pas la sémantique de la valeur du champ d'en-tête et est donc inoffensive.
11.6.2. Authorization
Le champ d'en-tête « Authorization » permet à un agent utilisateur de 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). Sa valeur consiste en des informations d'identification contenant les informations d'authentification de l'agent utilisateur pour le royaume de la ressource demandée.
Authorization = credentials
Si une requête est authentifiée et qu'un royaume est spécifié, les mêmes informations d'identification sont présumées valides pour toutes les autres requêtes dans ce royaume (en supposant que le schéma d'authentification lui-même n'exige pas autrement, comme des informations d'identification qui varient selon une valeur de défi ou l'utilisation d'horloges synchronisées).
Un proxy transférant une requête NE DOIT PAS (MUST NOT) modifier les champs d'en-tête Authorization dans cette requête. Voir la Section 3.5 de [CACHING] pour les détails et les exigences concernant le traitement du champ d'en-tête Authorization par les caches HTTP.
11.6.3. Authentication-Info
Les schémas d'authentification HTTP peuvent utiliser le champ de réponse « Authentication-Info » pour communiquer des informations après que les informations d'identification d'authentification du client ont été acceptées. Ces informations peuvent inclure un message final du serveur (par exemple, elles peuvent contenir l'authentification du serveur).
La valeur du champ est une liste de paramètres (paires nom/valeur), utilisant la syntaxe « auth-param » définie dans la Section 11.3. Cette spécification décrit uniquement le format générique ; les schémas d'authentification utilisant Authentication-Info définiront les paramètres individuels. Par exemple, le schéma d'authentification « Digest » définit plusieurs paramètres dans la Section 3.5 de [RFC7616].
Authentication-Info = #auth-param
Le champ Authentication-Info peut être utilisé dans n'importe quelle réponse HTTP, indépendamment de la méthode de requête et du code d'état. Sa sémantique est définie par le schéma d'authentification indiqué par le champ d'en-tête Authorization (Section 11.6.2) de la requête correspondante.
Un proxy transférant une réponse n'est pas autorisé à modifier la valeur du champ de quelque manière que ce soit.
Authentication-Info peut être envoyé comme champ de remorque (Section 6.5) une fois qu'il devient clair que le corps du message sera envoyé (par exemple, l'authentification n'est pas rejetée), lorsque le schéma d'authentification le permet explicitement.
11.7. Authentification des Clients auprès des Proxys (Authenticating Clients to Proxies)
11.7.1. Proxy-Authenticate
Le champ d'en-tête « Proxy-Authenticate » consiste en au moins un défi qui indique le ou les schémas d'authentification et paramètres applicables au proxy pour cette requête. Un proxy DOIT (MUST) envoyer au moins un champ d'en-tête Proxy-Authenticate dans chaque réponse 407 (Proxy Authentication Required) qu'il génère.
Proxy-Authenticate = #challenge
Contrairement à WWW-Authenticate, le champ d'en-tête Proxy-Authenticate s'applique uniquement au client sortant suivant sur la chaîne de réponse. Cela est dû au fait que seul le client qui a choisi un proxy donné est susceptible d'avoir les informations d'identification nécessaires pour l'authentification. Cependant, lorsque plusieurs proxys sont utilisés dans le même domaine administratif, comme les proxys de bureau et régionaux de mise en cache dans un grand réseau d'entreprise, il est courant que les informations d'identification soient générées par l'agent utilisateur et transmises à travers la hiérarchie jusqu'à consommation. Par conséquent, dans une telle configuration, il semblera que Proxy-Authenticate soit transféré car chaque proxy enverra le même ensemble de défis.
Notez que les considérations d'analyse pour WWW-Authenticate s'appliquent également à ce champ d'en-tête ; voir la Section 11.6.1 pour les détails.
11.7.2. Proxy-Authorization
Le champ d'en-tête « Proxy-Authorization » permet au client de s'identifier (ou d'identifier son utilisateur) auprès d'un proxy qui nécessite une authentification. Sa valeur consiste en des informations d'identification contenant les informations d'authentification du client pour le proxy et/ou le royaume de la ressource demandée.
Proxy-Authorization = credentials
Contrairement à Authorization, le champ d'en-tête Proxy-Authorization s'applique uniquement au proxy entrant suivant qui a demandé l'authentification en utilisant le champ d'en-tête Proxy-Authenticate. Lorsque plusieurs proxys sont utilisés dans une chaîne, le champ d'en-tête Proxy-Authorization est consommé par le premier proxy entrant qui s'attendait à recevoir des informations d'identification. Un proxy PEUT (MAY) relayer les informations d'identification de la requête client vers le proxy suivant si c'est le mécanisme par lequel les proxys coopèrent pour authentifier une requête donnée.
11.7.3. Proxy-Authentication-Info
Le champ d'en-tête de réponse « Proxy-Authentication-Info » est équivalent à Authentication-Info, sauf qu'il s'applique à l'authentification proxy (Section 11.3) et que sa sémantique est définie par le schéma d'authentification indiqué par le champ d'en-tête Proxy-Authorization (Section 11.7.2) de la requête correspondante :
Proxy-Authentication-Info = #auth-param
Cependant, contrairement à Authentication-Info, le champ d'en-tête Proxy-Authentication-Info s'applique uniquement au client sortant suivant sur la chaîne de réponse. Cela est dû au fait que seul le client qui a choisi un proxy donné est susceptible d'avoir les informations d'identification nécessaires pour l'authentification. Cependant, lorsque plusieurs proxys sont utilisés dans le même domaine administratif, comme les proxys de bureau et régionaux de mise en cache dans un grand réseau d'entreprise, il est courant que les informations d'identification soient générées par l'agent utilisateur et transmises à travers la hiérarchie jusqu'à consommation. Par conséquent, dans une telle configuration, il semblera que Proxy-Authentication-Info soit transféré car chaque proxy enverra la même valeur de champ.
Proxy-Authentication-Info peut être envoyé comme champ de remorque (Section 6.5) une fois qu'il devient clair que le corps du message sera envoyé, lorsque le schéma d'authentification le permet explicitement.