WWW-Authenticate : tous les défis, pas seulement le premier

Qu’est-ce que l’en-tête WWW-Authenticate ?

Lorsqu’un serveur répond à une requête par un 401 Unauthorized, il doit indiquer comment vous pourriez vous authentifier. C’est le rôle de l’en-tête WWW-Authenticate : une liste de défis, chacun nommant un schéma comme Basic ou Bearer et portant en général des paramètres tels qu’un realm. Le client choisit un schéma qu’il comprend et répond par un en-tête Authorization.

L’en-tête paraît simple et ne l’est pas. La RFC 9110 le dit elle-même, conseillant aux agents utilisateurs une attention particulière à l’analyse, car une valeur peut contenir plus d’un défi, chaque défi peut porter une liste de paramètres séparés par des virgules, et l’en-tête peut être envoyé plusieurs fois. Le séparateur entre défis et le séparateur entre paramètres sont le même caractère : rien n’indique localement lequel des deux est une virgule donnée.

Cette page implémente la grammaire de la spécification, affiche tous les défis et non le seul premier, et nomme chaque paramètre avec la forme sous laquelle il est arrivé. Elle analyse le défi envoyé par le serveur. Elle refuse délibérément de décoder un en-tête Authorization, qui est la réponse transportant vos identifiants.

Comment l’utiliser

1. Collez l’en-tête. Avec ou sans le nom du champ, un par ligne si la réponse en a envoyé plusieurs. Plusieurs en-têtes et une seule valeur séparée par des virgules sont équivalents selon la norme : la réponse est la même.
2. Lisez les défis. Chacun affiche son schéma, s’il figure au registre de l’IANA, et un tableau de paramètres indiquant si chaque valeur est arrivée sous forme de jeton sans guillemets, de chaîne entre guillemets, ou entre guillemets avec un échappement.
3. Regardez les notes en dessous. Elles couvrent ce sur quoi la norme a un avis : plus d’un défi par ligne, un schéma non enregistré, une virgule esseulée, un paramètre répété, ou un schéma connu qui n’est pas listé en premier.

Pourquoi cet en-tête est difficile à analyser

La spécification donne un exemple résolu puis, chose rare, en livre la réponse. Elle montre un défi Basic avec un realm valant simple, suivi d’un défi Newauth avec un realm valant apps, un paramètre type et un paramètre title, le tout sur une ligne. Et elle affirme qu’il s’agit de deux défis, et que type et title appartiennent au second.

Le déduire exige un jeton d’anticipation. Quand l’analyseur atteint type, rien de ce qui précède ne dit si ce mot ouvre un troisième défi ou nomme un paramètre du second. Seul le caractère suivant tranche : un jeton suivi d’un signe égal est un paramètre, un jeton suivi d’autre chose est un nouveau schéma. Manquez cette règle et vous obtenez une analyse plausible et tout simplement fausse.

Le même exemple recèle un second piège. Son paramètre title est une chaîne entre guillemets qui contient elle-même des guillemets, échappés par des barres obliques inverses. Un analyseur bâti sur l’idée d’aller d’un guillemet au suivant s’arrête au mauvais endroit, et une virgule à l’intérieur d’une valeur entre guillemets coupe en deux un défi qui devait rester entier.

Ce n’est pas une inquiétude théorique. Pendant la construction de cette page, deux analyseurs publiés ont été confrontés à l’exemple de la spécification elle-même. Aucun n’a rendu la réponse que la spécification imprime : l’un a signalé un unique défi avec les deux realms fusionnés, l’autre n’a rien rendu du tout, alors qu’il traite parfaitement un défi Basic ordinaire. La norme l’avait anticipé, en avertissant qu’envoyer plus d’un défi sur une ligne peut ne pas être interopérable, et séparément que beaucoup de clients échouent sur un schéma qu’ils ne reconnaissent pas.

Ce que cette page refuse de faire

Elle ne décodera pas un en-tête Authorization. WWW-Authenticate voyage depuis le serveur et est public : c’est la question. Authorization voyage depuis le client et transporte la réponse, qui pour Basic est votre identifiant et votre mot de passe sous un déguisement très mince. Si vous en collez un ici, la page vous le dit et s’arrête, sans le décoder. C’est la position que ce site tient déjà sur son décodeur de JWT, dépourvu de champ pour la clé de signature : coller un secret quelque part est une habitude à ne pas prendre, même dans une page qui fonctionne entièrement dans votre propre navigateur.

Elle vous dit ce que dit la grammaire, pas ce que fera votre client. Un défi peut être parfaitement valide et néanmoins ignoré, car un navigateur n’implémente qu’une poignée de schémas et une bibliothèque peut s’arrêter au premier défi qu’elle reconnaît. Rien ici n’a été mesuré face à un navigateur, et cette page n’avance aucune affirmation à ce sujet.

Elle ne juge pas non plus l’absence de realm. Il serait tentant d’y voir une erreur, mais la norme décrit le paramètre realm comme réservé aux schémas souhaitant indiquer une portée de protection, non comme une obligation pour tout défi. Là où la spécification s’abstient d’exiger, cette page s’abstient d’avertir.

Un cas est réellement ambigu et se voit signalé plutôt que tranché. Un signe égal final après un nom isolé, comme un défi se terminant par realm=, correspond à la grammaire d’un jeton opaque tout aussi bien qu’à celle d’un paramètre resté sans valeur, car cette production est une suite de caractères suivie d’un nombre quelconque de signes égal. À cet endroit du texte, rien ne les distingue. Là où la norme laisse deux lectures ouvertes, cette page fait de même.

Pourquoi est-ce gratuit ?

Analyser un en-tête relève de la manipulation de chaînes, et cela se passe dans votre navigateur. Aucun serveur n’intervient, il n’y a donc rien à facturer ni de compte à créer.

Rien n’est envoyé. L’en-tête que vous collez ne quitte pas l’onglet.