Header Ads Widget

Ticker

6/recent/ticker-posts

Autorización de servidor a servidor mediante TLS mutuo

 Aprovechar una arquitectura basada en tokens para el acceso a la API se está volviendo mucho más popular, como debería. Sin embargo, no todos los tokens se crean de la misma manera, y hay cosas que considerar al implementar una infraestructura de API basada en tokens.

Introducción

Un enfoque común es utilizar los denominados Bearer Tokens para autorizar a un cliente al realizar una llamada a la API. Pasar un token de portador suele ser suficiente para obtener acceso a la API. Sin embargo, los tokens al portador se parecen mucho al efectivo: si encuentra efectivo, puede usarlo para pagar bienes incluso si el efectivo no es suyo. Si obtiene un token de portador, puede usarlo para obtener acceso a la API.

Este artículo analizará cómo podemos fortalecer aún más el enfoque basado en token para la seguridad de API y la comunicación de servidor a servidor. Veremos algunos de los detalles definidos en OAuth 2.0 sobre el uso de la seguridad de la capa de transporte mutua para manejar algunas de las debilidades de los tokens de portador tradicionales.

¿Qué es Mutual TLS?

Transport Layer Security (TLS) ha reemplazado al Secure Sockets Layer (SSL) más conocido. Los navegadores web utilizan TLS para asegurar la conexión entre el cliente y el servidor que aloja la página web. Cuando se establece una conexión, el servidor web proporciona un certificado al cliente que se puede validar. Por tanto, se confía en la identidad del servidor.

El servidor también puede solicitar que el cliente se autentique para establecer una comunicación segura entre el servidor y el cliente. En ese caso, el cliente debe presentar un certificado al servidor, y el servidor validará ese certificado. Si la validación es exitosa, la confianza sería mutua, por lo tanto, Mutual TLS o mTLS.

TLS mutuo y OAuth 2.0

El TLS mutuo se puede aprovechar de diferentes formas y mediante diferentes tipos de sistemas. Echemos un vistazo a cómo OAuth 2.0 hace uso específico de esta tecnología.

RFC8705 es un RFC de OAuth 2.0 que define dos partes principales con respecto al uso de mTLS:

  • Autenticación del cliente
  • Tokens de acceso vinculados a certificados

Estos enfoques se usan comúnmente juntos. Entonces, analicémoslos y examinémoslos individualmente.

Autenticación del cliente

Hay varias formas diferentes para que un cliente se autentique en el Token Service. Un enfoque simple y común es utilizar un secreto compartido. Se trata básicamente de una contraseña que el cliente pasa al Token Service, junto con la identificación del cliente. Ambas partes se combinan, se codifican en base64 y luego se pasan como un encabezado en la solicitud del servidor de autorización.

Una opción más segura y flexible sería aprovechar mTLS para esta autenticación. En lugar de pasar un secreto compartido, el cliente envía la identificación. El servidor de autorización puede recoger el certificado del protocolo de enlace mTLS realizado entre el cliente (que llama al servidor o API) y el Servicio Token y luego usarlo para autorizar al cliente.

Un ejemplo de servidor a servidor

Revisemos cómo se vería esto en un escenario de servidor a servidor (o API a API).

Cuando el servidor A quiere comunicarse con el servidor B, el servidor A primero deberá obtener un token de acceso de un servicio de token. Al iniciar la comunicación con el Token Service, el servidor A puede usar mTLS para autorizarse a sí mismo para obtener un Token de acceso. Este token de acceso se utiliza posteriormente para autorizar la comunicación con el servidor B.

Pero recuerde el punto inicial sobre los tokens de portador: si el servidor A obtiene un token de portador en este proceso, todavía existe el riesgo de que el token se pierda o sea robado. En ese caso, otro servidor o cliente podría iniciar la comunicación con el servidor B. Tan pronto como se emita el token, no hay forma de vincular ese token al cliente al que se le entregó. Este token es ahora todo lo que se necesita para acceder al servidor B, independientemente de quién solicite el acceso.

