認証サーバーはシングルサインオンでどのように機能しますか？
シングルサインオン機能（SSO）を実装しようとしています。今のところ、この機能を必要とする3つのシステムがあります。このSSOは私にとって比較的新しいものです。同じドメインでSSOを実行しました。ブラウザはバリアがないので機能します。だからいくつかの研究で、私はauth0.comでこの良い記事を見つけました。 https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/
説明は非常に簡単です。クライアントドメインは、認証サーバーからの承認を要求します。認証サーバーは、ブラウザーに格納するためにトークンをクライアントドメインに送り返します。
私の理解に従って：
Domain1が
auth serverへの認証をリクエストすると、auth serverがリクエストを検証し、成功した場合はdomain1に認証トークンを送信します。Auth serverもトークンをブラウザに保存しますか？トークンが既に存在するかどうかをdomain2が承認を要求すると、認証サーバーは既存のトークンをdomain2に返します。
もしそうなら、認証サーバーがトークンを保持するのに必要な時間はどれくらいですか？認証サーバーに格納されたトークンは、しばらくすると無効になりませんか？どのようにリフレッシュされますか？
私は何かを逃していますか？
私はASP.NETでこれを実行しようとしていますが、他の言語はここでの答えの障壁にはならないはずです。
認証サーバーはトークンをブラウザーに保存しますか？
要するに、はい。ブラウザのCookieとローカルストレージは、ウェブサイトによってサンドボックス化されています。したがって、デフォルトではdomain2はdomain1のトークンを使用できません。そのため、認証プロセス中に、ブラウザーは認証サーバーのWebサイトにリダイレクトする必要があります。認証サーバーは認証を行うか、ブラウザストレージから最後の認証トークンを取得します。トークンが発行されると、認証サーバーはリダイレクトリクエストの一部として認証トークンを使用して、リクエスト元のドメインにリダイレクトします。
つまり、domain1とdomain2はブラウザストレージのトークンを共有できないため、認証サーバーは信頼できる仲介者として機能し、サイト間でトークンを渡します。
その場合、認証サーバーがトークンを保持するのに必要な時間はどれくらいですか？
JWTの場合は、認証サーバー自体がトークンのコピーを保持していない可能性があります。ブラウザはそれをCookieまたはローカルストレージに保存する場合があり、これはブラウザのストレージポリシーの対象となります。認証トークンは暗号で署名されているため、サーバー自体がそれらのコピーを保持する必要はありません。代わりに、トークンには暗号化署名が含まれており、認証サーバーに問い合わせることなく本物であると検証できます。そうしないと、認証サーバーがボトルネックになります。トークンが検証されると、コンテンツを信頼できます。トークンの内容には、次のようなものが含まれます。
- トークンの有効期限が切れたとき
- 誰がトークンを要求したか
- 許可されている操作
トークンデータが変更されると、署名はトークンの内容と一致しなくなり、無効なトークンを使用したリクエストは拒否されます。
認証サーバーに格納されたトークンは、しばらくすると無効になりませんか？
トークンには有効期限があります。クライアントはサーバーと同様にこの有効期限を検査でき、有効期限が過ぎている場合、クライアントはログインにリダイレクトして戻ることができます。クライアントが期限切れのトークンを使用しようとすると、サーバーはリクエストを拒否します。
どのようにリフレッシュされますか？
部分的または完全に信頼されたクライアントは、更新トークンを利用できます。これらは、前述のアクセストークンとは異なります。リソースへのアクセスを許可しません。代わりに、ユーザーに再認証を強制することなく、認証サーバーに新しいアクセストークンを要求する機能をクライアントに付与します。
プロセスは一般に行きます：
- クライアントはAPIリクエストの作成を開始し、アクセストークンを調べます
- 期限切れのアクセストークンが見つかりました
- クライアントは更新トークンを認証サーバーに送信し、新しいアクセストークンを要求します
- クライアントには新しいアクセストークンが提供されます
- クライアントは新しいアクセストークンでAPIリクエストを送信します
更新トークンは、ユーザーが認証するときに要求できます。更新トークンは通常、有効期限が長いですが、それらから発行されたアクセストークンは有効期限が短いです。これにより、サーバーは権限を取り消す機会が与えられ、それが次の発行されたアクセストークンに反映されます。
@Harry Ninhがコメントで言ったように、トークンの有効期限はニーズの問題である傾向があるため、ほとんどのシステムではこれを構成でき、その期間は数分から永久までの間のいずれかになります。また、ほとんどのシステムにはトークンリフレッシュメソッドがあります。それは、トークンが使用された後のトークンの有効期限を考慮して、トークンの使用後に自動的に行うことも、明示的なトークンリフレッシュメソッドにすることもできます。私が選択しなければならなかった場合、私は最初の方法に行きますが、それは単なる意見です。
また、ほとんどのシステムには、トークンを即座に無効にするために呼び出すことができるトークン失効メソッドもあります。
その場合、認証サーバーがトークンを保持するのに必要な時間はどれくらいですか？
これは、使用するトークンの実装に完全に依存します。例のJWTはステートレスであり、最も基本的な実装ではサーバーに格納されている情報は必要ありません。ステートフルトークンの場合は、トークンの有効期間よりも少し長く保持して、常に有効なトークンと常に一致できるようにすることをお勧めします。
トークンが失効メソッドを介して、または失効したために失効した場合は、トークンを格納しているサーバーからこのトークンを安全に削除できます。これは、トークンが承認に使用できなくなることを意味します。
認証サーバーに格納されたトークンは、しばらくすると無効になりませんか？
それは、私が調べたすべてのソリューションに、トークンの有効期限が切れるときを示すタイムスタンプが含まれていました。この時点で、トークンはユーザーの認証に有効ではなくなりました。
どのようにリフレッシュされますか？
これは実装によって異なります。 @Zalomonが言及したように、一般的な方法はトークンの更新メソッドを実装することです。これは通常、既存のトークンを認証に使用して新しいトークンを生成し、新しいトークンを送り返して古いトークンを置き換えます。
もう1つの方法は、ユーザーのセッションをトークンで期限切れにして、強制的に再度ログインさせることです。
SSOシステムで使用されるベアラートークン/ JWT/SAMLアサーション/その他のアーティファクトは、特定のユーザーの権利の検証済みで検証可能な信頼できる主張を、一時的な期間で表します。 JWTには有効期限があります（例：expires_in = 3600秒）、SAMLアサーションには有効期限がありますstamp（例：Not on or after = 2017-06-20 11:38:01）。
それを除いて、すべてが非常に一般的です。権利の主張は、ロールのメンバーシップ、リソースへのアクセスなど、何でもかまいません。
2つの一般的なアプローチ
この種のメカニズムが認証コンテキストで使用されるのを見た方法は2つあります。
1。 assertion/token/artifactは、システムにアクセスする権利を表します。
この場合、認証サーバーのトークンは本質的に長い持続時間（たとえば、20〜40分）を持ち、マルチドメインセッションCookieとして機能します。有効期限が近づくと、認証サーバーに戻って「更新」または「更新」する必要があり、結果として新しいトークンを取得する可能性があります。
一部のシステムでは、更新操作に認証サーバーへのラウンドトリップが必要ですブラウザ自体。それ以外の場合は、バックエンドのWebサービスを介して実行できます。後者は実装の「純粋」ではありませんが（理想的には、認証サーバーのみがトークンを提供できる必要があります）、特定の状況では、エンドユーザーにとって物事をよりクリーンに保つ必要があります。一時的であっても、どこか別の場所でブラウザ。
2。トークンはinitiateシステムへのアクセス権を表します
この場合、認証サーバーは比較的短い期間（たとえば60秒）のトークンを発行し、ドメインサーバーはこのトークンを独自のセッション管理メカニズムで一種のパスワードとして使用します。その後、ドメインサーバーは独自のセッションCookieを発行し、認証サーバーのトークンは不要になります。ドメインサーバーは、セッションCookie自体の更新を担当します。これは、そのようなものがWebプラットフォームに組み込まれているため、通常は非常に簡単です。 ASP.NETフォーム認証。
このアプローチの欠点は、真のSSOではないことです。認証サーバーに戻って新しいトークンを取得して新しいドメイン固有のセッションを開始しないと、ドメイン間をシームレスに移動できません。しかし、メリットは、実装がはるかに簡単になることです。
それで...更新する必要がありますか？
はい。ただし、設計方法によっては、認証サーバーによって発行されたトークンを更新したり、ドメインサーバーが所有しているトークンを更新したりすることができます。
認証サーバーは、ユーザーを認証するためのいくつかの完全に標準的な方法を備えた完全に通常のWebサイトと考えてください。
- ユーザー名とパスワードのデータベースを持っています
- NTLM/Kerberos認証を使用します
- 等...
他の標準的なWebサイトと同様に、ユーザー名とパスワードを使用してログインした場合、将来の要求でそのユーザーを覚えておく必要があります。他のWebサイトと同様に、そのCookieの有効期限などは要件によって異なります（たとえば、 20分間のスライドセッション、3か月の永続的なCookie）
SSO /認証トークンの要素は、domain1が関与し、認証サーバー認証メカニズムを利用できるようにしたい場合にのみ機能します。 認証トークンの目的は、認証されたユーザーが安全な方法でいるdomain1と認証サーバーが通信できるようにすることです。
認証サーバーはトークンをブラウザーに保存しますか？
必要な場合は必要ですが、必要はありません-認証サーバーに認証済みユーザーを追跡させるメカニズム（Cookieなど）は問題ありません。 Windows authの場合、すべてのリクエストが認証されます。認証サーバーは、誰が認証されるかを知っている限り、いつでも認証トークンを作成できるため、トークン自体を保存する必要はありません。
Domain1もトークンを保存する必要がないことに注意してください-トークンを保存することもできますが、これはかなり一般的なことですが、有効期限とユーザー名が同じである標準のASP.Net Cookieを書き込むことも同様に有効です。認証トークン。認証されたユーザーが誰であるかをdomain1が認識すると、認証トークンがその目的を果たします。
どのようにリフレッシュされますか？
通常、認証サーバーは、独自のCookieが有効期限が切れる前に期限切れになるトークンを発行します。たとえば、認証サーバーがユーザーを7日間ログインし続けるとすると、たとえば12時間続くトークンを発行することができます。シナリオはこのように見えるかもしれません
- 月曜日の朝、ユーザーはdomain1に移動し、認証サーバーを介してログインします。認証サーバーは7日間続くCookieを書き込み、12時間で期限切れになるトークンをdomain1に送信します。 domain1もCookieを保存しますが、これは12時間続きます。これは、ユーザーがその日の残りの間domain1を引き続き使用できることを意味します。
- 火曜日にユーザーはdomain1に戻り、domain1のCookieがなくなったため、認証サーバーに転送されますが、認証サーバーからの7日間のトークンが残っているため、ユーザーは直接ログインし、認証トークンが直接送信されます。 domain1-ユーザーに表示されるのは、ページが数回更新されることだけです。
したがって、domain1の「更新メカニズム」は、認証サーバーに対して再度認証することです。トークンの期間が短く、ページ更新の「ちらつき」が望ましくない場合は、非表示のiframeでこのプロセスを実行するなどのトリックを使用できます。
Auth Serverは、ユーザーがそのドメインにアクセスするたびに新しいCookieを書き込む機会があることに注意してください（通常のWebサイトにすぎないことに注意してください）。つまり、認証サーバーはセッションを「更新」することもできます。 7日間の期限切れをローリング7日間の期限切れにします。
Domain1とdomain2が相互に信頼している限り、「中間者」の認証サーバーを必要としない別の方法があります。選択した公開鍵暗号方式または共有秘密を使用してJWTベアラートークンに署名し、それらのトークンを使用して他のドメインのアクセストークンを取得できます。
私はあえて仲介者の認証サーバーを含めることは多くのシステムにとってやり過ぎだと言います。一般的な方法として、実行しない作業の量を最大化する必要があります。