Spring Cloud SecurityでOAuth2「トークン交換」を実装する方法

Question

誰かがSpring Cloud Security（OAuth2を使用）で「トークン交換」手法を実装する方法を知りたいかどうかを知りたいと思います。

現在、私は、ZuulProxyを使用してOAuth2トークンを「リレー」してSSOを実装するために、マイクロサービス環境で「トークンリレー」技術を実装しました。これは素晴らしいことですが、すべてのマイクロサービスが同じclientIdを使用していることを意味します（ZuulProxyは、authorization_code許可タイプと提供されたclientIdのみでトークンを中継します）。 しかし、マイクロサービス内のコールでは、トークンを「交換」したいと思います。これは、ZuulProxyがリレーするトークンが、マイクロサービスAのクライアントとしてMicroservice Aを認証/承認するために必要なトークンではないことを意味する場合があります。

現在、「SpringブートとSpringセキュリティOAuth2では、シングルサインオン、トークンリレー、トークン交換などの一般的なパターンを実装するシステムを迅速に作成できます。 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03

私が言ったように：私は、彼らが意味リファレンスドキュメントのOAuth2のこの拡張の実装で「トークン取引所」と、私は必要なものは基本的である、この仕様で説明していることと思います（http://cloud.spring.io/spring-cloud-security/spring-cloud-security.html）

私はSSOとトークンリレーの使い方を理解していますが、リファレンスドキュメントで「トークン交換」を実装する方法についてはこれ以上説明することはできません。私は実装例も見つけられませんでした。

詳しい情報や例はどこにありますか？

ありがとうございます！

Answer 1

Microservice AからMicroservice Bへの呼び出しを行うためにトークンを「交換する」必要があり、中継が十分でない理由が不思議です。サービス間リクエストのトークンを交換して達成しようとしていることは何ですか？

私たちはこのNordic APIs entryに記載されているものに非常に似ています。短いバージョンでは、外部の呼び出し側が不透明なトークンを使用しますが、要求がゲートウェイを通過すると、すべてのマイクロサービスは同じトークンのJWT表現を取得します。私たちは、JWT交換に対して不透明を実行するためのカスタムエンドポイントを実装しなければなりませんでした。サービスが相互にやり取りする必要がある場合、AがBを呼び出す必要があるときにはトークンを交換しません。単にトークンを中継します。 RestTemplateまたはFeignクライアントは、AからBへのトークンを自動的に転送します。したがって、コンテキストは失われません。

ここで、アクセスを制御したい場合、JWTはオーディエンス値のコレクションを指定するか、スコープ経由でアクセスを強制できます。実際には、ユースケースに応じて2つの組み合わせを実行しています。

トークンを交換することは安価な操作ではありません。実際、規模が非常に高価で、サービス内通信のトークン交換が必要な理由を本当に考慮する必要があります。すべてのAPIリクエストでサービスAの呼び出しサービスBが発生し、トークン交換を行う必要がある場合は、認可サービスがそのタイプのワークロードを処理できることを確認する必要があります。最後に、IETFトークン交換は依然としてドラフトステータスであり、その進化ではかなり変更されているため、仕様が完成に近づくまで実装のアドバイスはあまり期待していません。