しばらくの間、SPA の SSO ソリューションを調査してきました。微妙な違いがあるソリューションはたくさんありますが、実際には誰もが SSO について同じ理解を持っているわけではなく、SPA 用の確立された SSO のパターンがあまり存在しないこともわかりました。したがって、詳細な設計/アーキテクチャを求めているわけではありませんが、このトピックに関する一般的な慣行があるかどうかを確認してみてください.
SSO とはどういう意味ですか?
- 開発中のいくつかの新しい SPA があり (モバイル アプリやタブレット アプリも可能)、これらは異なるサーバーにデプロイされ、異なるドメインを持ちます。
- また、すべてのユーザー ID が保存される中央の IdP (authServer) もあります。
- SPA1にログインし、ボタンをクリックしてSPA2 (またはSPA3、SPA4 、場合によっては) に移動すると、ユーザー資格情報を入力する必要がなくなり、自動的にログインされます。
SPAとの違いは?(通常の Web アプリとは対照的に)
SAMLのような古いソリューションでさえ、いくつかのソリューションを見てきました(SSOについて理解したいだけです..)。私の現在の候補はOpenId Connectですが、私の理解が正しければ、SPA の違いに気付きました。通常の Web アプリとは異なり、SPA には通常、バックエンド サーバーがありません (または、持たないようにしています)。SPA が備えているのは、スクリプト、スタイル シート、および画像と共に静的ページを提供する単なるサーバーです。
問題は次のとおりです。
OpenId Connectは、 OAuth2 Authorization Code付与タイプに基づいています。つまり、次のいずれかを意味します。
- SPA を機能させたい場合は、SPA ごとにバックエンド プロキシのようなモジュールが必要です。
- auth0 が提供するものなど、クライアント側の SSO を行うために別のソリューションを使用します
- 他の解決策/例は見つかりませんでした
私の質問:
上記のポイント1について、私の理解は正しいですか?通常の Web アプリのように、SPA にバックエンド コードを持たせない方がよいでしょうか?
上記のポイント 2 については、解決策のように聞こえますが、 OAuth2 Implicit grant typeとは本質的にどのように異なるのでしょうか?
また、知っておくべきであるが、まだ調査していない他のソリューション (フレームワーク、プロトコルなど) はありますか?