Existe un enfoque más sólido para verificar al cliente que solicita un token de acceso. Aquí es donde entran en juego los tokens de acceso vinculados a certificados. Echemos un vistazo a los detalles de eso a continuación.

Tokens de acceso vinculados a certificados

Los tokens de acceso vinculados a certificados pueden aliviar las preocupaciones de seguridad en torno a los tokens de portador perdidos o robados. Estos tokens hacen posible que el servidor de recursos (Servidor B en nuestro ejemplo) verifique que el remitente del token es el mismo a quien se emitió el token.

El servicio de token puede aprovechar la información del certificado de la sesión mTLS para el cliente al que se está emitiendo el token (servidor A en nuestro ejemplo). En lugar de simplemente emitir un token de acceso como antes, el servicio de token codificará la huella digital (hash) del certificado del servidor A en el token y, por lo tanto, creará un token de acceso vinculado por certificado. Estos tipos de tokens también se conocen como tokens restringidos por poseedor de clave, prueba de posesión o remitente.

Este token de acceso vinculado por certificado ahora está específicamente vinculado al cliente que solicitó el token y al que se emitió el token. Ahora solo puede ser utilizado por ese cliente, y las limitaciones son que este cliente tendría que establecer una conexión mTLS con el servidor o API. Esta conexión protegida por mTLS debe establecerse utilizando el mismo certificado que se utilizó en la conexión con los servicios de token.

Servidor a servidor en un ecosistema de integración de socios

Se puede lograr una arquitectura sólida para manejar la comunicación de servidor a servidor combinando la autenticación de cliente y los tokens de acceso vinculados a certificados. Un caso de uso práctico sería dentro de un ecosistema de integración de socios.

El servicio de tokens centralizado emitiría tokens de una manera mucho más controlada, y se mitigaría el riesgo de que un socio acceda indebidamente a la información de otro socio. Los tokens emitidos están vinculados a un socio específico o incluso a un servidor o API en particular. Dependiendo de la infraestructura subyacente para manejar certificados, los tokens podrían ser utilizados técnicamente por varios sistemas o API que pertenecen a un socio específico. Sin embargo, el token aún estaría vinculado a un certificado específico. El certificado en sí no se compartiría entre diferentes socios del ecosistema.

Apliquemos esto a nuestro ejemplo.

Cuando el servidor A recibe un token de acceso vinculado por certificado y luego pasa este token al servidor B para establecer la comunicación, la huella digital del certificado se codifica directamente en el token. Esto se hace a través de un reclamo de confirmación estandarizado llamado cnf.

El servidor A también usa el mismo certificado en su comunicación mTLS con el servidor B. Esto le permite al servidor B verificar que el certificado usado para establecer que la sesión mTLS es el mismo que el certificado en el cnfreclamo en el token y verifica que el servidor A puede usarlo . Si el token se usa incorrectamente y algún otro servidor o API intenta usarlo, el servidor B no aceptará el token ya que habría una falta de coincidencia de certificado en el proceso de verificación.

Resumen

Los tokens de acceso tradicionales o los tokens de portador son muy comunes pero vienen con algunas vulnerabilidades. En una arquitectura típica basada en token, sería suficiente presentar un Bearer Token para obtener acceso. Sin embargo, esto significa que cualquier persona en posesión de un token válido puede acceder a los recursos protegidos.

El aprovechamiento de mTLS puede mejorar la seguridad en una arquitectura basada en tokens. El uso de mTLS en el paso en el que un cliente (servidor) solicita un token de acceso de un Token Service le permite al Token Service emitir un token que está vinculado a ese cliente (certificado) específicamente y no puede ser utilizado por nadie más. Esto se puede validar de forma segura cuando ese cliente solicita acceso a los recursos en otro servidor (o API) verificando que el certificado del token sea el mismo que se utilizó para establecer la sesión mTLS.

Este enfoque es muy adecuado para entornos con requisitos de alta seguridad, especialmente en escenarios con comunicación de servidor a servidor y diferentes entornos de socios que solicitan información entre sí.

Publicar un comentario

0 Comentarios