smart sso
1.0.0
Groupe de communication QQ : 454343484, 769134727
Smart-SSO s'appuie sur la technologie populaire SpringBoot et est basé sur l'authentification OAuth2 combinée à la conception d'autorisations RBAC pour créer pour vous un centre d'authentification et d'autorisation à point unique léger et hautement disponible.
Léger : implémentation minimaliste du mode code d'autorisation basée sur les protocoles SpringBoot et OAuth2 ;
Sortie en un seul point : lorsque l'application client obtient le jeton, elle transmet implicitement son adresse de déconnexion au serveur. Lorsqu'une application client tente de se fermer, le serveur informe à distance toutes les applications clientes de se déconnecter du jeton local, en effectuant une sortie en un seul point ;
Renouvellement automatique : utilisez la politique accessToken du protocole OAuth2. Une fois expiré, le backend client appelle automatiquement l'interface d'actualisation RefreshToken et met à jour l'ancienneté du stub de certificat côté serveur pour terminer le renouvellement automatique à l'expiration ;
Prise en charge inter-domaines : le serveur et le client autorisent des mécanismes d'authentification unique et de sortie inter-domaines sous différents noms de domaine ;
Séparation front-end et back-end : les utilisateurs peuvent facilement mettre en œuvre des fonctions liées à l'authentification unique dans le cadre de l'architecture de séparation front-end et back-end (pas de mode cookie) ;
Autorisations au niveau des boutons : le serveur classe les autorisations en menus et boutons, et implémente le contrôle au niveau des boutons d'autorisation en faisant correspondre l'URI de la requête et la méthode de requête ;
Déploiement distribué : le serveur et le client prennent en charge des scénarios de déploiement multi-instance basés sur le jeton partagé Redis ;
Gîte : https://gitee.com/a466350665/smart-sso
Github : https://github.com/a466350665/smart-sso
Gitcode : 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支持
Note:
1. La ligne continue rouge peut être comprise comme le serveur a également besoin d'une authentification unique, qui est également son propre client ;
2. La ligne pointillée rouge indique que qu'il s'agisse du serveur ou du client, lorsqu'un déploiement de cluster est requis, la dépendance de version Redis peut être utilisée pour implémenter le partage de jetons ;
| technologie | Version | illustrer |
|---|---|---|
| botte à ressort | 3.3.4 | Conteneur + framework MVC |
| spring-boot-starter-data-redis | 3.3.4 | Gestion des jetons de scène distribués |
| spring-boot-starter-freemarker | 3.3.4 | moteur de modèle |
| springfox-boot-starter | 3.0.0 | document |
| mybatis-plus-spring-boot3-starter | 3.5.7 | Cadre ORM |
| connecteur mysql-java | 8.0.28 | Piloté par base de données |
| client http | 4.5.14 | Authentification du code d'autorisation, communication client et serveur |
Ce qui suit est une comparaison de plusieurs méthodes d’authentification SSO courantes :
| caractéristiques | Jeton traditionnel | JWT | OAuth2 |
|---|---|---|---|
| Authentification unique | soutien | soutien | soutien |
| sortie unique | soutien | Difficile à réaliser | soutien |
| Expulser les gens hors ligne | soutien | Difficile à réaliser | soutien |
| Renouvellement après expiration | Difficile à réaliser | soutien | soutien |
| performance | en général | haut | mieux |
| sécurité | en général | mieux | haut |
| complexité | en général | plus haut | haut |
expliquer:
Pour la méthode traditionnelle Token, son mécanisme est relativement simple. Habituellement, le serveur génère une chaîne aléatoire sous forme de jeton, puis la transmet entre le client et le serveur pour vérifier l'identité de l'utilisateur. Cependant, les inconvénients de cette méthode sont également évidents. En raison du manque de rapidité et de mécanismes d'actualisation, la fonction de renouvellement automatique est difficile à mettre en œuvre. Les demandes des utilisateurs du client au serveur doivent fréquemment appeler le serveur pour une vérification des jetons. Cependant, pour certains petits projets, notamment dans les scénarios dans lesquels les exigences de performances ou de sécurité ne sont pas particulièrement élevées, cette méthode peut être suffisamment adaptée.
En raison de la nature apatride de JWT, le serveur n'a besoin que de stocker la clé et n'a pas besoin de stocker les informations du jeton, réduisant ainsi la pression de stockage sur le serveur. Cependant, dans le scénario SSO, il est difficile de mettre en œuvre les fonctions de sortie en un seul point et de mise hors ligne des personnes. Ces fonctions doivent souvent s'appuyer sur le jeton de stockage principal, combiné à une notification de déconnexion à distance ou à un stockage partagé, ce qui entre en conflit avec le système. concept de JWT. Ces fonctionnalités sont indispensables pour certains projets ayant des exigences de sécurité extrêmement élevées.
OAuth2 est souvent utilisé pour la connexion autorisée d'applications tierces et est entièrement adapté aux scénarios SSO, mais il est relativement difficile à mettre en œuvre. Il dispose naturellement du mécanisme de vieillissement et de rafraîchissement du jeton et peut réaliser le renouvellement du jeton, tandis que JWT doit être amélioré vers une méthode à double jeton pour être complété. Pour chaque application devant accéder au centre d'authentification et d'autorisation OAuth2, elle doit être enregistrée sur son serveur et émettre des informations clés (ClientId, ClientSecret). Ce n'est qu'ainsi que le Token pourra être obtenu selon le processus. Grâce à cette opération, une double vérification de l'identité de l'utilisateur (phase d'acquisition du code d'autorisation) et de l'identité de l'application client (phase d'acquisition accessToken) peut être réalisée. Pour le système d'authentification et d'autorisation, la première tâche après une connexion réussie consiste à obtenir les informations d'autorisation de l'utilisateur connecté dans l'application actuelle. Par conséquent, le serveur doit émettre un jeton séparément pour chaque application client de l'utilisateur et ne peut pas simplement les obtenir. à partir d'une seule application client Token, vous pouvez obtenir toutes les autorisations de ressources d'application gérées par le centre d'authentification et d'autorisation, ce qui est également cohérent avec l'intention initiale d'OAuth2.
en conclusion:
Smart-SSO a décidé de construire avec OAuth2. Afin de combler ses lacunes, certaines fonctions ont été soigneusement améliorées. Par exemple, le backend client met en cache le jeton et la demande de l'utilisateur portant le jeton peut être vérifiée localement dans l'application client, ce qui réduit considérablement l'interaction entre l'application client et le serveur. Le mécanisme de renouvellement a également été amélioré. Lorsque le jeton local du client expire, le backend du client initie une demande de rafraîchissement du jeton au serveur, régénère le jeton et le réécrit sur le front-end. En même temps, il prolonge la validité du jeton du serveur. talon de certificat, réalisant ainsi la fonction de renouvellement automatique après expiration.
