Header Ads Widget

Ticker

6/recent/ticker-posts

Estrategias para integrar OAuth con puertas de enlace API

Asegurar sus API con OAuth demuestra que ha adoptado un modelo de seguridad maduro para su servicio. Sin embargo, configurar OAuth frente a su API no es una tarea trivial. Por lo general, hay muchas preguntas de arquitectura que deben responderse, más que el habitual "qué servidor de autorización elegir" o "cómo validar un token".
Los desarrolladores a menudo encuentran un problema cuando su solución consiste en una malla de servicios oculta detrás de una puerta de enlace API. ¿Debería participar API Gateway en el proceso? Si es así, ¿cómo puede ayudar?
En este artículo, demostraremos los diferentes enfoques para integrar OAuth con una puerta de enlace API. También mostraremos ejemplos de cómo estos enfoques se pueden usar con diferentes tipos de puertas de enlace API.

Dos estrategias para compartir tokens

Hay dos estrategias principales para compartir tokens de acceso con el mundo exterior:
  • Puede compartir el token web JSON generado por el servidor de autorización con cualquier cliente externo. En este escenario, las API utilizan el mismo token de forma externa e interna.
  • Puede compartir externamente un token opaco, que luego se intercambia por un JWT. Esto significa que un token opaco se usa externamente, pero internamente, sus API funcionan con un JWT.
Para obtener la mejor seguridad, la última opción suele ser la opción recomendada. En este escenario, no comparte ningún dato incrustado en su token de acceso con ningún cliente externo. El contenido del token de acceso está destinado a su API, pero si comparte un JWT con clientes externos, cualquiera puede decodificar el token y usar su contenido.

Problemas con la externalización de un JWT

Exponer un JWT con clientes externos puede generar problemas de privacidad y seguridad. Además, puede complicar su implementación. Cuando comparte un JWT con los clientes externos, los desarrolladores pueden decodificar los tokens y comenzar a usar su contenido, aunque los tokens están destinados solo a sus API. Esto podría llevar a situaciones en las que realizar cambios en el contenido del token puede romper las implementaciones existentes. El contenido de un token JWT se convierte en un contrato entre usted y los desarrolladores externos, y debe evitarse un cambio radical.
En el primer enfoque, la integración con API Gateway no es tan crucial. El Gateway simplemente reenvía el JWT a la API, que luego puede validarlo. Sin embargo, puede dejar que Gateway realice algunas de las tareas de validación.
Si decide implementar el enfoque recomendado, la integración adecuada con una puerta de enlace se vuelve más crítica. Para validar el token y leer su contenido, se debe obtener una representación JSON. El intercambio de un JWT lo puede realizar cualquier microservicio que utilice el token, pero puede aumentar innecesariamente la carga de tráfico y complicar la arquitectura, ya que cada servicio debería ser capaz de realizar el intercambio. Por eso es mucho mejor dejar que API Gateway maneje este intercambio. Ahora, exploremos diferentes formas de integración con puertas de enlace API.

Enfoques para la integración con puertas de enlace API

Se pueden utilizar algunos enfoques al realizar la integración con una puerta de enlace API. Dependerán de la estrategia de intercambio de tokens que elija.

Validación JWT

Si decide compartir JWT con el mundo exterior, es bueno que su API Gateway realice una validación del token entrante. El Gateway puede verificar la firma y realizar una validación inicial del contenido del token. Por ejemplo, podría evaluar la validez de los reclamos basados ​​en el tiempo, el emisor, la audiencia o algunos alcances requeridos.
Con la validación de JWT, una puerta de enlace API puede rechazar solicitudes con tokens no válidos, lo que limita el tráfico innecesario que de otro modo llegaría a su red interna.

Enfoque de token fantasma

El enfoque de token fantasma es una de las opciones que puede implementar si desea compartir tokens opacos externamente, pero usa JWT entre sus servicios internos. El token opaco se cambia por un JWT usando el patrón de introspección. La puerta de enlace API maneja este intercambio.
Con este enfoque, todos los servicios detrás del Gateway no tienen que realizar el intercambio ellos mismos, lo que limita el tráfico de la red. Una estrategia de Phantom Token es más fácil de mantener que hacer que todos los servicios manejen la introspección por sí mismos, ya que solo hay un punto desde el cual se consulta el servidor de autorización.

