¿Qué es la autenticación HTTP?

La autenticación es un protocolo utilizado en la comunicación HTTP para verificar la identidad de un cliente antes de otorgarle acceso a un recurso específico en la web. Es una medida de seguridad dentro del protocolo HTTP diseñada para proteger a usuarios y empresas en el entorno online. Cuando la autenticación se realiza en el edge, mejora significativamente tanto la velocidad como la seguridad del proceso, aumentando en última instancia la credibilidad e ingresos de una empresa.

Autenticación HTTP

La autenticación es un proceso de control de acceso que verifica la identidad de un cliente antes de otorgarle acceso a un recurso específico en la web. Como resultado, la autenticación sirve como una capa de seguridad extra en las comunicaciones HTTP.

La solicitud inicial de un cliente es típicamente anónima, lo que significa que carece de cualquier información de identificación para confirmar la identidad del cliente. Esto puede ser arriesgado, especialmente para recursos sensibles como detalles bancarios, ya que se podría otorgar acceso sin restricciones a cualquier usuario. Aquí es donde entra la autenticación: para regular el acceso, el servidor rechaza las solicitudes anónimas e indica que se requiere autenticación del cliente. La información de autenticación intercambiada entre el servidor y el cliente se transmite a través de encabezados.

Los principios básicos de la autenticación se describen anteriormente, pero dado que diferentes tipos de recursos requieren diferentes niveles de seguridad, la complejidad de la autenticación también varía. Exploraremos esto más a fondo en la sección sobre esquemas de autenticación.

¿Cómo funciona la autenticación HTTP?

RFC7235 describe cómo el protocolo HTTP proporciona un marco general para el control de acceso y la autenticación. Admite un conjunto diverso de esquemas de autenticación de desafío-respuesta que permiten a un servidor desafiar una solicitud del cliente y habilitar al cliente para proporcionar credenciales de autenticación.

¿Qué es la autenticación de desafío-respuesta?

En la autenticación de desafío-respuesta, el servidor emite una solicitud, conocida como desafío, y el cliente debe proporcionar una respuesta válida para ser autenticado. Un ejemplo común de autenticación de desafío-respuesta es la autenticación por contraseña, donde el desafío del servidor es una solicitud de contraseña, y la respuesta válida del cliente es la contraseña correcta.

Encabezados de autenticación

Los encabezados son utilizados ya sea por el servidor para definir el método de autenticación (encabezados de respuesta) o por el cliente para proporcionar credenciales de autenticación (encabezados de solicitud). Veamos cómo funcionan:

Encabezados de respuesta

Hay dos encabezados que el servidor puede enviar: WWW-Authenticate y Proxy-Authenticate.

Ambos definen el método de autenticación que debe utilizarse para que el cliente obtenga acceso a un recurso. Deben especificar qué esquema de autenticación usar para que el cliente que desea autorización sepa cómo proporcionar las credenciales.

WWW-Authenticate

El encabezado WWW-Authenticate indica el esquema de autenticación y los parámetros aplicables al recurso objetivo.

Sintaxis: WWW-Authenticate: type realm=

Donde:

• type: es el tipo de autenticación solicitada.
• realm: es el ámbito de protección, el área a proteger.

Ejemplo de encabezado WWW-Authenticate:

WWW-Authenticate: Basic realm="Access to the internal site"

Proxy-Authenticate

El encabezado Proxy-Authenticate define el método de autenticación que debe utilizarse para obtener acceso a un recurso que está detrás de un servidor proxy. Este encabezado consiste en al menos un desafío que indica los esquemas de autenticación y parámetros aplicables al servidor proxy.

Sintaxis: ​​Proxy-Authenticate: realm=

Ejemplo de encabezado WWW-Authenticate:

Proxy-Authenticate: Basic realm="Access to the internal site"

Encabezados de solicitud

El cliente puede enviar dos encabezados: Authorization y Proxy-Authorization.

Ambos contienen las credenciales para autenticar al cliente con un servidor de origen o un servidor proxy. Las credenciales pueden ser codificadas o cifradas, dependiendo del esquema de autenticación utilizado.

Authorization

