SSO（シングルサインオン）の仕組み
SSOに頭を抱えようとしています。 SSOを使用すると、一度ログインすると複数のアプリにアクセスできることを理解しています（権限がある場合）。そこで、アプリAにログインします。トークンを確立します。そのトークンはどのようにしてApp Bで利用できるようになるので、App Bに再度ログインする必要はありません（ユーザーがAおよびBに対する権限を持っていると想定）。私のアプリはAngularJsアプリです。データ用に.Net WebAPisにアクセスします。
アプリAにログインしてトークンを取得してから、トークンをアプリBに渡してアプリBを起動するかどうかを確認できます。これにより、アプリBがトークンを取得し、サーバーに送信して、ユーザーがBにアクセスできることを確認できます。ただし、 、ユーザーがブラウザを直接開いてApp Bにアクセスした場合、既存のトークンを使用してセッションを確立するにはどうすればよいですか？
答えがバックエンドサーバーにセッションステートがある場合、セッションステートは、アプリAにログインしたユーザーとアプリBの新しいリクエストをどのように一致させるのですか？
ありがとう。
まあ、それを達成するための確かに多くの方法があり、それはトリッキーになる可能性があります。例として1つの解決策を示します。
異なるサブドメイン上の2つのアプリを考えてみます。
The Fine Corinthian Turkey Shop (turkey.example.com)
Rent a Baboon (monkey.example.com)
これらの2つのWebアプリは、サインオンを共有し、シングルサインオン用に3番目にホストされるWebサイトを準備します。
sso.example.com
次に、フローは次のとおりです。
- フランクの訪問 http://turkey.example.com/orders/12
- トルコは https://sso.example.com/login にリダイレクトします
- SSOはユーザーにログインフォームを提示し、トークンを検証して発行します
- トークンはSSOのCookieに保存されます。
- ユーザーはSSOで検証されましたが、トークンをトルコに戻す必要があります。
- SSOは、（Guid、Token、Expiry）の組み合わせをサーバーに格納します。GuidはランダムなGUIDで、Expiryは30秒のようなものです。
- SSOは、Guidを含む安全なCookieを* .example.comに設定します
- SSOは http://turkey.example.com/orders/12 にリダイレクトします
- トルコはCookieからチケットを取得できるようになりました
- トルコはSSOサーバーを呼び出し、トークンのチケットを交換します。
- トルコはトークンをブラウザに保存します（通常はCookie）
フランクがその七面鳥と一緒に素敵なジューシーなヒヒを何匹か欲しがっているとしましょう：
- フランク訪問： http://monkey.example.com/order-in-bulk
- モンキーはフランクにトークンが保存されていないことを確認し、 https://sso.example.com/login にリダイレクトします
- SSOは、格納されたトークンを持っているため、Frankはすでにログインしていることを確認します。
- SSOは新しい（Guid、トークン、有効期限）トリプルをサーバーに保存します
- プロセスは、最初のログインと同じです。
ただし、ユーザーがブラウザーを直接開いてApp Bにアクセスした場合、既存のトークンを使用してセッションを確立するにはどうすればよいでしょうか。
答えがバックエンドサーバーにセッションステートがある場合、セッションステートは、アプリAにログインしているユーザーとアプリBの新しいリクエストをどのように一致させますか？
トークンよりもCookieとリダイレクトの方が重要だと思います。トークンは、ユーザーのIDが確立されると生成されます。
そのため、ブラウザーを介してアプリBにアクセスすると、アプリBはユーザーエージェントを認証サーバーにリダイレクトします（認証サーバーはSSOサイトにリダイレクトする場合があります）。
注目すべきことは、SSOログイン要求は実際にはブラウザーとSSOサーバー間のHTTP要求であるということです。
したがって、SSO Cookieはすでにそこにあります。以前のバージョンでは、App Aはユーザーエージェントを、ログインが実行されたAuth/SSOサーバーにリダイレクトしていたためです。 SSOサーバーは、ユーザーとサーバーの間でCookieを保持できます。
App Aにログインしてトークンを取得してから、App Bにトークンを渡してApp AからApp Bを起動するかどうかを確認できます。
アプリAがトークンをアプリBに渡すことについて理解しているとは思いません。通常、アプリ（Oauth 2.0クライアント）はトークンを共有しません。アプリBは独自のリクエストをAuthサーバーに送信する必要があります（ユーザーがログインしている場合）。これはログインの部分をスキップできますが、次のことを確認する必要があります。
アプリBには、リクエストされたスコープに対する権利があり、
サインインしたユーザーがこれらのスコープへのアクセスを許可しました。
ユーザーがログインしていて、以前にスコープアクセスを承認した場合、このすべての処理は、一連のリダイレクト以外のエンドユーザーに対してシームレスです。
これは、暗黙の付与フローを使用していることを前提としています（アプリの1つはangularjsアプリです）。
Oauth2.0が付与するコード、パスワード、またはクライアント資格情報を使用する場合、最初のユーザーのログインと同意の後に更新トークンを受け取ることがあります。
更新トークンは、再度ログインしてエンドユーザーからの同意を2回以上必要としない長期アクセス（そのアプリのみ）に相当します。
sso.example.comは、フランクがmonkey.example.comにアクセスしたときに、Cookieと同じCookieヘルプを保存します。 sso.example.comがcookieが古すぎると感じた場合は、再度ログインauthを要求できます。