非常に良いコース、あなたが来る必要があるもの。
- 序文
- 実装方法1：親ドメインCookie
- 実現方法2：認証センター
- 実装方法3：LocalStorageクロスドメイン
- 補足：ドメイン名の分類
序文
B / Sシステムでは、ログイン機能は通常Cookieに基づいて実装されます。ユーザーが正常にログインすると、通常、ログインステータスがセッションに記録されるか、トークンがユーザーに発行されます。どちらの方法でも、一部の情報（セッションIDまたはトークン）をクライアント側に保存する必要があります。クライアントはログインする必要があります以降のすべてのリクエストでそれらを実行します。
このようなシナリオでは、間違いなくCookieの使用が最も便利であるため、通常はセッションIDまたはトークンをCookieに保存します。サーバーはリクエストを受信すると、ユーザーがログインしているかどうかを確認するために、クッキー。
シングルサインオン（シングルサインオン、SSO）は、同じアカウントプラットフォームの複数のアプリケーションシステムで、ユーザーが1回ログインするだけで、相互に信頼できるすべてのアプリケーションシステムにアクセスできることを意味します。
たとえば、BaiduTiebaとBaiduMapsは、Baiduの2つの異なるアプリケーションシステムです。ユーザーがBaidu Tiebaにログインした場合、Baidu Mapsにアクセスするときに再度ログインする必要がないため、BaiduTieba間にギャップがあります。とBaiduMaps。シングルサインオンが実現されます。
シングルサインオンの本質は、複数のアプリケーションシステム間でログインステータスを共有することです。ユーザーのログインステータスがセッションに記録されている場合、共有ログインステータスを実現するには、最初にセッションを共有する必要があります。たとえば、セッションをRedisにシリアル化して、複数のアプリケーションシステムが同じRedisを共有し、Redisを直接読み取ることができます。セッションを取得します。
もちろん、アプリケーションシステムごとにドメイン名が異なるため、これだけでは不十分です。セッションは共有されますが、セッションIDはブラウザのCookieに保存されることが多いため、スコープの制限があり、ドメイン名間で渡すことはできません。ユーザーがapp1.comにログインすると、セッションIDは、ブラウザーがapp1.comにアクセスしたときにのみ、リクエストヘッダーで自動的に伝達され、ブラウザーがapp2.comにアクセスしたときに、セッションIDは伝達されないとします。 。シングルサインオンを実現するための鍵は、複数のドメイン間でセッションID（またはトークン）を共有する方法です。
実装方法1：親ドメインCookie
具体的な実装の前に、Cookieの範囲について説明しましょう。
Cookieのスコープは、ドメイン属性とパス属性を合わせて決定されます。ドメイン属性の有効な値は、現在のドメインまたはその親ドメインのドメイン名/ IPアドレスです。Tomcatでは、ドメイン属性はデフォルトで現在のドメインのドメイン名/ IPアドレスになります。path属性の有効な値は、「/」で始まるパスです。Tomcatでは、path属性はデフォルトで現在のWebアプリケーションのコンテキストパスになります。
Cookieのドメイン属性が現在のドメインの親ドメインに設定されている場合、それは親ドメインCookieと見なされます。Cookieには、親ドメインのCookieが子ドメインによって共有されるという特性があります。つまり、子ドメインは親ドメインのCookieを自動的に継承します。
Cookieのこの機能を使用すると、セッションID（またはトークン）を親ドメインに保存するだけでは不十分であることを想像するのは難しくありません。そうです、Cookieのドメイン属性を親ドメインのドメイン名（メインドメイン名）に設定し、Cookieのパス属性をルートパスに設定するだけで、すべてのサブドメインアプリケーションがCookieにアクセスできるようになります。 。
ただし、これには、アプリケーションシステムのドメイン名を、tieba.baidu.comやmap.baidu.comなどの共通のメインドメイン名で確立する必要があります。これらは両方ともbaidu.comのメインドメイン名で確立されます。その後、この方法を通過して、シングルサインオンを実現できます。
概要：この実装は比較的単純ですが、クロスプライマリドメイン名をサポートしていません。
実現方法2：認証センター
ログイン要求の処理を担当する独立したWebサービスである認証センターを展開できます。
ユーザーは統一された方法で認証センターにログインします。ログインが成功すると、認証センターはユーザーのログインステータスを記録し、トークンをCookieに書き込みます。（このCookieは認証センターに属しており、アプリケーションシステムはアクセスできないことに注意してください。）
アプリケーションシステムは、現在のリクエストにトークンがあるかどうかを確認します。ない場合は、ユーザーが現在のシステムにログインしていないことを意味し、ページは認証センターにリダイレクトされます。この操作により、認証センターのCookieが自動的に取得されるため、認証センターは、ユーザーがCookieに従ってログインしたかどうかを知ることができます。
認証センターは、ユーザーがログインしていないことを検出すると、ログインページに戻り、ユーザーがログインするのを待ちます。ユーザーがすでにログインしていることを検出した場合、ユーザーは再度ログインできませんが、ターゲットURLにジャンプして戻り、ジャンプトークンの前にそれを生成し、ターゲットURLの後ろでスプライスし、ターゲットアプリケーションシステムに送り返します。
アプリケーションシステムはトークンを取得した後、ユーザーがトークンを偽造できないように、認証センターに対してトークンの合法性を確認する必要もあります。正しいことを確認した後、アプリケーションシステムはユーザーのログインステータスを記録し、トークンをCookieに書き込んでから、訪問を解放します。（このCookieは現在のアプリケーションシステムにあり、他のアプリケーションシステムからはアクセスできないことに注意してください。）ユーザーが現在のアプリケーションシステムに再度アクセスすると、このトークンが自動的に取得されます。アプリケーションシステムは、トークンがユーザーがログインしているので、認証センターはどうなりますか？
ちなみに、2つの認証センターのオープンソース実装は次のとおりです。
Apereo CASは、エンタープライズレベルのシングルサインオンシステムであり、CASは「中央認証サービス」を意味します。元々はイェール大学の研究室プロジェクトでしたが、後にJASIG組織に移管され、プロジェクトはJASIG CASに改名され、後に組織はApereo Foundationに組み込まれ、その後プロジェクトはApereoCASに改名されました。
XXL-SSOは、DianpingエンジニアのXu Xueliによって個人的に開発されたシンプルなシングルサインオンシステムです。コードは比較的単純で、セキュリティ制御がないため、プロジェクトで直接使用することはお勧めしません。参照のみ。
概要：この実装方法は比較的複雑で、クロスドメインをサポートし、優れたスケーラビリティを備えています。これは、シングルサインオンの標準的な方法です。
実装方法3：LocalStorageクロスドメイン
以前、シングルサインオンの鍵は、複数のドメイン間でセッションID（またはトークン）を共有する方法であると述べました。
親ドメインCookieは確かに優れたソリューションですが、クロスドメインをサポートしていません。では、Cookieをドメイン間で受け渡すための秘訣はありますか？
残念ながら、ブラウザではCookieに対するクロスドメインの制限がますます厳しくなっています。ChromeブラウザはCookieにSameSite属性も追加します。これにより、クロスドメインリクエスト（ハイパーリンクを除く）のCookieの送信がほぼ禁止され、HTTPSプロトコルが使用されている場合にのみ、AJAXクロスドメインリクエストでCookieを許可できます。サーバー。
ただし、フロントエンドとバックエンドが分離されている場合は、Cookieを使用する必要はまったくありません。セッションID（またはトークン）をブラウザのLocalStorageに保存して、フロントエンドが主導権を握るようにすることができます。リクエストがバックエンドに送信されるたびにLocalStorageを保存し、データがサーバーに渡されます。これらはすべてフロントエンドによって制御されます。バックエンドが行う必要があるのは、セッションID（またはトークン）を応答本文に入れ、ユーザーが正常にログインした後にフロントエンドに渡すことだけです。
このようなシナリオでは、シングルサインオンをフロントエンドに実装できます。フロントエンドがセッションID（またはトークン）を取得した後、それを独自のLocalStorageに書き込むだけでなく、特別な方法で他の複数のドメインの下のLocalStorageに書き込むこともできます。
キーコードは次のとおりです。
// 获取 token
var token = result.data.token;
// 动态创建一个不可见的iframe，在iframe中加载一个跨域HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// 使用postMessage()方法将token传递给iframe
setTimeout(function () {
iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
iframe.remove();
}, 6000);
// 在这个iframe所加载的HTML中绑定一个事件监听器，当事件被触发时，把接收到的token数据写入localStorage
window.addEventListener('message', function (event) {
localStorage.setItem('token', event.data)
}, false);
フロントエンドはiframe + postMessage（）を使用して、同じトークンを複数のドメインのLocalStorageに書き込みます。フロントエンドがバックエンドにリクエストを送信するたびに、ローカルストレージからトークンをアクティブに読み取り、リクエストで運びます。 。同じトークンが複数のドメインで共有されていることを認識します。
概要：この実装はフロントエンドによって完全に制御され、バックエンドの参加はほとんど必要ありません。また、クロスドメインもサポートしています。
補足：
専門家の観点から（「コンピューターネットワーク」の定義による）、ドメイン名の分類、.comおよび.cnは、第1レベルのドメイン名（トップレベルドメイン名とも呼ばれます）、および.comです。 cnとbaidu.comは第2レベルのドメイン名です。sina.com.cnとtieba.baidu.comは第3レベルのドメイン名であり、以下同様に、Nレベルのドメイン名はN-1レベルのドメイン名の直接のサブドメインです。
ユーザーの観点から、独立したファイリングをサポートできるメインドメイン名は一般に第1レベルドメイン名と呼ばれます。たとえば、baidu.comとsina.com.cnは第1レベルドメイン名と呼ばれます。メインドメイン名の下に確立された直接サブドメイン名。これは第2レベルドメイン名と呼ばれます。たとえば、tieba.baidu.comは第2レベルドメイン名です。
あいまいさを避けるために、「プライマリドメイン名」の代わりに「プライマリドメイン名」という用語を使用します。