Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo manejar el procesamiento por lotes con OAuth 2.0


 Recientemente, en el canal de API nórdicas, algunas personas nos preguntaron: ¿cómo maneja los procesos por lotes que están protegidos con OAuth 2.0? Las solicitudes por lotes son las que se ejecutan automáticamente o se programan para que se repitan de forma recurrente.

Por lo general, usamos OAuth para confirmar la identidad del usuario para las llamadas a la API, pero el problema es que OAuth 2.0 no está realmente diseñado para el procesamiento por lotes. Por lo general, OAuth se usa de manera más sincrónica , por ejemplo, envía una solicitud y obtiene una respuesta inmediata. Al tratar con OAuth, normalmente tiene el canal de comunicación abierto.

Los procesos por lotes, por otro lado, a menudo son asincrónicos , lo que significa que es posible que no tenga un canal abierto ya que las operaciones ocurren en una escala de tiempo más larga. Aunque muchos proveedores de API se están moviendo hacia microservicios RESTful llamativos, el comportamiento asincrónico en las API móviles o arquitecturas de servicios empresariales todavía existe, y debe tratarse con un método seguro y escalable que considere la identidad de la solicitud en cada paso del camino.

Un problema común es que cuando creamos solicitudes que desencadenan un proceso en un momento posterior, estos desencadenantes a menudo se realizan como trabajos por lotes. Por ejemplo, si por la noche el sistema de un banco activa todas las transferencias que están esperando en la cola, este es un trabajo por lotes. Si considera la operación completa, la solicitud original para realizar la transferencia es más una solicitud asincrónica.

Supongamos que tiene un entorno asincrónico, donde una API activa otro servicio para realizar una acción, como en una cola de mensajes . Cuando finalmente se activa la acción, a menudo la identidad de la llamada final no se combina con la llamada inicial de ninguna manera. Usar un flujo típico de OAuth aquí es incómodo, ya que los tokens de OAuth están pensados ​​para ser de muy corta duración, lo que significa que no deben almacenarse en la cola para un trabajo por lotes indefinido. Muchas organizaciones simplemente no se dan cuenta de lo propenso que es una cola o un mecanismo de distribución a atacar , a menudo realizado por actores internos. Para evitar esta vulnerabilidad, en este artículo proporcionaremos una solución potencial para implementar OAuth en todo el proceso de solicitud por lotes para mejorar los estándares de verificación y la validación de identidad.

Caso de ejemplo: depósito bancario recurrente

Supongamos que necesita activar un depósito recurrente de $ 50 en una cuenta de ahorros cada mes durante el próximo año. Primero, consideremos cómo esta solicitud se maneja típicamente usando un flujo OAuth normal en un entorno con API RESTful HTTP y una arquitectura de estilo de microservicios.

Flujo de trabajo normal de OAuth (simplificado)

  1. El usuario primero inicia una solicitud en el sitio web del Cliente .
  2. A continuación, el cliente enviará un token de acceso a una puerta de enlace API .
  3. La API de puerta de enlace a continuación, pasar el token de acceso al servidor de autorización (el servidor de OAuth).
  4. El servidor de autorización verifica que el token de acceso sea ​​correcto y envía un token de acceso JWT a API Gateway .
  5. La API de puerta de enlace a continuación, pasa a la JWT Token de acceso a un microService que tendrá que actuar como un disparador cada mes para un trabajo continuo. A esto lo llamaremos API Trigger Savings .
  6. Luego, el trabajo se inserta en una Cola , lo que activa un segundo microservicio que mueve dinero a la cuenta. Lo llamaremos API Do Savings .
  7. La cola se restablece y el paso 6 se repite cuando ha transcurrido el tiempo correcto.

Básicamente, en este modelo usamos dos microservicios: uno para activar el pago y otro para mover el dinero. Lo que esto significa es que debes poner el trabajo en una cola, para que más tarde, cuando haya transcurrido el tiempo adecuado, active una API Do Savings para transferir dinero a una cuenta. Luego, la cola se actualiza.

¿Parece bien y elegante? Bueno, no lo es.

El problema con las solicitudes por lotes

Un problema con este proceso por lotes es que se vuelve difícil verificar la identidad en cada paso, desde la primera solicitud hasta la solicitud que inicia la API Do Savings. Cuando deja que un proceso por lotes se pudra en la cola, pierde la pista del control de identidad por completo, lo que aumenta enormemente el riesgo de ataque.

Estrechamente relacionados están los requisitos de especificación del token de acceso. En este caso, nuestro token de acceso probablemente sea un token de portador . Como se recomienda en la Especificación de OAuth 2.0 , un token de portador debe tener una vida útil muy corta; algo así como 5 a 15 minutos es una práctica estándar.

