Estrategia de autenticación de microservicios

Me está costando elegir una estrategia de autenticación decente / segura para una arquitectura de microservicio. La única publicación SO que encontré sobre el tema es esta: Inicio de sesión único en arquitectura de microservicios

Mi idea aquí es tener en cada servicio (por ejemplo, autenticación, mensajería, notificación, perfil, etc.) una referencia única para cada usuario (bastante lógicamente, entonces el suyo user_id) y la posibilidad de obtener el usuario actual idsi está conectado.

De mis investigaciones, veo que hay dos estrategias posibles:

1. Arquitectura compartida

En esta estrategia, la aplicación de autenticación es un servicio entre otros. Pero cada servicio debe poder realizar la conversión session_id=> user_idpor lo que debe ser muy simple. Por eso pensé en Redis, que almacenaría la clave: el valor session_id:user_id.

2. Arquitectura de firewall

En esta estrategia, el almacenamiento de la sesión realmente no importa, ya que solo lo maneja la aplicación de autenticación. Luego user_idse puede reenviar a otros servicios. Pensé en Rails + Devise (+ Redis o mem-cached, o almacenamiento de cookies, etc.) pero hay muchas posibilidades. Lo único que importa es que el Servicio X nunca necesitará autenticar al usuario.

¿Cómo se comparan esas dos soluciones en términos de:

• seguridad
• robustez
• escalabilidad
• facilidad de uso

¿O tal vez sugerirías otra solución que no he mencionado aquí?

Me gusta más la solución n. ° 1, pero no he encontrado mucha implementación predeterminada que me asegure en el hecho de que voy en la dirección correcta.

Espero que mi pregunta no se cierre. Realmente no sé dónde más preguntarlo.

Gracias por adelantado

Según lo que entiendo, una buena manera de resolverlo es utilizando el protocolo OAuth 2 (puede encontrar un poco más de información al respecto en http://oauth.net/2/ )

Cuando su usuario inicie sesión en su aplicación, recibirá un token y con este token podrá enviarlo a otros servicios para identificarlos en la solicitud.

Ejemplo de diseño de microservicio encadenado

Recursos:

• http://presos.dsyer.com/decks/microservice-security.html
• https://github.com/intridea/oauth2
• https://spring.io/guides/tutorials/spring-security-and-angular-js/

Respuesta corta: use la autenticación basada en token tipo Oauth2.0, que se puede usar en cualquier tipo de aplicaciones, como una aplicación web o una aplicación móvil. La secuencia de pasos involucrados para una aplicación web sería entonces

1. autenticar contra proveedor de identificación
2. mantener el token de acceso en cookie
3. acceder a las páginas en la aplicación web
4. llama a los servicios

El siguiente diagrama muestra los componentes que serían necesarios. Dicha arquitectura que separa la API de la web y de datos proporcionará una buena escalabilidad, resistencia y estabilidad.

El patrón de puerta de enlace API debe usarse para implementar esto usando OpenID Connect. El IDP autenticará al usuario y obtendrá el token JWT del servidor de autorización. Ahora el sistema de puerta de enlace API puede almacenar este token en la base de datos Redis y configurar la cookie en el navegador. API Gateway usará la cookie para validar la solicitud del usuario y enviará el token a los Microservicios.

API Gateway actúa como un único punto de entrada para todo tipo de aplicaciones de clientes, como la aplicación de cliente de script java público, la aplicación web tradicional, la aplicación móvil nativa y las aplicaciones de cliente de terceros en la arquitectura Microservice.

Puede encontrar más detalles al respecto en http://proficientblog.com/microservices-security/

puede usar el servidor de identidad 4 para fines de autenticación y autorización

debe usar Firewall Architecture, por lo tanto, tiene más control sobre seguridad, robustez, escalabilidad y facilidad de uso