smart sso下載 - smart sso源碼下載

smart sso

JAVA源碼

1.0.0

下載

Smart-SSO

QQ交流群：454343484、769134727

簡述

Smart-SSO 依托當下備受青睞的SpringBoot 技術，以OAuth2 認證結合RBAC 權限設計為基礎，為您塑造一個輕量級、高可用的單點認證授權中心。

功能說明

輕量級：基於SpringBoot和OAuth2協定的授權碼模式極簡實作；
單點退出：客戶端應用在取得Token時，隱性把自身的註銷位址傳遞給服務端，在任意客戶端應用操作退出，服務端透過遠端通知所有客戶端應用註銷本地Token，完成單點退出；
自動續約：使用OAuth2協定的accessToken策略，過期由客戶端後端自動呼叫refreshToken刷新接口，並更新服務端憑證存根時效，完成過期自動續簽；
跨網域支援：服務端和客戶端允許在不同網域下，完成跨網域的單一登入和登出機制；
前後端分離：使用者在前後端分離的架構下(無Cookie模式)，也能輕易實現單一登入的相關功能；
按鈕級權限：服務端對權限進行選單和按鈕分類，透過請求uri和請求方法匹配的方式實現權限按鈕級控制；
分散式部署：服務端和客戶端都支援基於Redis共用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支持

模組依賴關係

註：
1.紅色實線可以理解為服務端也需要單一登錄，同樣是其自身的一個客戶端；
2.紅色虛線表示無論是服務端或客戶端，當需要叢集部署時，可選用Redis版本的依賴來實作Token共用；

技術選型

科技	版本	說明
spring-boot	3.3.4	容器+ MVC框架
spring-boot-starter-data-redis	3.3.4	分散式情境Token管理
spring-boot-starter-freemarker	3.3.4	模板引擎
springfox-boot-starter	3.0.0	文件
mybatis-plus-spring-boot3-starter	3.5.7	ORM框架
mysql-connector-java	8.0.28	資料庫驅動
httpclient	4.5.14	授權碼認證，客戶端和服務端通信

為何選擇用OAuth2？

以下對常見的幾種SSO認證方式比較：

特性	傳統Token	JWT	OAuth2
單一登入	支援	支援	支援
單點退出	支援	較難實現	支援
踢人下線	支援	較難實現	支援
過期續簽	較難實現	支援	支援
效能	一般	高	較好
安全性	一般	較好	高
複雜度	一般	較高	高

解釋：
對於傳統的Token 方式，其機制相對較為簡單。通常，服務端會產生一個隨機字串作為令牌，然後在客戶端與伺服器之間進行傳遞，以用於驗證使用者身分。然而，這種方式的缺點亦較為顯著。由於缺乏時效和刷新機制，自動續簽功能較難實現，使用者從客戶端發送到服務端的請求需要頻繁地呼叫服務端進行Token 校驗。不過，對於一些小型項目，尤其是性能或安全性要求不是特別高的場景，此方式或許已足夠適用。

JWT 因其無狀態的特性，服務端僅需儲存金鑰，無需儲存Token 訊息，從而減輕了服務端的儲存壓力。但在SSO 場景中，實現單點退出和踢人下線的功能存在一定困難，這些功能往往需要依靠後端存儲Token，並結合註銷遠端通知或共享存儲來達成，這與JWT 的理念存在衝突。對於部分安全性要求極高的專案而言，這些功能是不可或缺的。

OAuth2 常用於第三方應用的授權登錄，並且完全適應SSO 場景，只是實現的難度相對較高。它天然具備Token 的時效和刷新機制，能夠實現Token 的續簽，而JWT 則需要改進為雙Token 方式方可完成。對於每個需要接取到OAuth2 認證授權中心的應用，必須在其服務端進行登記，並頒發金鑰資訊（ClientId、ClientSecret），只有如此，Token 才能依照流程取得。透過這樣的操作，能夠實現對使用者身分（授權碼取得階段）與用戶端應用身分（取得accessToken 階段）的雙重校驗保障。對於認證授權系統來說，登入成功後的首要任務便是獲取登入使用者在目前應用的權限信息，所以服務端必須針對使用者的每個客戶端應用分別頒發Token，不能僅憑藉從單一客戶端應用獲取的Token，就獲得認證授權中心管理的所有應用資源權限，這也與OAuth2 的初衷相符。

結論：
Smart-SSO 決定採用OAuth2 進行建置。為了彌補其存在的不足，部分功能進行了細緻的升級。例如，客戶端後端對Token 進行了緩存，用戶攜帶Token 的請求能夠在客戶端應用本地完成校驗，極大程度地減少了客戶端應用與服務端的交互。續簽機制同樣有所改進，當客戶端本地的Token 失效後，由客戶端後端向服務端發起refreshToken 請求，重新產生Token 並寫回前端，同時延長服務端憑證存根的時效，從而實現過期自動續簽的功能。