WWW-Authenticate
Uso
Cuando un cliente solicita un recurso protegido sin credenciales válidas, el servidor responde con un código de estado 401 e incluye la cabecera WWW-Authenticate. Esta cabecera transporta uno o varios desafíos de autenticación, cada uno de los cuales especifica un esquema y los parámetros que el cliente necesita para construir credenciales válidas.
Tras recibir el desafío, el cliente reenvía la solicitud con una cabecera Authorization que contiene las credenciales formateadas según el esquema seleccionado. El servidor valida las credenciales y, si son correctas, devuelve el recurso solicitado.
Varios desafíos en una misma respuesta permiten al servidor ofrecer varios esquemas a la vez. El cliente elige el esquema más robusto que ambas partes admiten. Los desafíos aparecen en líneas de cabecera independientes o en una única línea separada por comas.
La cabecera equivalente para la autenticación a nivel de proxy es Proxy-Authenticate, que desencadena una respuesta 407 en lugar de una 401.
scheme
El esquema identifica el método de autenticación. Los esquemas registrados los mantiene la IANA. A continuación se describen los esquemas más habituales en la práctica.
Basic envía un par username:password codificado en Base64. El esquema acepta un parámetro realm y un parámetro charset opcional (normalmente UTF-8).
Bearer autentica mediante un token de acceso opaco, emitido por lo general a través de un flujo de OAuth. El esquema admite los parámetros realm, scope y error. El parámetro scope enumera los permisos que debe llevar el token. El parámetro error comunica motivos de fallo concretos como invalid_token o insufficient_scope.
Digest mejora a Basic aplicando un hash a las credenciales con un nonce proporcionado por el servidor, lo que evita que la contraseña viaje en texto claro. Entre los parámetros obligatorios están realm, nonce y qop (calidad de protección). Los parámetros opcionales incluyen algorithm, opaque y stale.
Negotiate inicia una autenticación basada en SPNEGO, respaldada normalmente por Kerberos o NTLM en entornos empresariales. El esquema transporta un token SPNEGO codificado en Base64 mientras la negociación está en curso.
realm
El parámetro realm es una cadena opcional que define el espacio de protección. Su valor ayuda a los usuarios a identificar qué credenciales se necesitan. Un servidor que protege distintas áreas asigna a cada una un valor de realm diferente.
token68
La sintaxis token68 es una codificación de credenciales alternativa permitida por el marco de autenticación de HTTP. El valor utiliza un conjunto de caracteres restringido (alfanuméricos, -, ., _, ~, +, /) con relleno = opcional al final.
Ejemplo
Un servidor que protege un recurso con autenticación Basic devuelve un desafío que incluye el nombre del realm mostrado al usuario.
WWW-Authenticate: Basic realm="Staging Environment"Un desafío de token Bearer comunica el scope requerido y señala un token caducado mediante el parámetro error.
WWW-Authenticate: Bearer realm="api.example.re", scope="read write", error="invalid_token"Un desafío Digest incluye el nonce generado por el servidor y la configuración de calidad de protección.
WWW-Authenticate: Digest realm="admin@example.re", nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v", qop="auth", algorithm=SHA-256Un servidor que ofrece varios esquemas los enumera para que el cliente elija la opción más robusta.
WWW-Authenticate: Negotiate
WWW-Authenticate: Bearer realm="api.example.re"
WWW-Authenticate: Basic realm="api.example.re"Un intercambio completo de autenticación Basic. El cliente solicita primero un recurso protegido sin credenciales:
GET /admin HTTP/1.1
Host: example.reEl servidor responde con 401 y un desafío Basic:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="API"El cliente reintenta con una cabecera Authorization que contiene el par username:password codificado en Base64:
GET /admin HTTP/1.1
Host: example.re
Authorization: Basic dXNlcjpwYXNzEl servidor valida las credenciales y devuelve el recurso:
HTTP/1.1 200 OK
Content-Type: text/html