最近、 Beego Frameworkに基づいて複数の Web アプリケーションにSSO(Single-Sign-On)を実装するプロジェクトがあります。最も人気のある SSO プロジェクトはCASで、中央に CAS サーバーが必要で、各 Web アプリケーションの前に CAS クライアントが必要です。残念ながら、 go-cas/casとbeegoをサポートする adanteng/casを除いて、Golang で書かれた公式の CAS クライアントはないようです。
しかし、CAS のワークフローは少し複雑です。リダイレクトが多すぎ、CAS、Web アプリ、およびユーザー ブラウザー間で送信されるチケットが多すぎます。次の図のように、人々が認証サービスをすべての Web アプリの前面ではなく中央にデプロイする理由がわかりません。
この図では、すべてのリクエストが最初に認証サービスで強制的に処理され、認証に成功した場合は、セッション ID が生成され、Cookie と Redis に保存されます。この ID は他のマイクロサービスによって共有されます。リダイレクトやチケットはまったくなく、送信を要求するだけです。
この図は可能ですか、それとも私が無視したいくつかの重要な問題ですか?
更新 0
Nadh 氏が助言するように、セッション共有の方法は実際にはスケーラブルでもモジュール式でもありません。nginx-ssoでの Heipei の創作活動のように、認証サービスとダウンストリーム サービスの間のリクエストのヘッダーで、名前、電子メールなどのユーザー情報を送信するのはどうですか? Sam Newman が本のBuilding Microservicesで共有しているように、SSO ゲートウェイとして機能させることは可能ですか?
更新 1
Heipei と Sam Newman からあまり誤解がないことを願って、私の幼稚な考えを少し明確に説明するために、より詳細な図を以下に示します。
非常に多くのリダイレクトとハンドシェイクを処理するのではなく、最初にすべてのリクエストが認証サービスで処理され、MySQL からユーザー情報がセッション プロバイダーとして Redis に書き込まれ、HTTP ヘッダーがダウンストリーム サービスに送信されます。正常に認証されました。
このように、ユーザー情報は上記の共有 Redis as Nadh警告の代わりに HTTP ヘッダーを介して送信され、Redis は認証サービスでデプロイするか、認証インスタンス間でのみ共有することができます。
更新 2
Cookie と Session は昔ながらの技術のようです。Cookie のクロスドメインの問題とセッションの共有の問題は、最新の Web アプリケーションのスケーラビリティと柔軟性に対する主な障壁です。幸いなことに、JSON Web Token は、ユーザー情報 (おそらく ID で十分) のストレージをサーバー側からクライアント側に移動し、必要な場合にのみ送信することで、複数の軽量サービスに最適なシングル サインオン ソリューションになりました。