Como hemos escrito antes, debe tratar los tokens al portador como dinero en efectivo : cualquiera que robe este token puede enviarlo. Al enviar este token a una API, confía implícitamente en que nadie más se apoderó del token en el camino. Dado que la llamada está destinada a comportarse de forma sincrónica, confía en que se mantendrá segura hasta que expire, ya que la comunicación cliente / servidor está protegida. Sin embargo, cuanto mayor sea la vida útil del token, mayor será la probabilidad de que sea robado.

Los tokens de portador de OAuth son el token preferido para mantener la simplicidad del cliente. Sin embargo, no podemos poner un token de portador en la cola ya que la vida útil sería demasiado larga. Almacenado de forma asincrónica, un pirata informático podría potencialmente reorganizar la cola y asignarle diferentes tokens. O incluso más probablemente, un error en el procesamiento interno podría confundir los tokens y los mensajes a los que pertenecen simplemente por accidente. Dado que esta infraestructura es bastante común en todos los contextos empresariales, el uso de tokens de esta manera podría poner a una empresa en grave peligro.

Entonces, ¿cómo creamos un token especializado que sea relevante y esté continuamente vinculado a las operaciones por lotes? La solución consiste en hacer que el token de portador esté más vinculado a la solicitud . Dado que OAuth 2.0 se trata de llevar la complejidad al servidor en lugar de al cliente , es probable que tengamos que hacer algunas maniobras en el lado del servidor ... Prepárese para un flujo de OAuth salpicado de un poco de magia de procesamiento por lotes.

OAuth Server + Scopes + Meta Scope al rescate

Desarrolladores de aplicaciones, desarrolladores web ... nadie realmente quiere tocar la seguridad y, a menudo, evita enfrentarse a ella. Pero nuestra solución puede no ser tan compleja; radica en agregar otra capa de verificación con el servidor de autorización.

Cuando un servidor recibe un token de acceso JWT , puede contener permisos de cierto tipo, que se denominan ámbitos . Estos alcances son realmente muy poderosos y se pueden usar para activar funcionalidades, delinear ciertos niveles de acceso a la cuenta y más.

En nuestro ejemplo de ahorro, podríamos usar un alcance para activar ahorros continuos para permitir iniciar el búfer. Esto diría que puede poner algo en el búfer; podría leer el estado de su cuenta, o algo similar, para comenzar a procesar un pago.

Este ámbito particular se comportaría como un meta ámbito . Queremos transformar nuestro token de portador en algo menos peligroso, algo que se pueda usar para activar más transacciones, de modo que una vez que ingrese a la cola, solo pueda realizar una acción y no se pueda alterar de ninguna manera.

Para procesar esto, necesitamos algo como una API de ahorro de activación , que verificaría si el token tiene un alcance de pago de activación. Si es así, prepararía un nuevo token para enviar a la cola. Para ello, llamará al servidor OAuth con el token de acceso entrante, así como con el contenido que detalla la solicitud.

El objetivo es reducir los permisos del token de acceso en una sola acción que pueda descansar de forma segura en la cola . Esto requiere un poco más de acción por parte del servidor. Tomará los datos de la operación de ahorro y los firmará, utilizando la clave del servidor OAuth para crear una firma a partir de ese contenido. Luego responderá con un token de acceso que es más de larga duración (LL), que llamaremos JWT Access Token LL .

Dentro del JWT Access Token LL está la firma de la operación específica. Ahora, podemos enviar esta solicitud con el JWT Access Token LL y almacenarla en la cola. Al hacerlo, podemos especificar el tiempo de vida ( TTL ) de la operación para que sea de larga duración. Básicamente, usamos el token de acceso de corta duración para firmar un mensaje; el JWT Access Token LL contiene metadatos además de una firma para que pueda asociarse con el trabajo en cola.

Flujo de trabajo actualizado

Ciertamente, hay otras formas de lograr esto, pero aquí hay un flujo de trabajo paso a paso utilizando el proceso descrito anteriormente:

  1. El Cliente (el sitio web o la aplicación móvil) envía un token de acceso a API Gateway . Este token tiene algo así como un alcance 'trigger_continuous_savings' para delinear el tipo de transacción que se está llevando a cabo.
  2. La API de puerta de enlace envía el testigo de acceso a la OAuth servidor para su verificación.
  3. El servidor OAuth verifica y envía un token de acceso JWT firmado junto con la solicitud de contenido a API Gateway .
  4. La API de puerta de enlace envía el JWT Token de acceso a una API de activación de ahorro .
  5. La API de Trigger Savings envía el token de acceso JWT y la solicitud de contenido al servidor OAuth para su verificación.
  6. El servidor OAuth envía un nuevo JWT Access Token LL a la API Trigger Savings que puede durar mucho tiempo durante el tiempo total que debería estar iniciando ahorros. Contiene una firma, TTL de 1 año y un alcance para permitir ahorros de $ 50. También envía una solicitud de contenido para asegurarse de que el token se emite para este trabajo en particular.
  7. La API Trigger Savings pasa el ** JWT Access Token LL ** a la cola .
  8. En el momento adecuado, la cola activa la API Do Savings y pasa la clave privada para su verificación.
  9. La API Do Savings luego envía dinero a la cuenta del usuario.

