También disponible en: English · Português · Français · العربية
WWW-Authenticate: todos los desafíos, no solo el primero
Pega la cabecera de una respuesta 401 y verás cada desafío, cada parámetro y lo que dice el estándar al respecto.
¿Qué es la cabecera WWW-Authenticate?
Cuando un servidor responde a una petición con un 401 Unauthorized, tiene que indicar cómo podrías autenticarte. Eso es la cabecera WWW-Authenticate: una lista de desafíos, cada uno con el nombre de un esquema —Basic o Bearer, por ejemplo— y normalmente con parámetros como un realm. El cliente elige un esquema que entienda y responde con una cabecera Authorization.
La cabecera parece sencilla y no lo es. El propio RFC 9110 lo dice, y aconseja a los agentes de usuario tener especial cuidado al analizarla, porque un valor puede contener más de un desafío, cada desafío puede llevar una lista de parámetros separados por comas, y la cabecera puede enviarse varias veces. El separador entre desafíos y el separador entre parámetros son el mismo carácter, así que nada indica localmente cuál de los dos es una coma concreta.
Esta página implementa la gramática de la especificación, muestra todos los desafíos y no solo el primero, y nombra cada parámetro con la forma en la que llegó. Analiza el desafío que envía el servidor. Deliberadamente no descodifica una cabecera Authorization, que es la respuesta que lleva tus credenciales.
Cómo usarla
- Pega la cabecera. Con o sin el nombre del campo, y una por línea si la respuesta envió más de una. Varias cabeceras y un único valor separado por comas son equivalentes según el estándar, así que dan la misma respuesta.
- Lee los desafíos. Cada uno muestra su esquema, si ese esquema está en el registro de IANA, y una tabla de parámetros que indica si cada valor llegó como token sin comillas, como cadena entrecomillada, o entrecomillado con un escape dentro.
- Mira las notas de abajo. Cubren aquello sobre lo que el estándar tiene una opinión: más de un desafío por línea, un esquema sin registrar, una coma suelta, un parámetro repetido, o un esquema conocido que no aparece primero.
Por qué esta cabecera es difícil de analizar
La especificación da un ejemplo resuelto y, de forma poco habitual, te dice la respuesta. Muestra un desafío Basic con un realm igual a simple, seguido de un desafío Newauth con un realm igual a apps, un parámetro type y un parámetro title, todo en una línea. Y afirma que eso son dos desafíos, y que type y title pertenecen al segundo.
Deducirlo exige un token de anticipación. Cuando el analizador llega a type, nada de lo anterior indica si esa palabra abre un tercer desafío o nombra un parámetro del segundo. Solo lo decide el carácter siguiente: un token seguido de un signo igual es un parámetro, y un token seguido de cualquier otra cosa es un esquema nuevo. Si te saltas esa regla obtienes un análisis verosímil y sencillamente equivocado.
El mismo ejemplo esconde una segunda trampa. Su parámetro title es una cadena entrecomillada que contiene a su vez comillas, escapadas con barras invertidas. Un analizador construido sobre la idea de buscar de una comilla a la siguiente se detiene donde no debe, y una coma dentro de un valor entrecomillado parte en dos un desafío que debía quedar entero.
No es una preocupación teórica. Mientras se construía esta página se probaron dos analizadores publicados con el ejemplo de la propia especificación. Ninguno devolvió la respuesta que la especificación imprime: uno informó de un solo desafío con los dos realms fusionados, y el otro no devolvió nada en absoluto, pese a manejar sin problema un desafío Basic normal. El estándar lo anticipaba, al advertir de que enviar más de un desafío en una línea puede no ser interoperable, y por separado de que muchos clientes fallan con un esquema que no reconocen.
Lo que esta página no hará a propósito
No descodificará una cabecera Authorization. WWW-Authenticate viaja desde el servidor y es pública: es la pregunta. Authorization viaja desde el cliente y lleva la respuesta, que en el caso de Basic es tu usuario y tu contraseña con un disfraz muy fino. Si pegas una aquí, la página te lo dice y se detiene, sin descodificarla. Es la misma postura que este sitio mantiene en su descodificador de JWT, que no tiene campo para la clave de firma: pegar una credencial en cualquier parte es una costumbre que conviene no adquirir, ni siquiera en una página que funciona por completo en tu propio navegador.
Te dice lo que dice la gramática, no lo que hará tu cliente. Un desafío puede ser perfectamente válido y aun así ser ignorado, porque un navegador solo implementa un puñado de esquemas y una biblioteca puede detenerse en el primer desafío que reconoce. Nada de esto se ha medido contra un navegador, y esta página no afirma nada sobre ninguno.
Tampoco juzga la ausencia de realm. Es tentador tratarlo como un error, pero el estándar describe el parámetro realm como reservado para los esquemas que quieran indicar un ámbito de protección, no como algo que todo desafío deba llevar. Donde la especificación se abstiene de exigir, esta página se abstiene de avisar.
Hay un caso genuinamente ambiguo que se informa en lugar de resolverse. Un signo igual final tras un nombre suelto, como un desafío que termina en realm=, encaja en la gramática de un token opaco tan bien como en la de un parámetro que se quedó sin valor, porque esa producción es una serie de caracteres seguida de cualquier número de signos igual. En ese punto del texto nada los distingue. Donde el estándar deja dos lecturas abiertas, esta página también.
¿Por qué es gratis?
Analizar una cabecera es manipulación de cadenas, y ocurre en tu navegador. No hay servidor de por medio, así que no hay nada que facturar ni cuenta que crear.
No se sube nada. La cabecera que pegas no sale de la pestaña.