Azure AD - デーモンサービスと認証コードを持つマルチテナント許可されたフロー、ターゲットテナントがclient_secretを生成できますか？

Question

私はAzure ADとOAuth 2.0プロトコルを使って作業しており、Microsoft Graph SDKの認証プロセスを処理するService/Dameonアプリケーションも作成しています。サービス/デーモンの場合はHttpWebRequestとし、client_idとclient_secretを渡してaccess_tokenを生成し、Microsoft Graph SDKに供給することができます。

また、私は成功し、管理者が認証コード付与フローを使用してアプリケーションへのアクセス権を付与している中、対象テナントに対応するサービスプリンシパルを作成しました。その後、アプリケーションは（portal.azure.com）内のOverview -> Quick tasks -> Find an enterprise appに表示されます。

私はサービス/デーモンのアプローチを活用しながら、ターゲットテナントの管理者がアプリケーションを認可できるようにするアプローチがあります。ターゲットテナントがclient_secretを作成してそのテナント？

Answer 1

短い回答はいいえ。管理者の同意あなたのマルチテナントアプリが時：

1. Aサービスプリンシパルは、そのテナントにそれのために作成されたアプリが要求した
2. 権限がそのテナントに

が付与されているこれは、あなたのアプリができることを意味しますテナントに対してクライアントクレデンシャル（id + secret）で認証されるようになりました。したがって、承認されたすべてのテナントで同じキーが機能します。

あなたのアプリは、いつでも誰でもログイントークンを取得することができます。そのため、アプリにはデータを分けておく責任があります。

https://login.microsoftonline.com/company.com/oauth2/tokenからアクセストークンを取得した場合、トークンにはそのテナントの識別子が含まれます。また、Microsoft Graph APIのようなAPIは、そのトークンでそのテナントのデータのみを提供します。したがって、あなたのアプリは、ユーザーのテナントIDクレームと等しいテナントIDを持つトークンだけを使用するようにする必要があります。

Answer 2

私は、juunasの回答は99％正しいと言います。短い答えは基本的には「いいえ」であり、彼が言及している考察もしっかりしています。

しかし、私は、これは特定の考慮事項の下で技術的に可能であると考えています。管理者がデーモンサービスに同意すると、顧客のテナントにサービスプリンシパルが作成されます。サービスプリンシパルは、テナント単位でクライアントの秘密として使用できる資格情報の追加を許可します。つまり、実際にアプリケーションからプログラム主体に資格情報をプログラムで追加する方法はありません。テナントのサービスプリンシパルに新しい資格情報を追加するには、管理者にスクリプトを実行する必要があります。

このすべてを行っても、お客様のサービスが顧客/テナントベースでも分離されていることを確認する必要があります。セキュリティ上は、あなたの特異デーモンがすべての秘密にアクセスできるならば、テナントクライアントの秘密を作成するのは意味がありません。