Haga clic para ver una versión más grande

Este flujo coloca cierta complejidad adicional en el servidor para aceptar parámetros adicionales. Además, el flujo anterior supone que usamos ámbitos dinámicos . Incluiríamos un ámbito de acción como save_money, así como un ámbito que determina el amounten la creación de nuestro JWT. En este ejemplo específico, pasamos un TTL de un año, con la cantidad recurrente de $ 50 para ahorrar.

Dado que la única acción para la que se puede usar el token final es cuando se envía una solicitud a la API Do Savings, se vincula íntimamente con la solicitud. No podría editar la cantidad en el token, porque está usando una firma que solo el servidor de autorización puede producir. Dado que cada API recibe una clave pública, comparten la confianza con el servidor OAuth. En otras palabras, existe una confianza implícita entre la API Trigger Savings y la API Do Savings .

Entonces, cuando la API Do Savings recibe esa solicitud, puede preguntar al servidor de autorización : "¿es válido?" Puede solicitarlo directamente o hacer que el AS distribuya su clave pública, de modo que pueda usar la clave pública para verificar la firma y validar los datos actuales. Por lo tanto, puede unir las cosas de esta manera.

Lea Cómo controlar la identidad del usuario dentro de microservicios para obtener una introducción sobre el uso de ámbitos JWT

La seguridad se amplifica

Claro, podría devolver un token de portador de mayor duración con un alcance menor, pero el problema es que cuando los datos están en la cola, no hay más acoplamiento que el que están en la misma ranura. Con nuestro flujo actualizado, lo que ha cambiado es que el trabajo en cola específico ahora está vinculado a un token específico que se ha creado a partir de un token de acceso de corta duración que tenía derecho a crear trabajos.

Las colas generalmente no se tratan como un servidor OAuth: los servidores de autorización suelen ser un componente altamente seguro de su red, mientras que, por otro lado, muchas personas pueden tener acceso a una cola. Es posible que algunos ni siquiera se den cuenta de que esto podría ser un objetivo de ataque, pero ciertamente lo son.

Sin esta capa de verificación adicional, le estaría dando a un hacker tiempo suficiente para ingresar y reorganizar la cola. Este podría ser incluso un empleado descontento, que tiene acceso directo. Desde una perspectiva de auditoría, podrían reemplazar fácilmente tokens u ocultar ciertas operaciones.

La creación de un token de acceso de larga duración está más en sintonía con la especificación OAuth 2.0 combina sus datos de manera más estrecha para evitar vulnerabilidades de identidad. Dado que OAuth 2.0 no usa específicamente tokens de portador de esta manera, al colocar la firma de la solicitud en el JWT Access Token LL, lo transformamos en un token vinculado , lo que nos permite seguir usando OAuth 2.0.

Posibles desventajas

Cada vez que es necesario realizar una transacción, se pone un poco más de peso en el servidor de autorización, pero no mucho. Como mínimo, se verifican los tokens. La operación adicional es la verificación de la firma sobre el contenido de la operación que se supone que debe realizar, que se almacena dentro del token de acceso.

Compare esta operación adicional del servidor con la alternativa; hacer que el cliente firme los datos al principio y hacer que la gestión de claves se extienda hasta el cliente. Esto implicaría clientes mucho más pesados, especialmente para aquellos ubicados fuera de la organización.

Por último, aquí hay muchos detalles sobre quién puede pedir qué. Debemos reconocer que necesitaremos construir nuestras infraestructuras de seguridad que llevarán a cabo los flujos de trabajo. Un último riesgo a considerar: tendrá que confiar en un intermediario, es decir, en el servidor de autorización para respetar la criptografía asimétrica.

Conclusión

Este tipo de operación debe considerarse para cualquier cosa con una cola de servicio o un bus de distribución. Especialmente ahora que los servicios de suscripción con cargos de pago continuo están de moda, aprender a verificar la identidad y los permisos en cada paso es vital.

¿Tiene experiencia o problemas en el manejo de la gestión de identidades de API en el contexto de operaciones por lotes? ¡Nos encantaría leer tus comentarios a continuación!

Publicar un comentario

0 Comentarios