El encabezado Authorization permite al cliente autenticarse con un servidor de origen generalmente después de recibir una respuesta 401 Unauthorized del servidor. Este encabezado contiene credenciales con información para la autenticación del cliente para el área del recurso que se está solicitando.

Sintaxis: Authorization:

Donde:

• credentials: es la información para la autenticación. Consiste en el nombre de usuario, seguido de dos puntos (:) y la contraseña del usuario. Esta secuencia luego se codifica con el método de codificación base64.

Nota: Base64 es un grupo de esquemas de codificación binario-a-texto similares que representan datos binarios en un formato de cadena ASCII, convirtiéndolo a una representación en base 64.

Ejemplo:

Si el navegador usa Azion como nombre de usuario y edgecomputing como contraseña, el valor del campo es la codificación base64 de Azion:edgecomputing, es decir QXppb246ZWRnZWNvbXB1dGluZw==. Entonces el encabezado de Authorization será:

Authorization: Basic QXppb246ZWRnZWNvbXB1dGluZw==

Proxy-Authorization

El encabezado Proxy-Authorization permite al cliente autenticarse en un proxy generalmente después de que el servidor responde con un estado de 407 Proxy Authentication Required. Este encabezado contiene credenciales con información para la autenticación del cliente en el proxy y/o el área del recurso que se está solicitando.

Sintaxis: Proxy-Authorization:

Ejemplo de encabezado Proxy-Authorization:

Proxy-Authorization: Basic QXppb246ZWRnZWNvbXB1dGluZw==

Esquemas de autenticación

Basic

Como se mostró anteriormente, el servidor solicita un nombre de usuario y contraseña en una solicitud para autenticar a un usuario en un esquema de autenticación básica. Esta información se codifica utilizando codificación base64.

Una desventaja de la autenticación básica es que no es segura, por lo que debe usar protocolos de seguridad HTTPS/TLS para esta comunicación. Cuando la información es confidencial o valiosa, es necesario utilizar un esquema de autenticación más seguro.

Bearer

La autenticación Bearer utiliza tokens de seguridad llamados tokens de portador. En este esquema, se otorga acceso al portador del token.

El token es una cadena cifrada, generalmente generada por el servidor en respuesta a una solicitud de inicio de sesión. El cliente debe enviar este token en el encabezado Authorization cuando solicita acceso a recursos protegidos.

Sintaxis: Authorization: Bearer

Digest

La autenticación Digest también se basa en el mecanismo de desafío-respuesta. El desafío que el servidor envía al cliente es un valor nonce, un número aleatorio que solo puede usarse una vez. La respuesta del cliente debe contener un hash con el nombre de usuario, contraseña, valor nonce, método HTTP y URL solicitada. Este formato de hash de datos es más complejo y dificulta que la información del usuario sea robada y reutilizada, y se desarrolló como una alternativa para reemplazar la autenticación básica, que no es un esquema seguro.

El cliente debe enviar el hash en el encabezado Authorization cuando solicita acceso a recursos protegidos.

Sintaxis: Authorization: Digest username=

Ejemplo de autenticación Digest:

El cliente quiere tener acceso a un documento seguro a través de una solicitud GET. El URI del documento es https://www.azion.com/blog/index.html. El cliente y el servidor saben que el nombre de usuario para este documento es Azion y la contraseña es edgecomputing.

1. La primera vez que el cliente solicita el documento, el servidor no envía el encabezado de autorización y responde con:

   HTTP/1.1 401 Unauthorized

   WWW-Authenticate: Digest

   realm="registered_users@azion.com"

   qop="auth,auth-int",

   nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

   opaque="5ccc069c403ebaf9f0171e9517f40e41"

2. El cliente responderá con una nueva solicitud, incluyendo los siguientes encabezados:

   Authorization: Digest username="Azion"

   realm="registered_users@example.com"

   nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"

   uri="/blog/index.html"

   qop=auth

   nc=00000001

   cnonce="0a4f113b"

   response="6629fae49393a05397450978507c4ef1"

   opaque="5ccc069c403ebaf9f0171e9517f40e41"

HTTP Origin-Bound Auth (HOBA)

