Header Ads Widget

Ticker

6/recent/ticker-posts

Desacople la identidad del usuario del diseño de la API para crear microservicios escalables

 

Desacople la identidad del usuario del diseño de la API para crear microservicios escalables

¿Cómo se pueden proteger las API, los microservicios y los sitios web? Una forma de hacerlo es centrándose en la identidad : saber quién es la persona que llama y qué puede hacer la persona que llama con sus datos. Sin embargo, con demasiada frecuencia, los proveedores dependen demasiado de la identidad social del usuario y la combinan demasiado estrechamente con el diseño de sus API.

Como OAuth no se autentica por sí mismo, la forma en que se estructuran estos flujos significa que el acceso a la API a menudo depende en última instancia de los inicios de sesión sociales de los usuarios, que es una dependencia desfavorable que en realidad disminuye la seguridad y la escalabilidad de la API. Las API están mucho mejor protegidas con un proxy entre la API y el mecanismo de autenticación, utilizando ámbitos que delinean el tipo de acceso que otorga la API.

En esta publicación veremos por qué las API y los microservicios deben desacoplar la identidad del usuario de sus diseños y cómo llevar a cabo esta implementación. Revisaremos algunos flujos de muestra y explicaremos brevemente cómo se pueden usar los alcances de OAuth para crear una API más valiosa y con conocimientos. Siguiendo estas señales, el resultado final resaltará las prácticas de gestión de acceso e identidad (IAM) de vanguardia dentro del diseño de la API real, utilizando de hecho datos de identidad para asegurar todo el ciclo de vida de la API.

AAA

Cuando se realiza una llamada a la API, debemos saber quién realizó la solicitud y si están autorizados a leer y acceder a los datos solicitados. La Gestión de Identidad y Acceso (IAM) también se describe como  AAA ; un importante inicialismo compuesto por:

  • Autenticación : Validación de que el usuario es quien dice ser.
  • Autorización : Validación del usuario, su aplicación y privilegios.
  • Auditoría : contabilidad del comportamiento del usuario, registro de metadatos como a qué se accede, cuándo se accede, con qué dispositivo y más.

El almacenamiento en caché de los registros de usuarios es excelente, pero no evita las solicitudes mal formadas al servidor desde el principio. No queremos desperdiciar recursos, por lo que las solicitudes de verificación deben procesarse lo antes posible en la canalización del código. Por lo tanto, normalmente bloquea esto con un proxy . PERO, ¿cómo se asegura de que el proxy sepa qué hacer? ¿Cómo le indicamos al proxy que descifre qué usuario o aplicación está accediendo a los datos y a qué datos puede acceder?

Esta publicación se inspiró en esta charla de Jacob Ideskog de Curity . Mírelo describir cómo desacoplar la identidad del usuario del diseño de API:

Descripción general del flujo de OAuth

Puede estar pensando, solo use OAuth , problema resuelto. Sí, OAuth es un protocolo necesario dentro del flujo de trabajo de seguridad, pero OAuth no puede autenticarse ; un servidor separado debe decirle a OAuth quién es el usuario. Para comprender hacia dónde nos dirigimos, aquí hay una descripción general rápida de un flujo de OAuth simple. Para revisar, los actores son:

  • Propietario del recurso (RO): el usuario
  • Cliente : la aplicación, dispositivo móvil, servidor o sitio web que solicita datos de la API.
  • Servidor de autenticación : el servicio de inicio de sesión que autentica a los usuarios
  • Servidor OAuth (AS): también llamado servidor de autorización
  • Resource Server (RS): la API que proporciona datos

Supongamos que hemos creado un servidor de correo con una API que proporciona información para que un cliente de aplicación de terceros pueda ordenar los correos electrónicos de una manera mejorada. En nuestro tutorial asumiremos que la aplicación usa Google+ como servicio de autenticación. Hay variantes de estos flujos, pero un flujo de OAuth simple para este escenario sería:

  1. El cliente primero solicita acceso al servidor OAuth .
  2. continuación, el servidor OAuth delega la responsabilidad de autenticación a un servidor de autenticación de terceros (Google).
  3. El usuario ingresa credenciales con el servidor de autenticación para autenticarse.
  4. El servidor de autenticación le dice al servidor OAuth que la autenticación fue exitosa, emitiendo un token al servidor OAuth .
  5. El servidor OAuth envía el token al cliente .
  6. El cliente usa el token para acceder a los recursos del servidor de recursos .
  7. El servidor de recursos verifica con el servidor OAuth que el token es válido.
  8. El servidor de recursos (API) envía los datos a la aplicación del cliente .
Gif de flujo de OAuth estándar

Flujo de OAuth estándar

Para un análisis más profundo, consulte nuestro Análisis profundo de OAuth y OpenIDConnect

