前へ

次へ

アクセス許可と同意について探索する

完了

Microsoft ID プラットフォームに統合されるアプリケーションが従う承認モデルは、データへアクセス可能な方法に対する制御をユーザーと管理者に与えます。

Microsoft ID プラットフォームでは、OAuth 2.0 承認プロトコルが実装されています。 OAuth 2.0 は、ユーザーに代わってサードパーティのアプリが Web でホストされるリソースにアクセスできる方法です。 Web でホストされる任意のリソースは、Microsoft ID プラットフォームと統合されると、リソース識別子つまり "アプリケーション ID URI" を保有します。

Microsoft の Web でホストされるリソースの例をいくつか次に示します。

• Microsoft Graph: https://graph.microsoft.com
• Microsoft 365 メール API: https://outlook.office.com
• Azure Key Vault: https://vault.azure.net

Microsoft ID プラットフォームと統合されたサードパーティのリソースも同様です。 これらのリソースのいずれでも、機能をより小さいまとまりに分割するために使用できるアクセス許可のセットを定義できます。 リソースの機能を細かいアクセス許可セットにまとめると、サードパーティのアプリを、その機能を実行するために必要なアクセス許可のみを要求するように構築できます。 ユーザーと管理者は、アプリによってアクセスできるデータを把握できます。

OAuth 2.0 では、これらの種類のアクセス許可セットは "スコープ" と呼ばれます。 "アクセス許可" と呼ばれることもよくあります。 Microsoft ID プラットフォームでは、アクセス許可は文字列値として表現されます。 scope クエリ パラメーターでアクセス許可を指定することによって、アプリが必要なアクセス許可を要求します。 ID プラットフォームは、いくつかの適切に定義された OpenID connect スコープ とリソースベースのアクセス許可をサポートします (各アクセス許可は、リソースの識別子またはアプリケーション ID の URI にアクセス許可値を追加することによって示されます)。 たとえば、アクセス許可文字列 https://graph.microsoft.com/Calendars.Read を使用して、Microsoft Graph のユーザーの予定表を読み取るアクセス許可を要求します。

アプリでは、通常、Microsoft ID プラットフォーム承認エンドポイントへの要求でスコープを指定することにより、これらのアクセス許可を要求します。 ただし、一部の高い特権のアクセス許可は、管理者の同意によってのみ許可することができます。 これらは、管理者の同意エンドポイントを使用して要求または付与できます。

注意

Microsoft ID プラットフォームの承認、トークン、または同意エンドポイントへの要求では、スコープ パラメーターでリソース識別子が省略されている場合、リソースは Microsoft Graph と見なされます。 たとえば、scope=User.Read は、https://graph.microsoft.com/User.Read と同じです。

アクセス許可の種類

Microsoft ID プラットフォームでは、"委任されたアクセス許可" と "アプリ専用アクセス" の 2 種類のアクセス許可がサポートされています。

• 委任されたアクセス許可は、サインインしているユーザーが存在するアプリで使用されます。 これらのアプリでは、アプリが要求するアクセス許可にユーザーまたは管理者が同意します。 目的のリソースに対する呼び出しを行うときにサインインしたユーザーとして振る舞う権限を、アプリに委任します。

• アプリ専用アクセス許可は、サインイン済みユーザーが存在せずに実行されるアプリ (バックグラウンド サービスやデーモンとして実行されるアプリなど) で使われます。 管理者だけがアプリ専用アクセス許可に同意できます。

同意の種類

Microsoft ID プラットフォームのアプリケーションでは、必要なリソースや API へのアクセス権を取得するために同意を利用します。 正常に機能させるため、ご利用のアプリではさまざまな種類の同意を認識する必要があります。 アクセス許可を定義する場合、ユーザーがアプリや API へのアクセス権を取得する方法も理解しておく必要があります。

同意の種類には、"静的ユーザーの同意"、"増分と動的ユーザーの同意"、"管理者の同意" の 3 つがあります。

静的なユーザーの同意

