Authorization

Uso

La cabecera de solicitud Authorization sirve para obtener acceso a un recurso protegido y normalmente se envía después de que se informe al cliente de que el acceso está restringido. Por ejemplo, tras recibir del servidor una respuesta HTTP 401 Unauthorized que incluye la cabecera WWW-Authenticate, el cliente envía sus credenciales de esta forma.

Nota

Los navegadores eliminan la cabecera Authorization cuando una solicitud se redirige a un origen distinto. Así se evita la fuga de credenciales cuando una redirección apunta a un servidor de terceros. Este comportamiento está definido en el WHATWG Fetch Standard y es compatible con todos los navegadores modernos. Las aplicaciones que dependen de cabeceras Authorization a través de redirecciones entre orígenes deben gestionar una nueva autenticación en el destino final. Herramientas como curl, Python Requests y el cliente HTTP de Go siguen la misma convención.

authentication-scheme

authentication-scheme es una directiva obligatoria, acompañada de parámetros opcionales específicos del esquema. El esquema define el método de codificación de las credenciales. Entre los enfoques habituales están Basic, Bearer, Digest y Negotiate.

Ejemplo

En este ejemplo, el cliente utiliza el esquema de autenticación Basic. Como parámetro obligatorio, las credenciales son un par username:password codificado en base64.

Authorization: Basic RXhhbXBsZTphaQ==

Un token Bearer es habitual en las API con OAuth 2.0. El token es una cadena opaca o un JWT firmado emitido por un servidor de autorización.

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Diagnóstico

Los fallos de autorización suelen manifestarse como respuestas 401 inesperadas o como credenciales descartadas de forma silenciosa.

Credenciales eliminadas en una redirección entre orígenes. Los navegadores y los clientes HTTP quitan la cabecera Authorization cuando una solicitud se redirige a un origen distinto. La solución es enviar las credenciales directamente al destino final o volver a autenticarse una vez completada la redirección. Inspeccione las cadenas de redirección con curl -L -v para confirmar en qué punto desaparece la cabecera.

Errores de codificación Base64 en la autenticación Basic. La cadena codificada debe contener exactamente un carácter de dos puntos que separe el nombre de usuario y la contraseña. La falta de los dos puntos o un valor codificado dos veces produce un token corrupto que el servidor rechaza. Verifique el valor en bruto con echo -n “user:pass” | base64 y compárelo con el valor de la cabecera enviada en la solicitud.

Token Bearer caducado o mal formado. Los tokens incluyen una declaración de caducidad y los servidores rechazan con 401 los que han expirado. Decodifique un JWT en jwt.io o con echo "" | base64 -d para inspeccionar el campo exp. La lógica de renovación del token debe ejecutarse antes de que este caduque, no después de que el servidor rechace la solicitud.

Bucle de 401 cuando el servidor omite WWW-Authenticate. El servidor devuelve 401 pero no incluye la cabecera WWW-Authenticate, con lo que el cliente no recibe ninguna indicación sobre el esquema esperado. Revise las cabeceras de respuesta con curl -I https://example.re/resource y confirme que la configuración del servidor incluye la cabecera. En nginx, la directiva auth_basic la añade automáticamente. Los backends personalizados deben establecerla de forma explícita.

La comprobación previa de CORS bloquea la cabecera Authorization. Las solicitudes entre orígenes que llevan Authorization desencadenan una solicitud OPTIONS de comprobación previa. El servidor debe responder a esa comprobación con Access-Control-Allow-Headers: Authorization. Un valor ausente o incorrecto hace que el navegador bloquee la solicitud antes de enviar las credenciales. La pestaña Network de DevTools muestra la comprobación previa como una entrada OPTIONS independiente.

curl envía las credenciales al endpoint equivocado. Ejecutar curl -H “Authorization: Bearer …” con -L sigue las redirecciones, pero elimina la cabecera en los saltos entre orígenes. Use curl -v sin -L para enviar la cabecera al endpoint exacto, o pase —location-trusted para forzar el reenvío de las credenciales a través de las redirecciones (úselo con precaución y solo en dominios de confianza).

Basic frente a Bearer

Basic y Bearer son los dos esquemas de autenticación más comunes y responden a casos de uso diferentes.

Basic envía un par username:password codificado en Base64 en cada solicitud. La codificación es trivialmente reversible, por lo que HTTPS resulta obligatorio. Las credenciales son estáticas y están ligadas a una cuenta de usuario, de modo que una contraseña comprometida obliga a cambiar la contraseña misma. Basic funciona bien en herramientas internas e integraciones sencillas, donde la gestión de tokens añadiría una complejidad innecesaria.

Bearer utiliza tokens opacos (a menudo JWT) emitidos por un servidor de autorización. Los tokens caducan, llevan permisos acotados por ámbito y se pueden revocar sin cambiar la contraseña subyacente. Bearer es el mecanismo estándar para las API y los flujos de OAuth 2.0. Un token robado tiene una vida útil y un ámbito limitados, lo que reduce el radio de impacto frente a una contraseña filtrada.

Ambos esquemas transmiten las credenciales en texto claro dentro del valor de la cabecera. Ninguno aporta cifrado por sí mismo. HTTPS es necesario sea cual sea el esquema elegido.

Una solicitud de API entre orígenes con un token Bearer mediante la Fetch API.

fetch('https://api.example.re/data', {
  headers: {
    'Authorization': 'Bearer eyJhbGci...'
  }
})