クライアント資格情報フローによるグラフ認証-アプリはユーザーアカウントのみにアクセスできますか、それとも組織全体にアクセスできますか?

BigGerman

メッセージを読むためにOffice365の受信トレイにアクセスする必要があるデーモンスクリプトがあります。現在、Outlook Rest APIのV1.0で基本認証を使用していますが、これは正常に機能しますが、廃止されたため、GraphAPIとOAuth2.0認証に移行することを検討しています。ここで説明するように、クライアントの資格情報のフローはデーモンスクリプトに最適なオプションのようですが、アプリが持つ権限の範囲について混乱しています。上でリンクした記事では、アプリが組織全体にアクセスできるように見えますが、自分のアカウントにアクセスできるようにするために必要なのはスクリプトだけです。アプリに他のユーザーのアカウントへのアクセスを許可したくないし、IT部門もそれを許可しないと思います。

では、クライアント資格情報認証を使用する場合のアプリの権限の範囲は何ですか? 答えが「組織全体」である場合、アクセス許可を自分のアカウントだけに制限する方法はありますか?そうでない場合、他のオプションは何ですか?

編集:同様の質問がここで尋ねられましたが、答えは得られませんでした。

マーク・ラフルール

それは正しいです。クライアント資格情報を使用する場合、定義上、アプリケーションスコープを使用しています。これらのトークンには「ユーザー」コンテキストがないため、テナント全体の権限です。これが、アプリケーションスコープを使用する前に常に管理者の同意が必要な理由です。

ドキュメントから

Mail.Read(すべてのメールボックスのメールを読む)

サインインしたユーザーがいなくても、アプリがすべてのメールボックスのメールを読み取れるようにします。

これが他の人に展開しているものではなく、自分のメールボックス専用である場合は、offline_accessスコープで承認コード付与を使用してaccess_tokenとの両方を取得できrefresh_tokenます。

トークンをアプリに「シード」すると、アプリはを使用して、有効期限が切れたときにrefresh_token新しいアプリを取得できaccess_tokenます。アプリ/サービスを再シードする必要がある場合がありますが(たとえば、パスワードが変更された場合)、それ以外の場合は、操作なしで機能するはずです。

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]

編集
0

コメントを追加

0

関連記事

Related 関連記事

ホットタグ

アーカイブ