マイクロサービスアーキテクチャでのシングルサインオン
私は、いくつかのサービス（データを提供）とWebアプリケーション（HTMLを提供）を持つグリーンフィールドプロジェクトを設計しようとしています。マイクロサービスについて読んだことがありますが、よく似ています。
私がまだ抱えている問題は、SSOの実装方法です。ユーザーに一度認証してもらい、すべての異なるサービスとアプリケーションにアクセスできるようにします。
私はいくつかのアプローチを考えることができます：
Identityサービスとアプリケーションを追加します。リソースが保護されているサービスはすべて、Identity Serviceと通信して、保持している資格情報が有効であることを確認します。そうでない場合、認証のためにユーザーをリダイレクトします。
OpenIDなどのWeb標準を使用し、各サービスが独自のIDを処理するようにします。つまり、ユーザーは各サービス/アプリケーションを個別に承認する必要がありますが、その後はSSOになります。
他のアイデアを聞いてうれしいです。特定のPaaS（Herokuなど）に独自のソリューションがあり、それも受け入れられる場合。
私の以前の仕事でマイクロサービスアーキテクチャを実装していたときに、最良のアプローチは＃1に合わせて、アイデンティティサービスを追加し、それを介してサービスアクセスを許可することであると判断しました。私たちの場合、これはトークンを使用して行われました。リクエストに認証トークンが含まれている場合、そのトークンがサービスとのユーザーセッションの最初の呼び出しである場合、そのトークンをアイデンティティサービスで検証できます。トークンが検証されると、セッションに保存されるため、ユーザーのセッションでの後続の呼び出しで追加の呼び出しを行う必要はありません。そのセッションでトークンを更新する必要がある場合は、スケジュールされたジョブを作成することもできます。
この状況では、OAuth 2.0エンドポイントで認証され、トークンはドメインへの呼び出しのHTTPヘッダーに追加されました。すべてのサービスはそのドメインからルーティングされたため、トークンを取得できました私たちはすべて同じアプリケーションエコシステムの一部であったため、最初のOAuth 2.0認証は、ユーザーがアカウントに許可を与えるアプリケーションサービスをリストします。
このアプローチに追加されたのは、IDサービスがHTTPクライアントフィルターチェーンに追加され、サービスへの承認プロセスを処理するプロキシクライアントライブラリを提供することでした。サービスは、アイデンティティサービスからプロキシクライアントライブラリを使用するように構成されます。 Dropwizardを使用していたため、このプロキシは、実行中のサービスプロセスにフィルターをブートストラップするDropwizardモジュールになります。これにより、インターフェイスが大幅に変更されない限り、無料のクライアント側更新も依存サービスによって簡単に消費されるアイデンティティサービスの更新が可能になりました。
デプロイアーキテクチャは、AWS Virtual Private Cloud（VPC）と自社のデータセンターに分散されていました。 OAuth 2.0認証サービスは会社のデータセンターにあり、すべてのアプリケーションサービスはAWS VPCにデプロイされました。
私たちが取ったアプローチがあなたの決定に役立つことを願っています。他にご質問がある場合はお知らせください。
クリススターリングは、上記の標準的な認証方法を説明しましたが、それは絶対に理にかなっています。いくつかの実用的な理由から、ここに別の考えを入れたいだけです。
リソースを認証するために、認証サーバーと認証サーバーに依存する他の複数のマイクロサービスを実装しました。ある時点で、認証サーバーへのラウンドトリップが多すぎるためにパフォーマンスの問題が発生しました。また、マイクロサービスの数が増えると、認証サーバーのスケーラビリティの問題も発生しました。あまりにも多くの往復を避けるために、アーキテクチャを少し変更しました。
認証サーバーは、資格情報を使用して1回だけアクセスし、秘密キーに基づいてトークンを生成します。対応する公開キーが各クライアント（マイクロサービスサーバー）にインストールされ、認証サーバーに接続せずに認証キーを検証できます。キーには生成された時間が含まれ、マイクロサービスにインストールされたクライアントユーティリティも有効になります。標準の実装ではありませんでしたが、特にすべてのマイクロサービスが内部でホストされている場合、このモデルでかなりの成功を収めています。