WebにはJson Web Token、認証にJWT（）を使用することに関する多くの情報があります。しかし、マルチドメイン環境でシングルサインオンソリューションに JWTトークンを使用する場合のフローの明確な説明はまだわかりませんでした。
私は、さまざまなホスト上に多数のサイトがある会社で働いています。example1.comとexample2.comを使用してみましょう。シングルサインオンソリューションが必要です。つまり、ユーザーがexample1.comで認証された場合、そのユーザーもexample2.comで自動的に認証されるようにします。
OpenId Connectフローを使用して、example1.comで認証するユーザーが最初に認証サーバー（またはOP「OpenIdプロバイダー」）にリダイレクトされることを理解しています。ユーザーはそのサーバーで認証され、署名されたJWTトークンを使用して元のexample1.comサイトにリダイレクトされます。（後でそれ自体が実際のJWTトークンと交換できる中間トークンを返す別のフローがあることを理解していますが、これは私たちには必要ではないと思います）...
これで、ユーザーはexample1.comに戻り、認証されました。AuthenticationヘッダーでJWTトークンを渡して要求を出すことができ、サーバーは署名されたJWTを検証できるため、ユーザーを識別できます。いいね！
最初の質問：
JWTトークンはどのようにクライアントに保存する必要がありますか？繰り返しになりますが、これについては多くの情報があります。人々Web Storageは、古き良き時代というよりは、使用することが道のりであることに同意しているようですcookies。JWTをブラウザーの再起動間で永続的にしたいのでLocal Storage、ではなくを使用しましょうSession Storage...
これで、ユーザーはブラウザを再起動でき、JWTトークンの有効期限が切れていない限り、example1.comで認証されます。
また、example1.comが別のドメインにAjaxリクエストを行う必要がある場合、CORSを構成するとそれが可能になることを理解しています。ただし、主な使用例はクロスドメインリクエストではなく、シングルサインオンソリューションです。
したがって、主な質問：
ここで、ユーザーがexample2.comにアクセスして、すでに持っているJWTトークンを使用して認証されるようにした場合、フローはどうなりますか？Local Storageはクロスドメインアクセスを許可していないようです。そのため、この時点ではブラウザはJWTトークンを読み取ってexample2.comにリクエストを送信できません。
する必要があります：
- ユーザーは再び認証サーバーにリダイレクトされますか？ユーザーがexample1.comに対して認証されると、 認証サーバーはユーザーにCookieを設定している可能性があるため、example2.comに対するこの新しい認証要求はそのCookieを使用して、ユーザーがすでに認証されていることを確認し、すぐにexample2.comにリダイレクトします 。同じJWTトークンで？
- または、ブラウザがexample2.comで、認証サーバーに再度アクセスすることなくJWTトークンにアクセスできますか？私はそこにある参照クロスストレージ・ソリューションは、しかし、それらの広く使用されていますか？それらは、クロスドメインSSO環境の推奨ソリューションですか？
私たちは空想したいものは何もありません、私たちは主に使用されるソリューションで満足します！