Enfoque de ficha dividida

El enfoque de token dividido es otra opción en la que se intercambia un token opaco en API Gateway por un JWT. En este patrón, el servidor de autorización divide el token generado en dos partes:
  • La firma del JWT
  • Jefe y cuerpo del JWT
Los clientes externos utilizan la firma como token opaco. La otra parte se envía a API Gateway junto con una firma hash, donde se almacena en caché. Ante una solicitud, API Gateway usa la parte entrante del token para buscar el resto en su caché y luego los vuelve a pegar para crear un JWT completo. El JWT resultante se agrega a la solicitud reenviada a cualquier servicio detrás del Gateway.
Este enfoque lo ayuda a limitar aún más el tráfico de red necesario para intercambiar el token opaco por un JWT, ya que no se requieren solicitudes adicionales al servidor de autorización.

Integraciones de API Gateway de ejemplo

Si decide integrar su solución OAuth con una API Gateway, el enfoque que elija dependerá del tipo de API Gateway que utilice. Hay muchas soluciones diferentes disponibles en el mercado y muchas empresas incluso están utilizando sus propias puertas de enlace patentadas. A continuación, examinaremos tres implementaciones comerciales de API Gateway.

Cloudflare: CDN como puertas de enlace

Cloudflare CDN proporciona suficiente funcionalidad para usarse como API Gateway distribuida. Es una puerta de enlace distribuida en varios centros de datos y regiones con acceso a un almacén de valores clave compartido y capaz de realizar modificaciones en las solicitudes y respuestas a través de funciones lambda.
Si usa Cloudflare o su puerta de enlace comparte características similares, el mejor enfoque sería utilizar el enfoque de token dividido , especialmente si el servidor de autorización se implementa en un número sustancialmente menor de ubicaciones. Gracias al enfoque de token dividido, la puerta de enlace no tiene que consultar al servidor de autorización en cada solicitud, lo que de otro modo ralentizaría considerablemente las solicitudes, dado que los servidores se encuentran en diferentes centros en todo el mundo.
Al elegir el enfoque de token dividido, una cosa a considerar es que la puerta de enlace necesita acceso a una caché compartida, una que el servidor de autorización pueda llenar fácilmente y que todas las instancias de puerta de enlace distribuidas puedan acceder a ella.

Nginx: pasarelas locales

Nginx es un ejemplo de API Gateway que se instala en las instalaciones. Si este es el caso de su solución de puerta de enlace, debería considerar implementar el enfoque de token fantasma , especialmente si el servidor de autorización que utiliza está instalado en los mismos centros de datos que la puerta de enlace.
En tal situación, la solicitud adicional necesaria para realizar una introspección del token no supondrá una gran sobrecarga para la solicitud. Es más, en este escenario, no necesariamente necesitará una caché compartida. Incluso si desea almacenar en caché las respuestas del servidor de autorización, cada una de las instancias de Gateway puede hacerlo por sí solo.

Google Apigee: una solución diversa

La respuesta a la pregunta de qué patrón de integración es mejor en un escenario particular depende de las características de Gateway en lugar del producto o proveedor concreto. Por ejemplo, en el caso de Google Apigee , puede utilizar la versión en la nube o instalar su instancia en las instalaciones. Por lo tanto, la elección del enfoque de integración de OAuth dependerá de la forma en que se utilice Apigee. En el entorno de la nube, probablemente será mejor utilizar el enfoque de token dividido , mientras que, con la instalación en las instalaciones, probablemente optaría por el enfoque de token fantasma .

Conclusión

Puede utilizar algunos enfoques diferentes para integrar OAuth con una API Gateway. La solución utilizada debe elegirse en función de las características de su API Gateway. Al decidir entre los estilos de integración de OAuth, dos puntos clave a considerar son si la puerta de enlace está distribuida o centralizada y si la puerta de enlace tiene un acceso razonable a una caché compartida.
Aunque compartir JWT con clientes externos puede parecer sencillo de implementar, recuerde que no es una buena práctica desde una perspectiva de seguridad. Debe evitarlo, ya que reduce su seguridad y privacidad y puede generar problemas con sus integradores.

Publicar un comentario

0 Comentarios