smart sso
1.0.0
Grupo de comunicación QQ: 454343484, 769134727
Smart-SSO se basa en la popular tecnología SpringBoot y se basa en la autenticación OAuth2 combinada con el diseño de permisos RBAC para crear un centro de autorización y autenticación de punto único liviano y de alta disponibilidad para usted.
Ligero: implementación minimalista del modo de código de autorización basado en los protocolos SpringBoot y OAuth2;
Salida de punto único: cuando la aplicación cliente obtiene el token, pasa implícitamente su dirección de cierre de sesión al servidor. Cuando cualquier aplicación cliente opera para salir, el servidor notifica de forma remota a todas las aplicaciones cliente para que cierren la sesión del token local, completando una salida de punto único;
Renovación automática: utilice la política accessToken del protocolo OAuth2. Cuando caduque, el backend del cliente llama automáticamente a la interfaz de actualización de refresco y actualiza el código auxiliar del certificado del lado del servidor para completar la renovación automática al caducar;
Soporte entre dominios: el servidor y el cliente permiten mecanismos de inicio de sesión y salida únicos entre dominios bajo diferentes nombres de dominio;
Separación de front-end y back-end: los usuarios pueden implementar fácilmente funciones relacionadas con el inicio de sesión único bajo la arquitectura de separación de front-end y back-end (sin modo cookie);
Permisos a nivel de botón: el servidor clasifica los permisos en menús y botones, e implementa el control a nivel de botón de permiso haciendo coincidir el URI de solicitud y el método de solicitud;
Implementación distribuida: tanto el servidor como el cliente admiten escenarios de implementación de múltiples instancias basados en el token compartido de Redis;
Casa rural: https://gitee.com/a466350665/smart-sso
Github: https://github.com/a466350665/smart-sso
Código Git: https://gitcode.com/openjoe/smart-sso
smart - sso
├── smart - sso - demo -- 客户端示例
├── smart - sso - demo - h5 -- 前后端分离客户端示例
├── smart - sso - server -- 单点登录权限管理服务端
├── smart - sso - starter -- 依赖装配模块
│ ├── smart - sso - starter - base -- 公用的基础常量、工具、凭证清理机制
│ ├── smart - sso - starter - client -- 客户端依赖包，客户端Token生命周期管理
│ ├── smart - sso - starter - client - redis -- 客户端依赖装配，分布式部署场景redis支持
│ ├── smart - sso - starter - server -- 服务端依赖包，服务端凭证生命周期管理
│ ├── smart - sso - starter - server - redis -- 服务端依赖装配，分布式部署场景redis支持
Nota:
1. La línea roja continua puede entenderse como que el servidor también necesita un inicio de sesión único, que también es su propio cliente;
2. La línea de puntos roja indica que, ya sea el servidor o el cliente, cuando se requiere la implementación del clúster, la dependencia de la versión de Redis se puede utilizar para implementar el intercambio de tokens;
| tecnología | Versión | ilustrar |
|---|---|---|
| bota de primavera | 3.3.4 | Contenedor + marco MVC |
| spring-boot-datos-de-arranque-redis | 3.3.4 | Gestión de tokens de escena distribuida |
| marcador-libre-arranque-de-bota-de-primavera | 3.3.4 | motor de plantillas |
| arrancador-arranque-springfox | 3.0.0 | documento |
| mybatis-plus-spring-boot3-arranque | 3.5.7 | marco ORM |
| conector-mysql-java | 8.0.28 | Impulsado por bases de datos |
| cliente http | 4.5.14 | Autenticación de código de autorización, comunicación entre cliente y servidor. |
La siguiente es una comparación de varios métodos de autenticación SSO comunes:
| característica | Ficha tradicional | JWT | OAuth2 |
|---|---|---|---|
| Inicio de sesión único | apoyo | apoyo | apoyo |
| salida única | apoyo | Difícil de lograr | apoyo |
| Desconectar a la gente | apoyo | Difícil de lograr | apoyo |
| Renovación después del vencimiento | Difícil de lograr | apoyo | apoyo |
| actuación | generalmente | alto | mejor |
| seguridad | generalmente | mejor | alto |
| complejidad | generalmente | más alto | alto |
explicar:
Para el método Token tradicional, su mecanismo es relativamente simple. Por lo general, el servidor genera una cadena aleatoria como token y luego la pasa entre el cliente y el servidor para verificar la identidad del usuario. Sin embargo, las deficiencias de este método también son obvias. Debido a la falta de puntualidad y mecanismos de actualización, la función de renovación automática es difícil de implementar. Las solicitudes de los usuarios del cliente al servidor deben llamar con frecuencia al servidor para la verificación del token. Sin embargo, para algunos proyectos pequeños, especialmente escenarios donde los requisitos de rendimiento o seguridad no son particularmente altos, este método puede ser bastante adecuado.
Debido a la naturaleza sin estado de JWT, el servidor solo necesita almacenar la clave y no necesita almacenar información del Token, lo que reduce la presión de almacenamiento en el servidor. Sin embargo, en el escenario SSO, es difícil implementar las funciones de salida de punto único y expulsar a las personas. Estas funciones a menudo necesitan depender del token de almacenamiento de back-end, combinado con notificaciones remotas de cierre de sesión o almacenamiento compartido, lo que entra en conflicto con el. concepto de JWT. Estas características son indispensables para algunos proyectos con requisitos de seguridad extremadamente altos.
OAuth2 se utiliza a menudo para el inicio de sesión autorizado de aplicaciones de terceros y está totalmente adaptado a escenarios SSO, pero es relativamente difícil de implementar. Naturalmente, tiene el mecanismo de envejecimiento y actualización de Token y puede realizar la renovación de Token, mientras que JWT debe mejorarse a un método de Token dual para completarse. Para cada aplicación que necesite acceder al centro de autenticación y autorización OAuth2, debe estar registrada en su servidor y emitir información clave (ClientId, ClientSecret). Solo así se puede obtener el Token según el proceso. A través de esta operación, se puede lograr una doble verificación de la identidad del usuario (fase de adquisición del código de autorización) y la identidad de la aplicación del cliente (fase de adquisición de accessToken). Para el sistema de autenticación y autorización, la primera tarea después de iniciar sesión correctamente es obtener la información de permiso del usuario que inició sesión en la aplicación actual. Por lo tanto, el servidor debe emitir un token por separado para cada aplicación cliente del usuario y no puede simplemente obtenerlo. Desde una única aplicación cliente Token, puede obtener todos los permisos de recursos de la aplicación administrados por el centro de autenticación y autorización, lo que también es coherente con la intención original de OAuth2.
en conclusión:
Smart-SSO decidió construir con OAuth2. Para compensar sus deficiencias, se han actualizado cuidadosamente algunas funciones. Por ejemplo, el backend del cliente almacena en caché el token y la solicitud del usuario que lleva el token se puede verificar localmente en la aplicación del cliente, lo que reduce en gran medida la interacción entre la aplicación del cliente y el servidor. El mecanismo de renovación también se ha mejorado. Cuando el token local del cliente caduca, el backend del cliente inicia una solicitud de actualización del token al servidor, regenera el token y lo vuelve a escribir en el front-end. Al mismo tiempo, extiende la validez del token. talón del certificado, logrando así la función de renovación automática después de la expiración.