La autenticación HTTP Origin-Bound (HOBA) es un esquema que no se basa en contraseñas, sino en firmas. Además, ofrece características extras como gestión de credenciales y sistema de cierre de sesión. Esto hace que este esquema sea más seguro ya que elimina el riesgo de filtración de contraseñas al no haber una base de datos de verificación de contraseñas del lado del servidor.

Los clientes pueden autenticarse en servidores utilizando el protocolo HTTP o un programa de autenticación Javascript utilizando claves público-privadas.

Sintaxis: Authorization: HOBA result="kid"."challenge"."nonce"."sig"

Donde result es la combinación de los valores kid, challenge, nonce y sig. El valor de result es una cadena separada por puntos que incluye la firma y se envía en el valor del encabezado de autorización HTTP utilizando la sintaxis mostrada anteriormente. El valor sig es la versión codificada en base64url de la salida binaria del proceso de firma. Los valores kid, challenge y nonce también están codificados en base64url.

Flujo de autenticación HOBA:

1. Para empezar, el cliente determina si ya tiene una clave pública para autenticarse o debe generar una.
2. El cliente luego hace una conexión al servidor, anticipando que el servidor solicitará una autenticación basada en HOBA, que debe hacerse suscribiéndose a un blob de información.
3. El servidor envía un desafío que puede confirmarse en un encabezado HTTP y el cliente debe responder con una firma, habiendo dado previamente la clave pública al servidor. El servidor determina la CPK (Clave Pública del Cliente) utilizando el KID (Identificador de Clave) para decidir si reconocer la CPK. Si la CPK es reconocida, el proceso de autenticación está completo.

Mutual

La autenticación mutua realiza tanto la autenticación del cliente como del servidor. Dado que la autenticación ocurre en ambas direcciones, este esquema también se conoce como autenticación bidireccional. Una de las características de la autenticación mutua es que el cliente y el servidor deben proporcionar certificados digitales a través del protocolo TLS (Transport Layer Security).

Sintaxis:

El cliente envía una solicitud al servidor con:

Authorization: Mutual user="name"

kc1="..."

El servidor responde con:

Authorization: Mutual sid=123

vkc="..."

Donde user es la cadena de identificación del usuario, kc1 es la clave de verificación del cliente al servidor, sid es la clave de identificación de sección, y vkc es la clave de verificación del servidor al cliente.

Flujo de autenticación mutua:

1. El cliente solicita un recurso sin ningún intento de autenticación.
2. Si el recurso solicitado está protegido por el protocolo de autenticación Mutual, el servidor responderá con un mensaje solicitando autenticación (401-INIT).
3. El cliente procesa el cuerpo del mensaje y espera a que el usuario ingrese el nombre de usuario y la contraseña. Si el nombre de usuario y la contraseña están disponibles, el cliente enviará un mensaje con intercambio de claves autenticado (req-KEX-C1) para iniciar la autenticación.
4. El servidor busca información de autenticación del usuario dentro de su base de datos de usuarios. Luego crea un nuevo identificador de sesión (sid) que se utilizará para identificar conjuntos de mensajes que lo siguen, y responde con un mensaje que contiene un valor de intercambio de claves autenticado por el servidor (401-KEX-S1).
5. El cliente y el servidor calculan un “secreto de sesión” compartido utilizando los valores intercambiados en los mensajes de intercambio de claves. Solo cuando utilizan credenciales secretas generadas a partir de la misma contraseña es que los valores del secreto de sesión coincidirán. Este secreto de sesión se utilizará para la autenticación de acceso de cada par individual de solicitud/respuesta a partir de ese momento.
6. El cliente enviará una solicitud con un valor de verificación de autenticación (req-VFY-C) calculado a partir del secreto de sesión generado por el cliente. El servidor verificará la validez del valor de verificación utilizando su propia versión del secreto de sesión.
7. Si el valor de verificación de autenticación del cliente es correcto, el cliente tiene la credencial basada en la contraseña esperada, es decir, la autenticación fue exitosa. El servidor responderá con un mensaje de éxito (200-VFY-S).

