Header Ads Widget

Ticker

6/recent/ticker-posts

Diseño de tokens para una mejor arquitectura de API

 

Diseño de tokens para una mejor arquitectura de API

Los pequeños detalles como los tokens a veces pueden ayudar a estructurar arquitecturas API complejas. En esta pieza vamos a echar un vistazo a diferentes arquitecturas y, en última instancia, veremos cómo una mejor forma de diseñar tokens puede conducir a un resultado de mayor rendimiento.

Considere el papel de los tokens dentro de dos facetas del diseño de API, control de acceso y estabilidad de datos . Cada vez que nos ocupamos del diseño de API, necesariamente debemos gestionar el control de acceso y proporcionar estabilidad a los datos. Estos dos pilares se pueden desglosar de la siguiente manera:

  • Control de acceso
    • Identidad de usuario (autenticación)
    • Permiso (autorización)
  • Estabilidad de datos
    • Documentación precisa
    • Formato de respuesta consistente (control de versiones de API)
    • Disponibilidad y tiempo de actividad del servicio

La máxima aquí es:

Diseñe el control de acceso de manera que facilite la estabilidad de los datos.

Con esto en mente, ahora podemos revisar tres arquitecturas API arquetípicas.

1: El feliz accidente

Este es el diseño más común, que de hecho no es ningún diseño. Básicamente, si tienes un sitio web, ¡tienes una API! Con solo una simple solicitud de cURL y algo de raspado, puede obtener los datos que necesita directamente desde el sitio web.

Aquí un artículo muy detallado sobre cómo comenzar con el web scraping, y varias trampas y trampas explicadas en detalle. Aunque esto parece muy sencillo y rápido, hay que tener mucho cuidado con la ONU accidentes felices. De hecho, hay dos problemas principales con este "diseño":

  1. Cambios en el formato de datos
  2. Trabajar con datos privados (usuario y contraseña)

El primer punto es un problema de estabilidad de datos : cualquier cambio en la implementación de un nuevo sitio web puede romper repentinamente nuestra API. El segundo punto, aunque generalmente se puede solucionar, solo hace que la arquitectura sea mucho más complicada. Cuando se trata de la autorización (generalmente nombre de usuario / correo electrónico y contraseña), hacer un raspado web simple no funcionará de inmediato, pero tendremos que lidiar con las páginas de registro o inicio de sesión primero (¡y espero que no haya captcha !)

Consulte también: Asegurar su flujo de datos con cifrado P2P

2: La recepción

El diseño de la recepción representa una arquitectura de modelo de puerta de enlace . Es decir, todas las solicitudes de API deben pasar primero por la puerta de enlace , que luego llama al servicio real solicitado. La puerta de enlace generalmente gestiona la autenticación , la limitación de velocidad y posiblemente también otras cosas (por ejemplo, análisis, supervisión del rendimiento, etc.). Esto a veces se denomina Gateway-as-a-service, y hay bastantes proveedores en la web. Un ejemplo interesante es Tyk, que está desarrollado en Go y es completamente de código abierto .

Como cualquier arquitectura , el uso de un enfoque de puerta de enlace tiene propiedades tanto buenas como malas.

Ventajas:
- Fácil de iterar
- Fácil de desarrollar rápidamente
- Acorta el tiempo de salida al mercado

Contras:
- Punto único de falla
- Potencialmente costoso
- Restricciones arquitectónicas rígidas


Vea a R. Kevin Nelson discutir este tema en un evento de APIs nórdicas

3: Metrópolis

Una arquitectura orientada a servicios (SOA) es un patrón arquitectónico en el diseño de software de computadora en el que los componentes de la aplicación brindan servicios a otros componentes a través de un protocolo de comunicaciones, generalmente a través de una red. Los principios de la orientación al servicio son independientes de cualquier proveedor, producto o tecnología.

MSDN

Este tercer tipo de arquitectura de API es la arquitectura orientada a servicios o SOA. Con SOA, cada servicio maneja su propia autenticación, limitación de velocidad, credenciales de API, etc. Podemos imaginar que esta arquitectura es como si cada servicio tuviera su propia recepción.

La idea detrás de Metropolis es que si cada servidor sabe cómo manejar las puertas de enlace API y también puede manejar su propia autenticación, entonces las solicitudes API pueden afectar los servicios directamente (tanto interna como externamente).

Aquí es donde el diseño de tokens resulta útil para ayudar a los servicios a manejar su propia autenticación. Pero, ¿qué es exactamente la autenticación? Cuando hablamos de autenticación, generalmente queremos hacer estas dos preguntas:

  1. ¿Puede este usuario realizar esta acción ?
  2. ¿ Esta aplicación puede realizar esta acción en nombre de este usuario ?

Pero hay más que eso. Consulte nuestro libro electrónico dedicado a la seguridad de API para comprender las sutilezas detrás de la autenticación, autorización, delegación y federación.