Descripción de la información de inicio de sesión

Teniendo en cuenta estos tres actores importantes ( servidor de recursos (la API), servidor de autorización (OAuth), servidor de autenticación (inicio de sesión)), necesitamos saber quién solicita acceso, qué tipo de aplicación solicita acceso y los privilegios que tiene el usuario. Tener en cuenta el proceso de inicio de sesión es importante, ya que completa la imagen de estos flujos.

Entonces, ¿cómo describe la información de inicio de sesión ? Lo haces con Federación , un concepto que ha existido durante algún tiempo. Cuando describe la autenticación entre sistemas federados, normalmente registra lo siguiente:

  • subject: quién inició sesión
  • auth_time: cuando se produjo el inicio de sesión
  • acr: Abreviatura de Referencia de clase de contexto de autenticación, esto estipula cómo ocurrió el inicio de sesión. Aquí es donde las partes comunicantes pueden describir y comprender la forma de autenticación utilizada para el inicio de sesión, ya sea Facebook, Google+ u otros.

A menudo, con esta información en la mano, una API simplemente examinará el acrregistro y proporcionará los recursos adecuados en función de él. Sin embargo, cuando esto sucede, el servidor de autenticación y el servidor OAuth esencialmente delegan la responsabilidad al inicio de sesión social, en este caso Google+.

La gran falacia de este enfoque es que crea una dependencia directa de su API a un inicio de sesión social. Tener un flujo de trabajo que dependa de un solo autenticador como Google puede crear suposiciones en el comportamiento estándar que se eliminan por completo si decide utilizar otro inicio de sesión en su lugar, como Facebook o Twitter. ¿Y qué sucede cuando tiene más de 150 microservicios implementados que dependen de la autenticación de esta manera? Escalar microservicios que dependen de un único autenticador social puede crear dolores de cabeza innecesarios.

Lea también: Cómo controlar la identidad del usuario dentro de microservicios

La solución está en la abstracción

Para resolver esto, lo que necesitamos crear es un método de abstracción estandarizado. La solución es la creación de una pared entre el API y el servidor de autenticación y OAuth servidor . Si le da sabor a OAuth y lo empareja con un servicio de autenticación, tiene las herramientas para hacerlo.

Tenga en cuenta que hay miles de formas únicas de autenticar un usuario (código PIN, número de teléfono, voz, datos biométricos), por lo que es imposible crear un estándar que combine todos los estilos de autenticación. Sin embargo, utilizando este concepto, podemos rastrear y emplear datos de identidad útiles con OAuth Tokens . OAuth define que sus tokens contienen tales puntos de datos:

  • subject: El usuario
  • client ID: La aplicación
  • scope: Para qué se puede utilizar el token
  • expiration: Cuánto tiempo es válido el token de acceso

Diseño de una API con ámbitos desde abajo hacia arriba

Ubicado dentro del token de OAuth, el alcance es un punto de datos interesante que probablemente haya usado antes. El alcance especifica la extensión de los tokens y son similares a los permisos enumerados en una IU de consentimiento. Son extremadamente útiles, ya que los ámbitos se pueden usar para delinear niveles de acceso a la API. Además, OAuth no especifica que debe dar los mismos alcances que está solicitando; si el alcance cambia, simplemente debe notificar al cliente / usuario. Para los diseñadores de administración de acceso, esto nos otorga mucho poder y flexibilidad en la forma en que manejamos los ámbitos y la identidad. Veremos que crear una API con ámbitos integrados en el diseño puede ser extremadamente útil.

Creemos una API de muestra para ver de qué estamos hablando. Digamos que estamos diseñando una API de artículos que aprovecha la plataforma de un periódico. La API proporciona acceso a los clientes que leen el contenido, así como a los empleados que escriben el contenido. El periódico también tiene un plan de suscripción premium, por lo que la API también debería reflejar este nivel de acceso más alto. Básicamente, la API debe proporcionar la capacidad de leer, agregar, eliminar y actualizar artículos.

Por otro lado, ArticleReader es una aplicación que consume la API de artículos . Puede pensar en ArticleReader como el cliente en nuestro flujo de OAuth. Como es un cliente lector, tendrá un alcance limitado sin capacidad de edición.

Entonces, ¿cómo creamos permisos? Hacerlo significa que definimos los ámbitos en la API. La hermosa magia aquí es que asignamos estos alcances con diferentes fortalezas de la siguiente manera:

ALCANCEFUERZACOMPORTAMIENTO
articles_regular_readDébilPermite la autenticación social
articles_premium_readMedioLa autenticación social está bien, pero debe ser un cliente
articles_writeFuerteEl usuario debe ser un empleado y el inicio de sesión debe realizarse a través de una red integrada.

