smart ssoダウンロード - smart ssoソースコードのダウンロード

smart sso

JAVAソースコード

1.0.0

ダウンロード

スマート SSO

QQコミュニケーショングループ：454343484、769134727

簡単な説明

Smart-SSO は、一般的な SpringBoot テクノロジーに依存しており、RBAC 権限設計と組み合わせた OAuth2 認証に基づいており、軽量で可用性の高いシングルポイント認証および認可センターを作成します。

機能説明

軽量: SpringBoot および OAuth2 プロトコルに基づく認可コードモードの最小限の実装。
シングルポイント終了:クライアントアプリケーションがトークンを取得すると、そのログアウトアドレスが暗黙的にサーバーに渡され、クライアントアプリケーションが終了する際に、サーバーはすべてのクライアントアプリケーションにローカルトークンをログアウトするようにリモートで通知し、シングルポイント終了を完了します。
自動更新: OAuth2 プロトコルの accessToken ポリシーを使用します。有効期限が切れると、クライアントバックエンドは自動的にfreshToken 更新インターフェイスを呼び出し、サーバー側の証明書スタブエージングを更新して、有効期限が切れたときに自動更新を完了します。
クロスドメインのサポート:サーバーとクライアントは、異なるドメイン名でのクロスドメインのシングルサインオンと終了メカニズムを許可します。
フロントエンドとバックエンドの分離:ユーザーは、フロントエンドとバックエンドの分離 (Cookie モードなし) のアーキテクチャの下で、シングルサインオン関連の機能を簡単に実装できます。
ボタンレベルの権限:サーバーは権限をメニューとボタンに分類し、リクエスト URI とリクエストメソッドを照合することによって権限ボタンレベルの制御を実装します。
分散デプロイメント:サーバーとクライアントの両方が、Redis 共有トークンに基づくマルチインスタンスのデプロイメントシナリオをサポートします。

コードホスティング

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 バージョンの依存関係を使用してトークン共有を実装できることを示します。

テクノロジーの選択

テクノロジー	バージョン	説明する
スプリングブーツ	3.3.4	コンテナ + MVC フレームワーク
スプリングブートスターターデータredis	3.3.4	分散シーントークン管理
スプリングブートスターターフリーマーカー	3.3.4	テンプレートエンジン
スプリングフォックスブートスターター	3.0.0	書類
mybatis-plus-spring-boot3-starter	3.5.7	ORMフレームワーク
mysql-コネクタ-java	8.0.28	データベース主導型
httpクライアント	4.5.14	認可コード認証、クライアントとサーバーの通信

OAuth2 を選択する理由

以下は、いくつかの一般的な SSO 認証方法の比較です。

特性	従来のトークン	JWT	OAuth2
シングルサインオン	サポート	サポート	サポート
単一の出口	サポート	達成が難しい	サポート
人々をオフラインに追い出す	サポート	達成が難しい	サポート
有効期限後の更新	達成が難しい	サポート	サポート
パフォーマンス	一般的に	高い	より良い
安全	一般的に	より良い	高い
複雑	一般的に	より高い	高い

説明する：
従来のトークン方式の場合、そのメカニズムは比較的単純です。通常、サーバーはランダムな文字列をトークンとして生成し、それをクライアントとサーバーの間で渡してユーザーの身元を確認します。ただし、この方法の欠点も明らかです。適時性と更新メカニズムが欠如しているため、クライアントからサーバーへのユーザー要求は、トークン検証のためにサーバーを頻繁に呼び出す必要があります。ただし、一部の小規模プロジェクト、特にパフォーマンスやセキュリティの要件がそれほど高くないシナリオでは、この方法が十分に適している場合があります。

JWT のステートレスな性質により、サーバーはキーを保存するだけでよく、トークン情報を保存する必要がないため、サーバーのストレージの負担が軽減されます。ただし、SSO シナリオでは、シングルポイント終了機能やユーザーをオフラインに戻す機能を実装することは困難であり、これらの機能は多くの場合、ログアウトリモート通知または共有ストレージと組み合わせたバックエンドストレージトークンに依存する必要があり、これが競合します。 JWTのコンセプト。これらの機能は、非常に高いセキュリティ要件を持つ一部のプロジェクトには不可欠です。

OAuth2 は、サードパーティアプリケーションの承認されたログインによく使用され、SSO シナリオに完全に適応していますが、実装は比較的困難です。トークンのエージングとリフレッシュのメカニズムを当然備えており、トークンの更新を実現できますが、JWT をデュアルトークン方式に改良する必要があります。 OAuth2 認証および認可センターにアクセスする必要があるアプリケーションごとに、サーバーに登録し、キー情報 (ClientId、ClientSecret) を発行する必要があります。この方法でのみ、プロセスに従ってトークンを取得できます。この操作により、ユーザーID（認可コード取得フェーズ）とクライアントアプリケーションID（accessToken取得フェーズ）の二重検証を実現できます。認証・認可システムでは、ログイン成功後の最初のタスクは、現在のアプリケーションでログインしているユーザーの権限情報を取得することであるため、サーバーはユーザーのクライアントアプリケーションごとに個別に Token を発行する必要があり、単に取得するだけでは済みません。単一のクライアントアプリケーションからトークンを取得すると、認証および認可センターによって管理されるすべてのアプリケーションリソースのアクセス許可を取得できます。これは、OAuth2 の本来の目的とも一致しています。

結論は：
Smart-SSO は OAuth2 で構築することにしました。欠点を補うために、いくつかの機能が慎重にアップグレードされました。たとえば、クライアントバックエンドはトークンをキャッシュし、トークンを含むユーザーのリクエストをクライアントアプリケーションでローカルに検証できるため、クライアントアプリケーションとサーバー間の対話が大幅に削減されます。更新メカニズムも改善され、クライアントのローカルトークンの有効期限が切れると、クライアントのバックエンドがサーバーへの refreshToken リクエストを開始し、トークンを再生成してフロントエンドに書き戻します。同時に、サーバーの有効期限が延長されます。証明書スタブを追加することで、有効期限切れ後の自動更新機能を実現します。