IdentityServer3のカスタム認可タイプで、「act-as」スキーマのトークン内にトークンを追加する必要があります。 私はPreserveAccessTokenで試しましたが、現在のClaimsPrincipalでクレームとしてトークンを追加するだけですが、チェーン内の次のサービス/ APIに別のトークンを渡す際にクレームとして入れ子にする方法が見つかりません。IdentityServer3 - カスタム許可タイプのトークン内トークンを追加する（act-as schema）
この背後にあるアイデアは、コールのチェーン内でエンドユーザから最後のサービス/ apiまでのすべてのホップの監査を維持できることです。
これはカスタムグラントを使用して達成できます。これにより、トークンエンドポイントをカスタムの「操作」で拡張することができます。委任されたクレームを含むトークンを発行します。トークン
言った - これはおそらく、複数のホップを介してユーザIDを伝えるための最も高価な方法です：https://identityserver.github.io/Documentation/docsv2/advanced/customGrantTypes.html
ここにも、あなたのシナリオに近づくサンプルです。
バックエンドシステム間に信頼できるサブシステムがある場合は、必要なデータをペイロードとして送信するだけで、はるかに簡単で高速に処理できます。
はい、私はしばらくの間、マルチホップのサンプルを試してきました。私の問題は、コールのチェーン内で3番目のAPIを試してみるときに起きました.3番目のAPIが前のクライアントを追跡するだけなので、最初のコールを失うことになります。ペイロードでデータを送信することに懸念があるのは、私が承認/トークンロジックによって処理する必要があると思う責任をApiのビジネスロジックに委任する必要があるということです。 – CesarD
おそらく私が達成しようとしているのはこれに関連しています：https://tools.ietf.org/html/draft-hunt-oauth-chain-01 – CesarD
これを達成するために何らかの方法でacr値を使用することは可能ですか？ – CesarD
なぜcorrelationIdを作成せず、代わりにそれをいくつかのヘッダーの一部として配置しますか？ –
例えば、コールチェーン内の最後のリンク（例えば、apiなど）は、DBに対する実際の呼び出しを行い、そのような操作の監査を記録しようとするので、オペレーションスターター（エンドユーザー）オペレーションの一部であった中間のすべてのサービス/ apis。 IdSrvrがトークンを別のトークンに入れ子にすることができれば、多くの追加作業をせずにすべてを解決するはずです。 – CesarD