Si el valor de verificación del cliente es incorrecto (por ejemplo, porque la contraseña proporcionada por el usuario era incorrecta), el servidor responderá con un mensaje 401-INIT (el mismo mensaje que el utilizado en 2).

Negotiate

La autenticación Negotiate es un mecanismo de autenticación de Microsoft Windows que utiliza Kerberos como su proveedor de autenticación subyacente. Kerberos funciona en un sistema de concesión de tickets para autenticar usuarios a recursos y requiere el uso de tokens SPNEGO GSSAPI.

Sintaxis: Authorization: Negotiate

Flujo de autenticación Negotiate:

1. El cliente solicita acceso a un documento protegido sin ningún intento de autenticación.

2. El servidor responde con:

   HTTP/1.1 401 Unauthorized

   WWW-Authenticate: Negotiate

3. El cliente obtendrá las credenciales del usuario utilizando el mecanismo SPNEGO GSSAPI para identificar y generar un mensaje GSSAPI que se enviará al servidor en una nueva solicitud con el encabezado de autorización:

   HTTP/1.1 GET dir/index.html

   Authorization: Negotiate a87421000492aa874209af8bc028

4. El servidor decodificará los datos GSSAPI y los pasará al motor SPNEGO GSSAPI en la función gss_accept_security_context. Si el contexto no está completo, el servidor responderá con un estado 401 y un encabezado WWW-Authenticate que contiene los datos GSSAPI:

   HTTP/1.1 401 Unauthorized

   WWW-Authenticate: Negotiate 749efa7b23409c20b92356

5. El cliente decodificará los datos GSSAPI, los pasará a gss_Init_security_context y devolverá los nuevos datos GSSAPI al servidor:

   HTTP/1.1 GET dir/index.html

   Authorization: Negotiate 89a8742aa8729a8b028

6. Este ciclo puede continuar hasta que el contexto de seguridad esté completo. Cuando el valor de retorno de la función gss_accept_security_context indica que el contexto de seguridad está completo, puede proporcionar datos de autenticación para devolver al cliente. Si el servidor tiene más datos GSSAPI para enviar al cliente para completar el contexto, se enviarán en un encabezado WWW-Authenticate con la respuesta final que contiene el cuerpo HTTP:

   HTTP/1.1 200 Success

   WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca

7. El cliente decodificará los datos GSSAPI y los proporcionará a gss_init_security_context utilizando el contexto para este servidor. Si el estado es exitoso en el gss_init_security_context final, la respuesta puede ser utilizada por la aplicación.

OAuth

La autenticación OAuth (abreviatura de Open Authorization) es un protocolo de autorización de estándar abierto que permite a servidores y servicios no relacionados permitir el acceso de terceros al recurso utilizando tokens de acceso en lugar de compartir sus credenciales. Este proceso también se conoce como “acceso seguro delegado”.

Un ejemplo muy simple de este esquema de autenticación es cuando un usuario inicia sesión en un sitio web (el tercero) y el sitio web ofrece iniciar sesión utilizando cuentas de otros sitios web/servicios, como Google o Facebook, lo que significa que no necesitas ingresar tus contraseñas. Cuando haces clic en el botón vinculado al otro sitio, el otro sitio te autentica y el sitio al que te estabas conectando originalmente inicia sesión utilizando el permiso obtenido del segundo sitio.

En este esquema, participan los siguientes agentes:

• Propietario del recurso: entidad capaz de otorgar acceso a un recurso protegido. Cuando el propietario del recurso es una persona, se le llama usuario final.
• Servidor de recursos: El servidor que aloja los recursos protegidos. El acceso a él se realiza a través de tokens.
• Cliente: aplicación que solicita recursos protegidos, a través de la autorización del propietario.
• Servidor de autorización: servidor que emite tokens de acceso al cliente, después de que ha sido autenticado y autorizado.

Sintaxis: Authorization: OAuth realm="Example",

oauth_consumer_key="C_KEY",

oauth_token="TOKEN",

oauth_signature_method="HMAC-SHA1",

oauth_signature="SIGNATURE",

oauth_timestamp="TS",

oauth_nonce="NONCE",

oauth_version="1.0"

