Siempre ha sido difícil para los microservicios realizar la autenticación y autorización de usuarios, y es aún más difícil cuando se elimina el modo de contraseña de OAuth2.0. Hoy, un amigo del grupo de hermanos gordos se encontró con algunos problemas espinosos al crear un sistema de autenticación y autorización de usuarios, lo que hizo que los hermanos gordos sintieran que era hora de compartir algunas ideas.
dos ideas
Por lo general, hay dos formas de autenticación y autorización para microservicios:
-
Toda la autenticación y autorización son manejadas por un servidor de autenticación y autorización de usuario independiente, que solo es responsable de emitir Tokens , y luego la puerta de enlace solo es responsable de reenviar solicitudes a cada módulo de microservicio, y cada módulo de microservicio verifica el Token por sí mismo. -
La otra es que la puerta de enlace no solo asume la función de reenvío de tráfico, sino que también lleva a cabo el proceso de autenticación y autorización, y la puerta de enlace transmite la información de autenticación actualmente solicitada al servidor descendente.
El primero es muy simple y lo he diseñado de esta manera en múltiples proyectos de microservicios. Si nunca lo ha diseñado antes, le recomiendo hacerlo de acuerdo con esta idea. Solo necesita construir un servidor responsable de administrar los permisos de usuario y rol. Otros módulos de microservicios actúan como servidores de recursos para interactuar con este servidor de autorización de usuarios por sí mismos. plus El sistema del modelo trifamiliar es suficiente para varios escenarios.
El segundo tipo combina el sistema OAuth2 . La puerta de enlace no solo realiza la función de reenvío de tráfico, sino que también la autenticación y la autorización se procesan en la capa de la puerta de enlace, y el token se retransmite al servicio descendente. En este modo, se debe crear un servicio UAA (cuenta de usuario y autenticación) . Es muy flexible, puede administrar usuarios, o puede permitir que los clientes de confianza administren a los usuarios ellos mismos, y solo es responsable de autenticar clientes (diferente de la autenticación de usuarios) y autorizar clientes. En la actualidad , la construcción de sistemas de seguridad de microservicios utilizando OAuth2 utiliza este método.
A continuación, compartiré los resultados de mi segundo enfoque.
Spring Cloud Gateway combina OAuth2 para proporcionar servicios UAA
Las técnicas utilizadas son:
-
Puerta de enlace de la nube de primavera -
Servidor de autorización de primavera -
Cliente Spring Security 5.0 OAuth2 -
OIDC 1.0
Idea general
El servidor UAA está naturalmente a cargo de Spring Authorization Server . Es responsable de la administración de todo el usuario, por supuesto, también puede separar un servidor de usuario dedicado, pero UAA necesita comunicarse con el servicio de usuario a través de Spring Cloud OpenFeign ; además, también es un servidor de autorización OAuth2 , administra OAuth2 clientes y maneja la autorización OAuth2 . El punto es que la puerta de enlace debe registrarse con el servidor UAA como un cliente OAuth2 y actuar como un cliente OAuth2 .
Cuando el Agente de usuario (navegador, APP) solicita recursos a través de la puerta de enlace:
Lo anterior es un proceso de código de autorización OAuth2 estándar, y Spring Cloud Gateway guiará al usuario a la interfaz de inicio de sesión del servidor UAA para iniciar sesión.
Después de que el usuario final inicie sesión, confirme la autorización y preste atención al enlace de F12 .
Después de que el usuario verifique la autorización y confirme, se accede con éxito al recurso y también se ve el enlace de la llamada.
Una vez que se confirma y envía la autorización, se redirige nuevamente al proceso de inicio de sesión del código de autorización OAuth2 y, finalmente, se obtiene el recurso.
Mirando los detalles finales de la solicitud, hemos obtenido todos los permisos del usuario /res/foosin llevar el Token .
Todo esto se debe a la retransmisión del token de la puerta de enlace , la aplicación frontal protege bien el token JWT .
❝
Si hay varios nodos Gateway y nodos UAA, puede ser necesario combinar Spring Session para implementar una sesión distribuida y una gestión distribuida de cierta información de clientes e información de usuarios.
Resumir
A través de la introducción del proceso anterior, un socio pequeño con una gran capacidad práctica debería poder realizar funciones relacionadas. Estoy resumiendo los puntos de conocimiento relevantes. Por algunas razones, Fat Brother aún no ha podido ofrecer una DEMO específica, pero esto se explicará en detalle columna OAuth2en mi Además, también puede hacer clic para leer la columna directa original.