以前の仕事でマイクロサービス アーキテクチャを実装していたときに、最善のアプローチは 1 番目の「ID サービスを追加し、それを介してサービス アクセスを承認する」に沿ったものであると判断しました。私たちの場合、これはトークンで行われました。リクエストに認証トークンが含まれていた場合、それがサービスとのユーザー セッションでの最初の呼び出しである場合、ID サービスでそのトークンを検証できます。トークンが検証されると、セッションに保存されるため、ユーザーのセッションでの後続の呼び出しでは、追加の呼び出しを行う必要がありませんでした。そのセッションでトークンを更新する必要がある場合は、スケジュールされたジョブを作成することもできます。
この状況では、OAuth 2.0 エンドポイントで認証を行っており、ドメインへの呼び出しのためにトークンが HTTP ヘッダーに追加されました。HTTP ヘッダーからトークンを取得できるように、すべてのサービスがそのドメインからルーティングされました。私たちは皆、同じアプリケーション エコシステムの一部だったので、最初の OAuth 2.0 認証では、ユーザーが自分のアカウントに対して許可を与えるアプリケーション サービスがリストされていました。
このアプローチに追加されたのは、HTTP 要求フィルター チェーンに追加され、サービスへの承認プロセスを処理するプロキシ クライアント ライブラリを ID サービスが提供することでした。このサービスは、ID サービスからプロキシ クライアント ライブラリを使用するように構成されます。Dropwizard を使用していたため、このプロキシは実行中のサービス プロセスにフィルタをブートストラップする Dropwizard モジュールになります。これにより、インターフェイスが大幅に変更されない限り、クライアント側の無料の更新も含まれる ID サービスの更新を、依存するサービスによって簡単に使用できるようになりました。
当社のデプロイ アーキテクチャは、AWS Virtual Private Cloud (VPC) と自社のデータ センターに分散されていました。OAuth 2.0 認証サービスは会社のデータセンターにあり、すべてのアプリケーション サービスは AWS VPC にデプロイされていました。
私たちが取ったアプローチがあなたの決定に役立つことを願っています. 他にご不明な点がございましたら、お問い合わせください。