Flujo de autenticación OAuth:

1. El cliente solicita autorización del propietario del recurso. La solicitud de autorización puede hacerse directamente al propietario del recurso (como se muestra en la imagen anterior), o preferiblemente indirectamente a través de la autorización del servidor como intermediario.
2. El cliente recibe una concesión de autorización, que es una credencial que representa la autorización del propietario del recurso, expresada utilizando uno de los cuatro tipos de concesión definidos en la especificación, o utilizando un tipo de concesión de extensión. El tipo de concesión de autorización depende del método utilizado por el cliente para solicitar autorización y los tipos compatibles con el servidor de autorización.
3. El cliente solicita un token de acceso cuando se autentica con el servidor de autorización y presenta la concesión de autorización.
4. El servidor de autorización autentica al cliente y valida la concesión de autorización y, si es válida, emite un token de acceso.
5. El cliente solicita el recurso protegido del servidor de recursos y se autentica presentando el token de acceso.
6. El servidor de recursos valida el token de acceso y, si es válido, acepta la solicitud.

VAPID

La autenticación VAPID (Identificación Voluntaria del Servidor de Aplicaciones) está diseñada para permitir que los sitios se autentiquen con servidores de push de forma independiente. Los sitios web pueden enviar notificaciones push sin saber en qué navegador se está ejecutando. Esta es una mejora significativa sobre la implementación de un protocolo push diferente para cada plataforma.

Es posible que el cliente incluya su identidad en un token firmado con las solicitudes que realiza. La suscripción puede ser utilizada por el servicio push para restringir el uso de una suscripción push a un solo servidor de aplicaciones.

Sintaxis: Authorization: vapid

t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczov L3B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1h aWx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_ HLGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,

k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs

Donde t es un token JWT (JSON Web Token) generado por el cliente y k es la clave privada (codificada en base64url) que firma este token.

¿Qué es JSON Web Token?

Actualmente existen muchas técnicas que se pueden implementar para controlar el acceso a recursos en línea. Una de las más comunes es el uso de algún tipo de token de acceso, generado por aplicaciones para garantizar que solo los usuarios autenticados puedan utilizar ciertos recursos, como API o archivos multimedia. Y una de esas soluciones modernas es el JSON Web Token (JWT).

Los JWT están criptográficamente protegidos contra manipulaciones. Además, con ellos, en lugar de almacenar el estado del token en la base de datos, es posible codificar este estado directamente en el ID del token y enviarlo al cliente. Por ejemplo, puedes serializar los campos del token en un objeto JSON, codificarlo con base64url para crear una cadena que se puede utilizar como ID del token. Cuando el token se presenta de nuevo a la API, todo lo que necesitas hacer es decodificar el token y analizar el JSON para recuperar los atributos de la sesión.

Mejorando la seguridad para contenido restringido con JWT

La protección del contenido restringido contra el acceso no autorizado se puede lograr a través de JSON Web Tokens (JWT), que proporcionan un método escalable y eficiente para el control de acceso. La tecnología JWT permite una autenticación segura para API y contenido privado como videos, cursos en línea e imágenes.

Los JWT operan sin necesidad de validación de base de datos, lo que los hace adecuados para aplicaciones de alto desempeño. Sin embargo, debido a que los JWT suelen ser más grandes que los ID de sesión, pueden afectar el desempeño de la red cuando se incluyen en cada solicitud. Ejecutar procesos de autenticación en el edge ayuda a mitigar este problema al manejar la validación más cerca de los usuarios, reduciendo la latencia y garantizando un control de acceso eficiente.

Medidas de seguridad adicionales pueden mejorar aún más la autenticación basada en JWT, como definir tiempos de vencimiento para las claves y gestionar permisos a través de una combinación de ID de claves y secretos. Al procesar solicitudes de autenticación en el edge, la validación ocurre antes de llegar a la infraestructura de origen, eliminando la necesidad de un servidor de autenticación centralizado y mejorando tanto la seguridad como el desempeño.

Este enfoque garantiza que el contenido restringido permanezca protegido mientras se mantiene un acceso rápido y confiable para los usuarios autorizados.