Deje que OAuth filtre estos ámbitos

A continuación, dejamos que el servidor OAuth filtre el acceso a la API en función de estos ámbitos. Dado que podemos cambiar nuestros alcances a lo largo del proceso, cuando ArticleReader envía una solicitud con un articlesalcance, un nuevo flujo se vería así:

  1. El cliente ArticleReader realiza una solicitud al servidor OAuth enviando un readalcance básico .
  2. continuación, el servidor OAuth delega la responsabilidad de autenticación a un servidor de autenticación de terceros (Google).
  3. El usuario ingresa credenciales con Google, el servidor de autenticación , para autenticarse.
  4. El servidor de autenticación le dice al servidor OAuth que la autenticación fue exitosa y envía un token OAuth . Dentro del token hay información que afectará los alcances, a saber, el ACR (que en este caso es social ) y el asunto (el nombre de usuario).
  5. El servidor OAuth verifica su base de datos de clientes para ver si el nombre de usuario es de hecho un cliente.
  6. En este caso, encuentra el nombre de usuario entre los archivos del cliente y, por lo tanto, le otorga al cliente un token de acceso con los alcances articles_regular_readarticles_premium_readTenga en cuenta que el servidor OAuth también le dice al cliente qué alcances devolvió, ya que estos eran diferentes del alcance inicial que se solicitó. Sin embargo, tenga en cuenta que el Cliente no debe, bajo ninguna circunstancia, analizar el token real; solo está destinado a que lo consuma la API.
  7. El cliente ArticleReader luego envía el token de acceso al servidor de recursos de la API de artículos En este punto ahora sabemos muchas más cosas que simplemente el ACR social .
  8. El servidor de recursos verifica con el servidor OAuth que el token es válido.
  9. El servidor de recursos (API) envía los datos a la aplicación del cliente .
Flujo de OAuth actualizado mediante ámbitos

Flujo de OAuth actualizado usando ámbitos

Con este flujo, la API se vuelve mucho más informada. Al devolver diferentes ámbitos en el paso 6, le damos al cliente la capacidad de personalizar la interfaz de usuario y habilitar o deshabilitar ciertas funciones. Aún mejor es que, dado que el poder del alcance le dijo que se usó suficiente fuerza durante la autenticación, a la API ahora ni siquiera le importa qué autenticación se realizó originalmente. Dotado de datos sobre el cliente, el usuario y el acceso otorgado por los ámbitos, puede filtrar datos de manera eficaz a los canales adecuados mediante un esquema de aprovisionamiento mejorado.

El proxy solo acepta solicitudes válidas

El último paso para desvincular la autenticación social del diseño de la API es construir un proxy para separar nuestra API del mecanismo de autenticación. El resultado final es un proxy que solo permite el acceso cuando se cumplen los siguientes criterios:

  • El token existe
  • El token es válido
  • El token contiene uno o más ámbitos. Para la API de artículos, sería uno o más de los siguientes:
    • articles_regular_read
    • articles_premium_read
    • articles_write

Ahora tenemos una interfaz API más segura y estricta que solo permite el acceso una vez que se cumplen estas tres reglas, lo que bloquea a los usuarios no registrados en el proxy.

Conclusión: separe la API de la autenticación

Para construir una infraestructura de API escalable que sea ideal para microservicios , debe diseñar sus API de manera que las separe de la autenticación. El uso de alcances para asignar los permisos y definirlos en su API puede crear una plataforma sólida que lo proteja e informe mejor como proveedor de API.

Los beneficios de este enfoque también incluyen:

  • La seguridad general de la API se mejora con la abstracción;
  • El control de identidad de API ahora asigna sus niveles de acceso, lo que permite una aplicación sencilla para los modelos comerciales freemium ;
  • Este patrón es fácil de comprender e implementar;
  • La construcción de alcances en el diseño de API en lugar de la autenticación de terceros significa libertad de cualquier método de autenticación sin molestar a las API con todos los detalles;
  • Puede ayudar a separar las API de socios privadas, públicas, complementando la estrategia de la plataforma y agregando potencial comercial;
  • Podría usarse para informar el análisis de uso;
  • Dado que los departamentos de marketing tienen una gran demanda de que los clientes viajen sin problemas, esto proporciona un tiempo de comercialización más rápido cuando se trata de autenticación.

Pero quizás el punto más crítico es que se necesita un solo patrón para el diseño de microservicios . Esto aumenta la capacidad no solo de crear API, sino también de compartir fácilmente el conocimiento de identidad en una organización, lo que aumenta la capacidad de mantenimiento del servicio a lo largo del tiempo. La autenticación es un objetivo en movimiento, mientras que las API pueden no serlo.

Publicar un comentario

0 Comentarios