Asegurando-la-fortaleza-API-blog-post-CTA-01

Diseño de tokens

Comencemos revisando qué es un token . Aquí está del Diccionario Oxford:

Token : una cosa que sirve como representación visible o tangible de un hecho, cualidad, sentimiento, etc.

En el ámbito del diseño de API, un token es una cadena simple que representa a un usuario que hemos validado previamente. Ahora, hay dos formas de utilizar un token. Vamos a empezar por el camino antiguo.

El viejo camino:

Esta sería una forma típica de manejar tokens para una API, y si ha trabajado con cualquier tipo de API, probablemente esté familiarizado con este diseño:

  1. Generar una sesión aleatoria o una clave de token
  2. Almacenar datos de carga útil en un almacén de datos
  3. Use la clave de sesión o token para buscar la carga útil

Aunque este diseño puede sonar familiar, hay un problema obvio con él. Es decir, necesitamos validar las credenciales de usuario cada vez, lo que significa enviar nuestro token y luego realizar una búsqueda para cada solicitud. Básicamente, se envía a la recepción para cada solicitud. Funciona, pero probablemente no sea la forma más eficiente de hacerlo. ¿Cómo se puede eliminar este cuello de botella y tener un diseño más eficaz?

Con esto en mente, podemos ver cómo el diseño de tokens y la criptografía pueden llevarnos a una mejor arquitectura.

Descubra por qué las claves de API ≠ Seguridad de API

La mejor manera:

Podemos usar el cifrado para tener un diseño de token que evite por completo las búsquedas en la base de datos. Comencemos con el proceso completo y luego lo revisaremos en detalle:

  1. Minimice los datos de carga útil. La carga útil solo debe contener información mínima, como identificación de usuario, marcas de tiempo y posiblemente otros códigos de identificación.
  2. Serialice la carga útil.
  3. Firma la carga útil. Hay diferentes formas de hacerlo, pero normalmente se hace con HMAC .
  4. Encriptar carga útil + combo de firma
  5. Base64 codifica el resultado del cifrado
  6. ¡El resultado codificado es tu token!

Para todo esto, básicamente solo necesitamos una biblioteca con un token de generación y métodos de token de análisis . Hay 3 beneficios obvios de este diseño :

  • Sin búsquedas en la base de datos
  • No hay requisitos de almacenamiento para la mayoría de los tokens.
  • Análisis de tokens de tiempo constante

Y solo hay dos requisitos para poder analizar los tokens correctamente:

  • Cifrado compartido y claves MAC entre servicios internos
  • Bibliotecas criptográficas correctamente implementadas

Revocación y cierre de sesión

Un pequeño problema es que la revocación y el cierre de sesión se vuelven problemáticos con este enfoque. Dado que no hemos almacenado el token en ningún lugar, ¿cómo podemos revocar su permiso?

Para responder a eso, obtengamos algunos detalles sobre los datos en una carga útil típica:

  • Identificación de usuario
    • ID, nombre, avatarURL
  • Metadatos de token
    • PublishedAt, expires, sessionID

Un token como este tiene aproximadamente las siguientes características:
- Alrededor de 220 bytes de tamaño
- Los datos de carga útil están encriptados
- Se requieren dos claves secretas para analizar o generar los tokens. Esto protege contra la suplantación de identidad y la fuga de datos.

Ahora volvamos a cerrar la sesión. Para la mayoría de las API, la revocación es más un caso extremo que una tarea común. No importará mucho entonces que al usar este diseño, el proceso de revocación será un poco más lento de lo habitual. En resumen, tendremos que usar un canal de retorno (por ejemplo, una cola de mensajes) que informará a todos nuestros servicios que un token específico ha sido revocado. Luego, cada servicio debe almacenar en la memoria (o en un caché de almacenamiento de datos rápido como Memcache o Redis) que el token ha sido revocado. De hecho, es mucho más fácil y rápido almacenar solo los tokens revocados en lugar de almacenar todos y cada uno. De esta manera, en lugar de verificar si un token es válido, podemos verificar si una carga útil ha sido desautorizada.

Por lo tanto, el proceso para la revocación y cierre de sesión del permiso del token es:

  1. Propagar la desautorización a los nodos a través de un canal de retorno
  2. Espere a que termine la propagación antes de responder

Conclusión

El diseño cuidadoso de nuestro enfoque de tokens puede tener efectos significativos en nuestra arquitectura general de API. Comenzamos viendo cómo cualquier sitio web puede convertirse en una API a través de un simple web scraping ( el feliz accidente ). Luego revisamos cómo funciona una arquitectura de recepción como una puerta de enlace, y sus pros y contras. Luego pasamos a una arquitectura orientada a servicios real , y cómo una forma diferente de diseñar tokens utilizando algunas técnicas de cifrado puede conducir a un nuevo diseño completamente libre de búsquedas en la base de datos.

Publicar un comentario

0 Comentarios