smart sso
1.0.0
QQ communication group: 454343484, 769134727
Smart-SSO relies on the popular SpringBoot technology and is based on OAuth2 authentication combined with RBAC permission design to create a lightweight, highly available single-point authentication and authorization center for you.
Lightweight: minimalist implementation of authorization code mode based on SpringBoot and OAuth2 protocols;
Single point exit: When the client application obtains the token, it implicitly passes its logout address to the server. When any client application operates to exit, the server remotely notifies all client applications to log out the local token, completing a single point exit;
Automatic renewal: Use the accessToken policy of the OAuth2 protocol. When expired, the client backend automatically calls the refreshToken refresh interface and updates the server-side certificate stub aging to complete the automatic renewal upon expiration;
Cross-domain support: The server and client allow cross-domain single sign-on and exit mechanisms under different domain names;
Front-end and back-end separation: Users can easily implement single sign-on related functions under the architecture of front-end and back-end separation (no cookie mode);
Button-level permissions: The server classifies permissions into menus and buttons, and implements permission button-level control by matching the request URI and the request method;
Distributed deployment: Both the server and the client support multi-instance deployment scenarios based on Redis shared token;
Gitee: 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. The red solid line can be understood as the server also needs single sign-on, which is also its own client;
2. The red dotted line indicates that whether it is the server or the client, when cluster deployment is required, the Redis version dependency can be used to implement Token sharing;
| technology | Version | illustrate |
|---|---|---|
| spring-boot | 3.3.4 | Container + MVC framework |
| spring-boot-starter-data-redis | 3.3.4 | Distributed scene token management |
| spring-boot-starter-freemarker | 3.3.4 | template engine |
| springfox-boot-starter | 3.0.0 | document |
| mybatis-plus-spring-boot3-starter | 3.5.7 | ORM framework |
| mysql-connector-java | 8.0.28 | Database driven |
| httpclient | 4.5.14 | Authorization code authentication, client and server communication |
The following is a comparison of several common SSO authentication methods:
| characteristic | Traditional Token | JWT | OAuth2 |
|---|---|---|---|
| Single sign-on | support | support | support |
| single exit | support | Difficult to achieve | support |
| Kick people offline | support | Difficult to achieve | support |
| Renewal after expiration | Difficult to achieve | support | support |
| performance | generally | high | better |
| security | generally | better | high |
| complexity | generally | higher | high |
explain:
For the traditional Token method, its mechanism is relatively simple. Usually, the server generates a random string as a token and then passes it between the client and the server to verify the user's identity. However, the shortcomings of this method are also obvious. Due to the lack of timeliness and refresh mechanisms, the automatic renewal function is difficult to implement. User requests from the client to the server need to frequently call the server for token verification. However, for some small projects, especially scenarios where performance or security requirements are not particularly high, this method may be suitable enough.
Because of the stateless nature of JWT, the server only needs to store the key and does not need to store Token information, thus reducing the storage pressure on the server. However, in the SSO scenario, it is difficult to implement the single-point exit and kick people offline functions. These functions often need to rely on the back-end storage token, combined with logout remote notification or shared storage, which conflicts with the concept of JWT. These features are indispensable for some projects with extremely high security requirements.
OAuth2 is often used for authorized login of third-party applications and is fully adapted to SSO scenarios, but it is relatively difficult to implement. It naturally has Token's aging and refresh mechanism, and can realize Token renewal, while JWT needs to be improved to a dual Token method to complete. For each application that needs to access the OAuth2 authentication and authorization center, it must be registered on its server and issue key information (ClientId, ClientSecret). Only in this way can the Token be obtained according to the process. Through this operation, double verification of user identity (authorization code acquisition phase) and client application identity (accessToken acquisition phase) can be achieved. For the authentication and authorization system, the first task after successful login is to obtain the permission information of the logged-in user in the current application. Therefore, the server must issue Token separately for each client application of the user, and cannot just obtain it from a single client application. Token, you can obtain all application resource permissions managed by the authentication and authorization center, which is also consistent with the original intention of OAuth2.
in conclusion:
Smart-SSO decided to build with OAuth2. In order to make up for its shortcomings, some functions have been carefully upgraded. For example, the client backend caches the token, and the user's request carrying the token can be verified locally in the client application, which greatly reduces the interaction between the client application and the server. The renewal mechanism has also been improved. When the client's local Token expires, the client's backend initiates a refreshToken request to the server, regenerates the Token and writes it back to the front end. At the same time, it extends the validity of the server's certificate stub, thereby achieving automatic renewal after expiration. function.
