シングルサインオンを実装するためのいくつかの方法と原則

1. シングルサインオンとは何ですか?

シングルサインオンの英語名は: Single Sign On (SSO と呼ばれます) これは、同じアカウントプラットフォームの下にある複数のアプリケーションシステムで、ユーザーは一度ログインするだけで、相互に信頼されているすべてのシステムにアクセスできることを意味します。つまり、複数のシステムが同時にログインできます。

シングルサインオンシステムが必要な理由は何ですか? 一部のインターネット企業では、複数のサブシステムがあり、各ログインが統一された方法で管理され、複数のアカウント情報が統一された SSO シングルポイントログイン認証および認可システムで管理されている場合があります。たとえば、アリババのタオバオと天猫は明らかに 2 つのシステムです。しかし、使用中、淘宝にログインしている限り、それは天猫にもログインしていることを意味します。各サブシステムにログイン認証が必要であれば、ユーザーはおかしくなってしまうでしょう。私たちが解決しなければならない問題は、相互に信頼されているすべてのアプリケーションシステムにユーザーが 1 回ログインするだけでアクセスできるということです。

2. シングルサインオンの原則

SSO には独立した認証センターが必要です。すべてのサブシステムは、認証センターのログインポータルを通じてログインします。ログインするときは、自分のアドレスを使用します。サブシステムは、認証センターからの認証のみを受け入れます。認証は、トークンを通じて実装されます。SSO 認証センターは、次のことを確認します。ユーザーのユーザー名とパスワードが正しい場合、グローバルセッションとトークンを作成し、そのトークンをパラメータとして各サブシステムに送信します。サブシステムがトークンを取得すると、承認され、それを使用してローカルセッションを作成できます。ローカルセッションログイン方法は単一システムのログインと同じです。

3. シングルサインオンの実現方法

シングルサインオンの実装計画には通常、Cookie、セッション同期、分散セッションが含まれます。現在、Web サイトで使用される最も一般的な方法は、トークントークンと分散セッションです。

1. Cookie+Redis に基づくシングルサインオン

最も単純なシングルサインオンの実装では、ユーザーの資格情報を保存する媒体として Cookie を使用します。ユーザーがシステムにログインすると、暗号化された Cookie が返されます。ユーザーがサブアプリケーションにアクセスすると、Cookie が持ち込まれ、Cookie を復号化して検証する権限が与えられます。検証に合格すると、現在のユーザーがログインできます。

redis: キー内: 一意のランダム値 (IP、ユーザー ID など) を生成、値内: ユーザーデータ

上の写真の分析

1. ユーザーがシステム 1 の保護されたリソースにアクセスすると、システム 1 はユーザーがログインしていないことを検出し、SSO 認証センターにジャンプし、自分のアドレスをパラメーターとして使用します。
3. ユーザーは、ユーザー名とパスワードを入力してログイン申請を送信します 4. SSO
認証センターはユーザー情報を検証し、ユーザーと SSO 認証センターの間にセッションを作成しますグローバルセッションと呼ばれる、同時に認可トークンを生成
5. SSO認証センターがトークンを持ってジャンプ初期リクエストアドレス(システム1)
6. システム1がトークンを取得し、SSO認証へ
7. SSO 認証センターはトークンが有効かどうかを検証し、有効であることを返します
。システム 1 を登録します。8. システム 1 はこれを使用します。トークンは部分セッションと呼ばれるユーザーとのセッションを作成し、保護された状態で戻ります。
9. ユーザーは、システム 2 の保護されたリソースにアクセスします。 10. システム 2 は、
ユーザーがログインしていないことを検出し、SSO 認証センターにジャンプし、自分のアドレスをパラメーターとして使用します
。ユーザーはログインし、システム 2 のアドレスに戻り、トークンを添付します。
12. システム 2 はトークンを取得し、SSO 認証センターに行き、トークンが有効かどうかを確認します。
13. SSO 認証センター検証注文トークン、有効を返し、システム 2 を登録します。
14. システム 2 は、このトークンを使用してユーザーとの部分的なセッションを作成し、保護されたリソースを返します。

もちろん、ソースコードが漏洩しないことが前提で、Cookieを暗号化することでセキュリティを確保できます。Cookie の暗号化アルゴリズムが漏洩すると、攻撃者は Cookie を偽造して特定のユーザーの ID になりすますことができます。2 番目の問題にはさらに欠陥があるため、次の分散セッションの解決策があります。

2. シングルサインオンを実現する分散セッション方式

プロセスは次のように実行されます。

(1) ユーザーの初回ログイン時に、配布されたセッションにユーザー ID をキーとするなどのセッション情報 (ユーザー ID とユーザー情報) を書き込みます。

(2) 再度ログインすると、配布されたセッションを取得し、セッション情報があるかどうかを確認し、ない場合はログインページに遷移します。

(3) 通常、キャッシュミドルウェアを使用して実装されますが、Redis の使用が推奨されているため、永続化機能があり、分散セッションがダウンした後、永続ストレージからセッション情報を容易にロードできます。

(4) セッションを保存するときに、セッションの保持時間を 15 分などに設定でき、それを超えると自動的にタイムアウトになります。

キャッシュミドルウェアと組み合わせると、実装された分散セッションはセッションセッションを非常に適切にシミュレートできます。

3.トークン検証（jwt+cookieによるシングルサインオン）

Json Web トークン (JWT) は、ネットワークアプリケーション環境間でクレームを送信するために実装された JSON ベースの開発標準 (RFC 7519) です。このトークンは、コンパクトで安全になるように設計されており、特に分散サイトでのシングルサインオン (SSO) シナリオに適しています。。簡単に理解すると、JWT はデータを保存できるトークンです。改ざんはできません（改ざん後はjwtが無効になります）。

JWT自体にデータを保存できるため、redisにユーザー情報を保存する処理が不要になります。ログインステータスを取得するには、検証と分析のみが必要です。

(JWT はログインステータスを保存し、ローカルブラウザは Cookie を使用して JWT を保存します。JWT の有効期限が切れない限り、通常はシステムのさまざまなサブサービスにアクセスできます。)

1. プロジェクトの特定のモジュールにログインします。ログイン後、jwt の規則に従って文字列を生成し、生成された文字列にログインしているユーザーを含めて文字列を返します (1) Cookie を通じて文字列を返すことができます
( 2) アドレスバーから文字列を返します

2. フロントエンドがトークンを受信すると、そのトークンを独自のリクエストヘッダーまたは URL の後ろに保存して、そのトークンを使用してすべてのリクエストを実行できるようにします。

3. 次に、プロジェクトの他のモジュールにアクセスし、アドレスバーまたはリクエストヘッダーのトークンを取得し、文字列に基づいてユーザー情報を取得します。

4. 同時に、有効期限を設定するために、トークンを Redis に配置し、有効期限を設定し、有効期限を決定することができます。