静的なユーザーの同意シナリオでは、Azure portal のアプリの構成で、必要なすべてのアクセス許可を指定する必要があります。 ユーザー (または、必要に応じて管理者) がこのアプリに同意していなかった場合、Microsoft ID プラットフォームでは、その時点でユーザーに同意を求めるメッセージが表示されます。 静的なアクセス許可により、管理者は、組織内のすべてのユーザーの代理として同意することができます。

アプリの静的アクセス許可は Azure portal で定義されており、コードを適切に維持できます。ただし、開発者には、次の点が問題となります。

• アプリで、ユーザーの初回サインインの時点で必要になる可能性があるすべてのアクセス許可を要求する必要があります。 アクセス許可のリストは長くなる場合があり、エンドユーザーが初回サインイン時にアプリのアクセスを承認することを阻げる要因となります。

• アプリでアクセスする可能性のあるすべてのリソースが事前にわかっている必要があります。 不特定の数のリソースにアクセスする可能性があるアプリを作成することは困難です。

増分および動的なユーザーの同意

Microsoft ID プラットフォーム エンドポイントを使用して、Azure portal のアプリケーション登録情報に定義された静的アクセス許可を無視し、代わりに増分でアクセス許可を要求することができます。 顧客が他のアプリ機能を使用するため、事前に最小のアクセス許可セットを要求し、時間の経過とともにさらに要求することができます。

これを行うために、任意の時点でアプリに必要なスコープを指定できます。その場合、アクセス トークンの要求時に scope パラメーターに新しいスコープを含めます。アプリケーションの登録情報に事前定義する必要はありません。 要求に追加された新しいスコープにユーザーがまだ同意していない場合、新しいアクセス許可のみの同意を求められます。 増分または動的な同意は、委任されたアクセス許可にのみ適用され、アプリ専用アクセス許可には適用されません。

重要

動的な同意は便利な場合もありますが、大きな問題もあります。 管理者の同意を必要とするアクセス許可の場合、同意する時点では、管理者の同意エクスペリエンスがこれらのアクセス許可を把握していないことです。 管理者特権のアクセス許可が必要な場合、またはアプリが動的な同意を使用する場合は、Azure portal で (管理者の同意が必要なアクセス許可のサブセットだけでなく) すべてのアクセス許可を登録する必要があります。 これにより、テナント管理者が、すべてのユーザーを代表して同意できます。

管理者の同意

管理者の同意は、特定の高い権限のアクセス許可がアプリに必要な場合に必要となります。 管理者の同意により、管理者は、組織の高い権限が必要なデータにアプリやユーザーがアクセスすることを承認する前に制御を増加できます。

組織の代わりに管理者が同意する場合でも、アプリに静的なアクセス許可が登録されている必要があります。 管理者に組織全体の代理として同意してもらう必要がある場合には、アプリ登録ポータルでアプリのそれらのアクセス許可を設定します。 これにより、アプリケーションを設定するために組織の管理者に必要なサイクルが減ります。

個々のユーザーの同意を要求する

OpenID Connect または OAuth 2.0 認可要求では、スコープ クエリ パラメーターを使用して、アプリから必要なアクセス許可を要求できます。 たとえば、ユーザーがアプリにサインインするときに、アプリは次の例のような要求を送信します。 改行は、読みやすくするために使用されます。

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

scope パラメーターは、アプリが要求している委任されたアクセス許可の一覧であり、空白文字で区切られています。 各アクセス許可は、リソースの識別子 (アプリケーション ID URI) にアクセス許可の値を追加して示されます。 上の要求では、ユーザーの予定表を読み取り、ユーザーとしてメールを送信するためのアクセス許可をアプリが必要としています。

ユーザーが資格情報を入力すると、Microsoft ID プラットフォームは、"ユーザーの同意" の一致するレコードがないか確認します。 ユーザーが過去に要求されたどのアクセス許可にも同意しておらず、管理者も組織全体の代わりにそれらのアクセス許可に同意していない場合、Microsoft ID プラットフォームは、要求されたアクセス許可を付与するようにユーザーに求めます。

続行