4. Définitions des champs d'en-tête
Cette section définit la syntaxe et la sémantique des champs d'en-tête liés au cadre d'authentification HTTP.
4.1 WWW-Authenticate
Le champ d'en-tête "WWW-Authenticate" indique le ou les schémas d'authentification et les paramètres applicables à la ressource cible.
WWW-Authenticate = 1#challenge
Un serveur qui génère une réponse 401 (Unauthorized) doit envoyer un champ d'en-tête WWW-Authenticate contenant au moins un défi (MUST). Un serveur peut 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'authentification (ou d'informations différentes) pourrait affecter la réponse (MAY).
Un mandataire qui transfère une réponse ne doit modifier aucun champ WWW-Authenticate de cette réponse (MUST NOT).
Il est conseillé aux agents utilisateurs de porter une attention particulière à 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. En outre, le champ d'en-tête lui-même peut apparaître plusieurs fois.
Par exemple :
WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple"
Ce champ d'en-tête contient deux défis : l'un pour le schéma "Newauth" avec une valeur de domaine "apps" et deux paramètres supplémentaires "type" et "title", et l'autre pour le schéma "Basic" avec une valeur de domaine "simple".
Remarque : La production grammaticale challenge utilise également la syntaxe de liste. Par conséquent, une séquence composée d'une virgule, d'un espace et d'une virgule peut être considérée soit comme s'appliquant au défi précédent, soit comme 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 sans conséquence.
4.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 est constituée d'informations d'authentification contenant les informations d'identification de l'agent utilisateur pour le domaine de la ressource demandée.
Authorization = credentials
Si une requête est authentifiée et qu'un domaine est spécifié, les mêmes informations d'authentification sont présumées valides pour toutes les autres requêtes de ce domaine (en supposant que le schéma d'authentification lui-même n'exige pas le contraire, par exemple des informations d'authentification variant selon la valeur du défi ou l'utilisation d'horloges synchronisées).
Un mandataire qui transfère une requête ne doit modifier aucun champ Authorization de cette requête (MUST NOT). Voir la section 3.2 de la [RFC7234] pour les détails et les exigences relatifs au traitement du champ Authorization par les caches HTTP.
4.3 Proxy-Authenticate
Le champ d'en-tête "Proxy-Authenticate" est constitué d'au moins un défi qui indique le ou les schémas d'authentification et les paramètres applicables au mandataire pour cette URI de requête effective (section 5.5 de la [RFC7230]). Un mandataire doit envoyer au moins un champ d'en-tête Proxy-Authenticate dans chaque réponse 407 (Proxy Authentication Required) qu'il génère (MUST).
Proxy-Authenticate = 1#challenge
Contrairement à WWW-Authenticate, le champ d'en-tête Proxy-Authenticate ne s'applique qu'au client sortant suivant dans la chaîne de réponse. En effet, seul le client qui a choisi un mandataire donné est susceptible de posséder les informations d'authentification nécessaires. Toutefois, lorsque plusieurs mandataires sont utilisés au sein du même domaine administratif, comme les mandataires de cache de bureau et régionaux d'un grand réseau d'entreprise, il est courant que les informations d'authentification soient générées par l'agent utilisateur et transmises à travers la hiérarchie jusqu'à leur consommation. Ainsi, dans une telle configuration, tout se passe comme si Proxy-Authenticate était transféré, car chaque mandataire envoie le même ensemble de défis.
Notez que les considérations d'analyse relatives à WWW-Authenticate s'appliquent également à ce champ d'en-tête ; voir la section 4.1 pour plus de détails.
4.4 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 mandataire qui exige une authentification. Sa valeur est constituée d'informations d'authentification contenant les informations d'identification du client pour le mandataire et/ou le domaine de la ressource demandée.
Proxy-Authorization = credentials
Contrairement à Authorization, le champ d'en-tête Proxy-Authorization ne s'applique qu'au mandataire entrant suivant qui a exigé une authentification au moyen du champ Proxy-Authenticate. Lorsque plusieurs mandataires sont utilisés dans une chaîne, le champ d'en-tête Proxy-Authorization est consommé par le premier mandataire entrant qui s'attendait à recevoir des informations d'authentification. Un mandataire peut relayer les informations d'authentification de la requête du client vers le mandataire suivant si tel est le mécanisme par lequel les mandataires authentifient conjointement une requête donnée (MAY).