設計上の考慮事項

Question

私は私の質問のための前提として、シナリオをあげる：

• CRMクライアントアプリ
• お客様のAPI
• IDP API
• お客様のAPIに必要な範囲を保護： "customers"
• CRMクライアントアプリケーションOAuth2クライアントには "customers"スコープアクセス権が付与されています
• CRMクライアントアプリケーションがスコープ「custo

開発者は、顧客APIからの請求書発行APIを新しいInvoices APIにリファクタリングして、今度は「請求書」のスコープが必要になると判断することもあります。 Customers APIがCRMクライアントアプリケーションに予期した結果を返すためには、Invoices APIを呼び出して、その部分を呼び出し側のアプリケーションに渡す必要があります。したがって、新しいスコープ要件のためにトークンを渡すことはできません。

CRMクライアントアプリケーションで新しいスコープを追加する必要がなくなり、期待どおりの結果をCRMアプリケーションに返すことができますか？

1つのアプローチは、Customers APIがクライアントの資格情報として信頼できるサブシステムとして認証することですが、Invoices APIはどのように開始ユーザーについて知っていますか？ここでのアイデアは、既存のクライアントアプリケーションで機能を分割せずに機能を分離することです。

Answer 1

マルチホップまたはact-as付与システムを使用すると役立つ可能性があります。私が正しく理解している場合、あなたのシナリオは次のとおりです。Client -> API1 -> API2

あなたは各層が自分のスコープを持つようにしたい場合は、act-as tokensお手伝いを致します（あなたはあなたの説明によるください）。

非常に良い概要はIdentityServer samples issue #182でご覧になれます。このシナリオの例はtheir Git repositoryです。