Azure Active Directory とアプリケーションの統合Integrating applications with Azure Active Directory

注意

この記事は、「Azure Active Directory 開発者ガイド」の一部です。This article is part of the Azure Active Directory developer's guide.

エンタープライズ開発者や SaaS (サービスとしてのソフトウェア) プロバイダーは、商用クラウド サービスまたは基幹業務アプリケーションを開発し、それらを Azure Active Directory (Azure AD) と統合することによって、自社のサービスにセキュリティで保護されたサインインと認可を実現することができます。Enterprise developers and software-as-a-service (SaaS) providers can develop commercial cloud services or line-of-business applications, that can be integrated with Azure Active Directory (Azure AD) to provide secure sign-in and authorization for their services. アプリケーションまたはサービスを Azure AD と統合するには、まず開発者がアプリケーションを Azure AD に登録しておく必要があります。To integrate an application or service with Azure AD, a developer must first register the application with Azure AD.

この記事では、Azure AD でアプリケーションの登録を追加、更新、または削除する方法について説明します。This article shows you how to add, update, or remove an application's registration in Azure AD. Azure AD と統合できるさまざまなアプリケーションの種類や、他のリソース (Web API など) にアクセスできるようにアプリケーションを構成する方法などについて説明します。You learn about the different types of applications that can be integrated with Azure AD, how to configure your applications to access other resources such as web APIs, and more.

登録されたアプリケーションを表す 2 つの Azure AD オブジェクト、およびそれらの関係の詳細については、アプリケーション オブジェクトとサービス プリンシパル オブジェクトに関するページを参照してください。Azure Active Directory を使ってアプリケーションを開発するときに使用するブランド化ガイドラインの詳細については、統合されたアプリケーションのブランド化に関するガイドラインを参照してください。To learn more about the two Azure AD objects that represent a registered application and the relationship between them, see Application Objects and Service Principal Objects; to learn more about the branding guidelines you should use when developing applications with Azure Active Directory, see Branding Guidelines for Integrated Apps.

アプリケーションの追加Adding an application

アプリケーションで Azure AD の機能を使用するには、まず Azure AD テナントにそのアプリケーションを登録する必要があります。Any application that wants to use the capabilities of Azure AD must first be registered in an Azure AD tenant. この登録プロセスでは、アプリケーションが配置されている URL、ユーザーが認証された後の応答の送信先となる URL、アプリを識別する URI など、アプリケーションの詳細を Azure AD に提供します。This registration process involves giving Azure AD details about your application, such as the URL where it’s located, the URL to send replies after a user is authenticated, the URI that identifies the app, and so on.

Azure Portal を使用して新しいアプリケーションを登録するにはTo register a new application using the Azure portal

  1. Azure Portal にサインインします。Sign in to the Azure portal.
  2. ご利用のアカウントで複数の Azure AD テナントにアクセスできる場合は、右上隅でアカウントをクリックし、ポータルのセッションを目的のテナントに設定します。If your account gives you access to more than one, click your account in the top right corner, and set your portal session to the desired Azure AD tenant.
  3. 左側のナビゲーション ウィンドウで、[Azure Active Directory] サービスをクリックし、[アプリの登録][新しいアプリケーションの登録] の順にクリックします。In the left-hand navigation pane, click the Azure Active Directory service, click App registrations, and click New application registration.

    新しいアプリケーションの登録

  4. [作成] ページが表示されたら、アプリケーションの登録情報を入力します。When the Create page appears, enter your application's registration information:

    • 名前: わかりやすいアプリケーション名を入力しますName: Enter a meaningful application name
    • アプリケーションの種類:Application type:
    • サインオン URL: 種類に [Web アプリ/API] を選択したアプリケーションについて、アプリのベース URL を入力します。Sign-On URL: For "Web app / API" applications, provide the base URL of your app. ローカル マシンで実行されている Web アプリの URL であれば、たとえば http://localhost:31544 のようになります。For example, http://localhost:31544 might be the URL for a web app running on your local machine. ユーザーはこの URL を使用して、Web クライアント アプリケーションにサインインすることになります。Users would use this URL to sign in to a web client application.
    • リダイレクト URI: 種類に [ネイティブ] を選択したアプリケーションについて、Azure AD がトークン応答を返すために使用する URI を入力します。Redirect URI: For "Native" applications, provide the URI used by Azure AD to return token responses. http://MyFirstAADApp など、アプリケーションに固有の値を入力してください。Enter a value specific to your application, for example http://MyFirstAADApp

    新しいアプリケーションの登録 - 作成

    Web アプリケーションまたはネイティブ アプリケーションの具体的な例が必要な場合には、クイック スタートを参照してください。If you'd like specific examples for web applications or native applications, check out our quickstarts.

  5. 完了したら、[作成] をクリックします。When finished, click Create. Azure AD によりアプリケーションに一意の ID が割り当てられ、アプリケーションのメイン登録ページが表示されます。Azure AD assigns a unique Application ID to your application, and you're taken to your application's main registration page. アプリケーションが Web アプリケーションとネイティブ アプリケーションのどちらであるかに応じて、アプリケーションに機能を追加するためのさまざまなオプションが表示されます。Depending on whether your application is a web or native application, different options are provided to add additional capabilities to your application. 同意の概要と、アプリケーション登録で追加の構成機能 (資格情報、アクセス許可、他のテナントのユーザーによるサインインの有効化) を有効にする方法の詳細については、次のセクションを参照してください。See the next section for an overview of consent, and details on enabling additional configuration features in your application registration (credentials, permissions, enable sign-in for users from other tenants.)

    注意

    既定では、新しく登録された Web アプリケーションは、同じテナントのユーザーのみサインインできる構成になります。By default, a newly registered web application is configured to allow only users from the same tenant to sign in to your application.

アプリケーションの更新Updating an application

アプリケーションを Azure AD に登録した後には、Web API にアクセスできるようにしたり、他の組織で使用できるようにしたりするために、登録したアプリケーションを更新する作業が必要になることがあります。Once your application has been registered with Azure AD, it may need to be updated to provide access to web APIs, be made available in other organizations, and more. このセクションでは、アプリケーションをさらに細かく構成するためのさまざまな方法を説明します。This section describes various ways in which you can configure your application further. まずは、同意フレームワークの概要を説明します。他のユーザーまたはアプリケーションが使用する必要があるアプリケーションを構築する場合には、このフレームワークについて理解しておくことが重要です。First we start with an overview of the consent framework, which is important to understand when building applications that need to be used by other users or applications.

Azure AD の同意フレームワークを使用すると、マルチテナントの Web クライアント アプリケーションやネイティブ クライアント アプリケーションを簡単に開発できます。The Azure AD consent framework makes it easy to develop multi-tenant web and native client applications. こうしたアプリケーションには、登録されている Azure AD テナントとは異なるテナントのユーザー アカウントを使ってサインインできます。These applications allow sign-in by user accounts from an Azure AD tenant, different from the one where the application is registered. また、独自の Web API に加えて、Microsoft Graph API (Azure Active Directory、Intune、および Office 365 のサービスへのアクセスに使用する API) をはじめとする Microsoft サービスの API など、各種の Web API にもアクセスが必要になることがあります。They may also need to access web APIs such as the Microsoft Graph API (to access Azure Active Directory, Intune, and services in Office 365) and other Microsoft services' APIs, in addition to your own web APIs. このフレームワークの根底には、ディレクトリのデータにアクセスする可能性があるためにディレクトリへの登録を要求しているアプリケーションに対して同意を与えるユーザーまたは管理者が存在します。The framework is based on a user or an administrator giving consent to an application that asks to be registered in their directory, which may involve accessing directory data.

たとえば、Web クライアント アプリケーションで Office 365 ユーザーの予定表情報を読み取る必要があるときは、まずそのユーザーがクライアント アプリケーションに同意を与える必要があります。For example, if a web client application needs to read calendar information about the user from Office 365, that user is required to consent to the client application first. 同意が与えられると、クライアント アプリケーションがユーザーに代わって Microsoft Graph API を呼び出し、必要に応じて予定表情報を利用できるようになります。After consent is given, the client application will be able to call the Microsoft Graph API on behalf of the user, and use the calendar information as needed. Microsoft Graph API は、Office 365 のデータ (Exchange の予定表とメッセージ、SharePoint のサイトとリスト、OneDrive のドキュメント、OneNote のノートブック、Planner のタスク、Excel のブックなど)、Azure AD のユーザーとグループなど、Microsoft クラウド サービスのさまざまなデータ オブジェクトにアクセスするための API です。The Microsoft Graph API provides access to data in Office 365 (like calendars and messages from Exchange, sites and lists from SharePoint, documents from OneDrive, notebooks from OneNote, tasks from Planner, workbooks from Excel, etc.), as well as users and groups from Azure AD and other data objects from more Microsoft cloud services.

Azure AD の同意フレームワークは、OAuth 2.0 と、public クライアントまたは confidential クライアントを使用した OAuth 2.0 のさまざまなフロー (Authorization Code Grant や Client Credentials Grant など) を基盤としています。The consent framework is built on OAuth 2.0 and its various flows, such as authorization code grant and client credentials grant, using public or confidential clients. Azure AD では OAuth 2.0 を採用することによって、スマートフォン、タブレット、サーバーなどにインストールされるアプリケーションから Web アプリケーションに至るまで、多種多様なクライアント アプリケーションの作成と、そのアプリケーションが必要なリソースにアクセスすることを可能にしています。By using OAuth 2.0, Azure AD makes it possible to build many different types of client applications, such as on a phone, tablet, server, or a web application, and gain access to the required resources.

OAuth 2.0 の認可付与を採用している同意フレームワークの使い方の詳細については、OAuth 2.0 と Azure AD を使用した Web アプリケーションへのアクセスの承認に関するページと、「Azure AD の認証シナリオ」を参照してください。For more information about using the consent framework with OAuth2.0 authorization grants, see Authorize access to web applications using OAuth 2.0 and Azure AD and Authentication Scenarios for Azure AD. Microsoft Graph を使って Office 365 に対するアクセスの承認を得る方法の詳細については、Microsoft Graph によるアプリ認証に関するページを参照してください。For information about getting authorized access to Office 365 via Microsoft Graph, see App authentication with Microsoft Graph.

以下の手順は、アプリケーションの開発者とユーザーにとっての同意エクスペリエンスがどのようなものになるかを示したものです。The following steps show you how the consent experience works for both the application developer and user.

  1. 何らかのリソース/API にアクセスするために一定のアクセス許可を要求する必要がある Web クライアント アプリケーションがあると仮定しましょう。Assume you have a web client application that needs to request specific permissions to access a resource/API. 構成方法については次のセクションで詳しく説明するとして、ここで重要なのは、構成時に Azure Portal を使用してアクセス許可の要求を宣言するという点です。You'll learn how to do this configuration in the next section, but essentially the Azure portal is used to declare permission requests at configuration time. この設定は他の構成設定と同じく、アプリケーションを Azure AD に登録する作業の一環として行います。Like other configuration settings, they become part of the application's Azure AD registration:

    他のアプリケーションに対するアクセス許可

  2. 現在、アプリケーションの更新が終わって、アプリケーションが実行中になり、これからユーザーが初めてアプリケーションを使用するところだとします。Consider that your application’s permissions have been updated, the application is running, and a user is about to use it for the first time. アプリケーションではまず、Azure AD の /authorize エンドポイントから認証コードを取得する必要があります。First the application needs to obtain an authorization code from Azure AD’s /authorize endpoint. 取得した認証コードは、後でアクセス トークンと更新トークンの取得に使用します。The authorization code can then be used to acquire a new access and refresh token.

  3. ユーザーの認証がまだであれば、Azure AD の /authorize エンドポイントによりサインイン画面が表示されます。If the user is not already authenticated, Azure AD's /authorize endpoint prompts for sign-in.

    ユーザーまたは管理者による Azure AD へのサインイン

  4. ユーザーのサインインが終わると、そのユーザーに対して同意ページを表示する必要があるかどうかが Azure AD により判定されます。After the user has signed in, Azure AD will determine if the user needs to be shown a consent page. 表示の要否の判定基準は、ユーザー (またはそのユーザーが所属する組織の管理者) がアプリケーションに既に同意を与えているかどうかです。This determination is based on whether the user (or their organization’s administrator) has already granted the application consent. 同意がまだであれば、Azure AD からユーザーに対して同意を求めるメッセージと、アプリケーションが機能するうえで必要なアクセス許可が表示されます。If consent has not already been granted, Azure AD prompts the user for consent and displays the required permissions it needs to function. 同意ダイアログに表示されるアクセス許可は、Azure Portal の [委任されたアクセス許可] で選択したものと同じになります。The set of permissions that are displayed in the consent dialog match the ones selected in the Delegated Permissions in the Azure portal.

    ユーザーの同意エクスペリエンス

  5. ユーザーが同意すると、アプリケーションに認証コードが返されます。アクセス トークンと更新トークンを取得するときには、この認証コードが必要になります。After the user grants consent, an authorization code is returned to your application, which is redeemed to acquire an access token and refresh token. このフローの詳細については、「Azure AD の認証シナリオ」の「Web アプリケーション対 Web API」を参照してください。For more information about this flow, see the web Application to web API section in Authentication Scenarios for Azure AD.

  6. 管理者であれば、テナント内のユーザー全員に代わってアプリケーションの委任されたアクセス許可に同意することもできます。As an administrator, you can also consent to an application's delegated permissions on behalf of all the users in your tenant. 管理者が同意すると、そのテナントのユーザーには同意ダイアログが表示されなくなります。この同意は、管理者ロールが与えられたユーザーが Azure portal で行うことができます。Administrative consent prevents the consent dialog from appearing for every user in the tenant, and can be done in the Azure portal by users with the administrator role. アプリケーションの [設定] ページで、[必要なアクセス許可][アクセス許可の付与] の順にクリックしてください。From the Settings page for your application, click Required Permissions and click on the Grant Permissions button.

    明示的な管理者の同意としてアクセス許可を付与する

    注意

    ADAL.js を使用するシングルページ アプリ (SPA) では現在、[アクセス許可の付与] ボタンを使用して明示的に同意する必要があります。Granting explicit consent using the Grant Permissions button is currently required for single page applications (SPA) that use ADAL.js. そうしないと、アクセス トークンが要求されたときにアプリケーションでエラーが発生します。Otherwise, the application fails when the access token is requested.

Web API にアクセスするためのクライアント アプリケーションの構成Configure a client application to access web APIs

Web/confidential クライアント アプリケーションが認証を必要とする認可付与フローに参加 (し、アクセス トークンを取得) するためには、セキュリティで保護された資格情報を確立する必要があります。In order for a web/confidential client application to be able to participate in an authorization grant flow that requires authentication (and obtain an access token), it must establish secure credentials. Azure portal でサポートされている既定の認証方法は、クライアント ID と秘密鍵の組み合わせです。The default authentication method supported by the Azure portal is client ID + secret key. このセクションでは、クライアントの資格情報に秘密鍵を追加するために必要な構成手順について説明します。This section covers the configuration steps required to provide the secret key with your client's credentials.

さらに、同意フレームワークでは、リソース アプリケーションによって公開されている Web API (Microsoft Graph API など) にクライアントがアクセスできるようになる前に、要求されたアクセス許可に基づいてクライアントに必要なアクセス許可が付与されていることを確認します。Additionally, before a client can access a web API exposed by a resource application (such as the Microsoft Graph API), the consent framework ensures the client obtains the permission grant required, based on the permissions requested. 既定では、どのアプリケーションも "Windows Azure Active Directory" (Graph API) および "Windows Azure Service Management API" のアクセス許可を選択できます。By default, all applications can choose permissions from "Windows Azure Active Directory" (Graph API) and "Windows Azure Service Management API." また、Graph API の [サインインとユーザー プロファイルの読み取り] アクセス許可が既定で選択されています。The Graph API “Sign-in and read user profile” permission is also selected by default. Office 365 のサブスクリプションを保有しているアカウントが存在するテナントにクライアントを登録しようとしている場合には、SharePoint と Exchange Online 用の Web API とアクセス許可を選択できます。If your client is being registered in a tenant that has accounts subscribed to Office 365, web APIs and permissions for SharePoint and Exchange Online are available for selection. 目的の Web API ごとに 2 種類のアクセス許可から選択できます。You can select from two types of permissions for each desired web API:

  • アプリケーションのアクセス許可: クライアント アプリケーションは、(ユーザー コンテキストなしで) アプリケーションとして Web API に直接アクセスする必要があります。Application Permissions: Your client application needs to access the web API directly as itself (no user context). この種類のアクセス許可には管理者の同意が必要であるほか、ネイティブ クライアント アプリケーションでは使用できません。This type of permission requires administrator consent and is also not available for native client applications.

  • 委任されたアクセス許可: クライアント アプリケーションは、サインインしているユーザーとして Web API にアクセスする必要があります。アクセスにあたっては、選択されているアクセス許可に応じて制限が適用されます。Delegated Permissions: Your client application needs to access the web API as the signed-in user, but with access limited by the selected permission. この種類のアクセス許可は、管理者の同意が必要でない限り、ユーザーが付与できます。This type of permission can be granted by a user unless the permission requires administrator consent.

    注意

    委任されたアクセス許可をアプリケーションに追加しても、テナント内のユーザーに対して自動的に同意が与えられるわけではありません。Adding a delegated permission to an application does not automatically grant consent to the users within the tenant. 追加したアクセス許可については、実行時にユーザーが手動で同意する必要があります。もっとも、管理者が Azure Portal のアプリケーション ページで [必要なアクセス許可] セクションの [アクセス許可の付与] をクリックした場合には、この限りではありません。Users must still manually consent for the added delegated permissions at runtime, unless the administrator clicks the Grant Permissions button from the Required Permissions section of the application page in the Azure portal.

Web API にアクセスするためのアプリケーションの資格情報またはアクセス許可を追加するにはTo add application credentials, or permissions to access web APIs

  1. Azure Portal にサインインします。Sign in to the Azure portal.
  2. ご利用のアカウントで複数の Azure AD テナントにアクセスできる場合は、右上隅でアカウントをクリックし、ポータルのセッションを目的のテナントに設定します。If your account gives you access to more than one, click your account in the top right corner, and set your portal session to the desired Azure AD tenant.
  3. 左側のナビゲーション ウィンドウで、[Azure Active Directory] サービスをクリックし、[アプリの登録] をクリックして、構成するアプリケーションを検索/クリックします。In the left-hand navigation pane, click the Azure Active Directory service, click App registrations, then find/click the application you want to configure.

    アプリケーションの登録の更新

  4. アプリケーションのメイン登録ページが表示され、そのアプリケーションの [設定] ページが開きます。You are taken to the application's main registration page, which opens up the Settings page for the application. Web アプリケーションの資格情報の秘密鍵を追加するには、次の操作を行います。To add a secret key for your web application's credentials:

    • [設定] ページの [キー] セクションをクリックします。Click the Keys section on the Settings page.
    • 鍵の説明を追加します。Add a description for your key.
    • 期間として 1 年または 2 年を選択します。Select either a one or two year duration.
    • [保存] をクリックします。Click Save. 構成の変更を保存すると、右端の列に鍵の値が格納されます。The right-most column will contain the key value, after you save the configuration changes. クライアント アプリケーションのコードで使用するので、必ず鍵をコピーしておいてください。このページを一度閉じると、鍵にアクセスできなくなります。Be sure to copy the key for use in your client application code, as it is not accessible once you leave this page.

    アプリケーションの登録の更新 - 鍵

  5. 次の手順に従い、クライアントからリソース API にアクセスするためのアクセス許可を追加します。To add permission(s) to access resource APIs from your client

    • [設定] ページの [必要なアクセス許可] セクションをクリックします。Click the Required Permissions section on the Settings page.
    • [追加] をクリックします。Click the Add button.
    • [API を選択します] をクリックし、選択するリソースの種類を選択します。Click Select an API to select the type of resources you want to pick from.
    • 利用可能な API の一覧を参照するか、検索ボックスを使用して、ディレクトリ内にあって Web API を公開している利用可能なリソース アプリケーションの中から選択します。Browse through the list of available APIs or use the search box to select from the available resource applications in your directory that expose a web API. 目的のリソースをクリックし、[選択] をクリックします。Click the resource you are interested in, then click Select.
    • [アクセスの有効化] ページが表示されます。You're taken to the Enable Access page. アプリケーションのアクセス許可や委任されたアクセス許可のうち、アプリケーションが API にアクセスするうえで必要なものを選択します。Select the Application Permissions and/or Delegated Permissions your application needs when accessing the API.

    アプリケーションの登録の更新 - アクセス許可 API

    アプリケーションの登録の更新 - アクセス許可

  6. 完了したら、[アクセスの有効化] ページで [選択] をクリックし、[API アクセスの追加] ページ で [完了] をクリックします。When finished, click the Select button on Enable Access page, then the Done button on the Add API access page. [必要なアクセス許可] ページに戻ります。ページでは API の一覧に新しいリソースが追加されています。You are returned to the Required permissions page, where the new resource is added to the list of APIs.

    注意

    [完了] をクリックすると、構成済みの他のアプリケーションに対するアクセス許可に基づいて、ディレクトリ内のアプリケーションのアクセス許可も自動的に設定されます。Clicking the Done button also automatically sets the permissions for your application in your directory based on the permissions to other applications that you configured. これらのアプリケーションのアクセス許可は、アプリケーションの [設定] ページで確認できます。You can view these application permissions by looking at the application Settings page.

Web API を公開するためのリソース アプリケーションの構成Configuring a resource application to expose web APIs

自ら Web API を開発し、クライアント アプリケーションで利用できるようにすることもできます。そのためには、アクセスのスコープロールを公開する必要があります。You can develop a web API and make it available to client applications by exposing access scopes and roles. Web API を適切に構成すれば、Graph API や Office 365 API など、他の Microsoft Web API と同じように利用できるようになります。A correctly configured web API is made available just like the other Microsoft web APIs, including the Graph API and the Office 365 APIs. アクセスのスコープとロールを公開するには、アプリケーション マニフェストを使用します。アプリケーション マニフェストは、アプリケーションの ID 構成を示した JSON ファイルです。Access scopes and roles are exposed through your application's manifest, which is a JSON file that represents your application’s identity configuration.

以下のセクションでは、リソース アプリケーションのマニフェストを変更してアクセス スコープを公開する方法について説明します。The following section shows you how to expose access scopes, by modifying the resource application's manifest.

リソース アプリケーションへのアクセス スコープの追加Adding access scopes to your resource application

  1. Azure Portal にサインインします。Sign in to the Azure portal.
  2. ご利用のアカウントで複数の Azure AD テナントにアクセスできる場合は、右上隅でアカウントをクリックし、ポータルのセッションを目的のテナントに設定します。If your account gives you access to more than one, click your account in the top right corner, and set your portal session to the desired Azure AD tenant.

  3. 左側のナビゲーション ウィンドウで、[Azure Active Directory] サービスをクリックし、[アプリの登録] をクリックして、構成するアプリケーションを検索/クリックします。In the left-hand navigation pane, click the Azure Active Directory service, click App registrations, then find/click the application you want to configure.

    アプリケーションの登録の更新

  4. アプリケーションのメイン登録ページが表示され、そのアプリケーションの [設定] ページが開きます。You are taken to the application's main registration page, which opens up the Settings page for the application. アプリケーションの登録ページで [マニフェスト] をクリックして、[マニフェストの編集] ページに切り替えます。Switch to the Edit manifest page, by clicking Manifest from the application's registration page. Web ベースのマニフェスト エディターが開き、ポータルでマニフェストを編集できます。A web-based manifest editor opens, allowing you to Edit the manifest within the portal. 必要があれば、[ダウンロード] をクリックしてローカルで編集します。編集を終えたら [アップロード] をクリックすると、アプリケーションに編集後のマニフェストが適用されます。Optionally, you can click Download and edit locally, then use Upload to reapply it to your application.

  5. この例では、oauth2Permissions コレクションに以下の JSON 要素を追加して、リソース/API で Employees.Read.All という新しいスコープを公開します。In this example, we will expose a new scope called Employees.Read.All on our resource/API, by adding the following JSON element to the oauth2Permissions collection. 既存の user_impersonation スコープは、登録時に既定で提供されます。The existing user_impersonation scope is provided by default during registration. user_impersonation は、クライアント アプリケーションがリソースに対するアクセス許可を要求するにあたり、サインインしたユーザーの ID を使えるようにするためのものです。user_impersonation allows a client application to request permission to access the resource, under the identity of the signed-in user. 既存の user_impersonation スコープ要素の後にコンマを追加したうえで、リソースのニーズに応じてプロパティの値を変更してください。Be sure to add the comma after the existing user_impersonation scope element, and change the property values to suit your resource's needs.

    {
     "adminConsentDescription": "Allow the application to have read-only access to all Employee data.",
     "adminConsentDisplayName": "Read-only access to Employee records",
     "id": "2b351394-d7a7-4a84-841e-08a6a17e4cb8",
     "isEnabled": true,
     "type": "User",
     "userConsentDescription": "Allow the application to have read-only access to your Employee data.",
     "userConsentDisplayName": "Read-only access to your Employee records",
     "value": "Employees.Read.All"
    }
    

    注意

    "id" の値は、guidgen などの GUID 生成ツールや、プログラムを使って作成する必要があります。The "id" value must be generated using a GUID generation tool such as guidgen or programmatically. この値は、Web API によって公開されるスコープの一意の識別子となります。It represents a unique identifier for the scope as exposed by the web API. クライアントに対して Web API にアクセスするためのアクセス許可が適切に構成されていると、そのクライアントには、Azure AD によって OAuth 2.0 アクセス トークンが発行されます。Once a client is appropriately configured with permissions to access your web API, it is issued an OAuth2.0 access token by Azure AD. クライアントが Web API を呼び出すときには、このアクセス トークンを提示することになります。そして、このアクセス トークンでは、スコープ (scp) 要求がアプリケーションの登録時に要求されたアクセス許可のとおりに設定されています。When the client calls the web API, it presents the access token that has the scope (scp) claim set to the permissions requested in its application registration.

    公開するスコープは、必要に応じて後から追加することもできます。You can expose additional scopes later as necessary. たとえば、Web API で、さまざまな機能が関連付けられたスコープをいくつも公開しているとします。Consider that your web API might expose multiple scopes associated with a variety of different functions. リソースでは、受け取った OAuth 2.0 アクセス トークンのスコープ (scp) 要求を評価することによって、実行時に Web API へのアクセスを制御します。Your resource can control access to the web API at runtime, by evaluating the scope (scp) claim(s) in the received OAuth 2.0 access token.

  6. 完了したら、[保存] をクリックします。When finished, click Save. これで Web API の構成が終わり、ディレクトリ内の他のアプリケーションが利用できるようになりました。Now your web API is configured for use by other applications in your directory.

    アプリケーションの登録の更新

テナント内の他のアプリケーションに Web API が公開されているかどうかの確認Verify the web API is exposed to other applications in your tenant

  1. Azure AD テナントに戻って、[アプリの登録] をもう一度クリックし、構成するクライアント アプリケーションを検索/クリックします。Go back to your Azure AD tenant, click App registrations again, then find/click the client application you want to configure.

    アプリケーションの登録の更新

  2. Web API にアクセスするためのクライアント アプリケーションの構成」の手順 5. をもう一度実行します。Repeat step 5 as you did in Configure a client application to access web APIs. [API を選択します] の手順まで進んだら、検索フィールドにアプリケーション名を入力してリソースを検索し、[選択] をクリックします。When you get to the Select an API step, search for your resource by entering its application name in the search field, and click Select.

  3. [アクセスの有効化] ページに新しいスコープが表示されていれば、クライアントのアクセス許可の要求で利用できる状態です。On the Enable Access page you should see the new scope, available for client permission requests.

    新しいアクセス許可の表示

アプリケーション マニフェストの詳細More on the application manifest

アプリケーション マニフェストは、実際にはアプリケーション エンティティを更新するためのメカニズムとしての役割を果たすものです。ここまでに取り上げた API のアクセス スコープをはじめ、Azure AD アプリケーションの ID 構成の属性はすべて、このアプリケーション エンティティで定義されています。The application manifest actually serves as a mechanism for updating the Application entity, which defines all attributes of an Azure AD application's identity configuration, including the API access scopes we discussed. アプリケーション エンティティとそのスキーマの詳細については、Graph API のアプリケーション エンティティに関するドキュメントを参照してください。For more information on the Application entity and its schema, see the Graph API Application entity documentation. このドキュメントでは、API のアクセス許可を指定するために使用するアプリケーション エンティティのメンバーについて、詳細な参照情報を確認できます。たとえば、次のような情報です。The article contains complete reference information on the Application entity members used to specify permissions for your API, including:

アプリケーション マニフェストの概念一般の詳細については、Azure Active Directory のアプリケーション マニフェストに関するページを参照してください。For more information on application manifest concepts in general, see Understanding the Azure Active Directory application manifest.

Microsoft Graph API による Azure AD Graph と Office 365 へのアクセスAccessing the Azure AD Graph and Office 365 via Microsoft Graph APIs

前に説明したように、独自のアプリケーションのための API を公開してそれにアクセスするだけでなく、クライアント アプリケーションを登録して、Microsoft のリソースにより公開されている API にアクセスすることもできます。As mentioned earlier, in addition to exposing/accessing APIs for your own applications, you can register your client application to access APIs exposed by Microsoft resources. Microsoft Graph API (ポータルのリソース/API 一覧では "Microsoft Graph") は、Azure AD に登録されているすべてのアプリケーションが利用できます。The Microsoft Graph API, referred to as “Microsoft Graph” in the portal's resource/API list, is available to all applications that are registered with Azure AD. Office 365 サブスクリプションにサインアップしたアカウントが存在するテナントにクライアント アプリケーションを登録した場合には、さまざまな Office 365 リソースにより公開されているスコープにもアクセスできます。If you are registering your client application in a tenant containing accounts that have signed up for an Office 365 subscription, you can also access the scopes exposed by the various Office 365 resources.

Microsoft Graph API により公開されているスコープの全容については、Microsoft Graph のアクセス許可に関するリファレンスを参照してください。For a complete discussion on scopes exposed by Microsoft Graph API, see the Microsoft Graph permissions reference article.

注意

現時点では、ネイティブ クライアント アプリケーションに [Access your organization's directory](組織のディレクトリにアクセスする) アクセス許可を使用した場合、そのアプリケーションで Azure AD Graph API しか呼び出すことができなくなるという制約があります。Due to a current limitation, native client applications can only call into the Azure AD Graph API if they use the “Access your organization's directory” permission. この制約は、Web アプリケーションには適用されません。This restriction does not apply for web applications.

マルチテナント アプリケーションの構成Configuring multi-tenant applications

Azure AD にアプリケーションを登録するときには、自分が所属する組織のユーザーだけがそのアプリケーションにアクセスできるようにすることもあれば、When registering an application in Azure AD, you may want your application to be accessed only by users in your organization. 反対に、外部組織のユーザーがアプリケーションにアクセスできるようにすることもあります。Alternatively, you may also want your application to be accessible by users in external organizations. 前者をシングルテナント アプリケーション、後者をマルチテナント アプリケーションと呼びます。These two application types are called single-tenant and multi-tenant applications. このセクションでは、シングルテナント アプリケーションの構成を変更してマルチテナント アプリケーションにする方法を説明します。This section discusses how to modify the configuration of a single-tenant application to make it a multi-tenant application.

シングルテナント アプリケーションとマルチテナント アプリケーションの違いに注意することが重要です。It’s important to note the differences between a single-tenant and multi-tenant application:

  • シングルテナント アプリケーションは、1 つの組織で使用することを想定しています。A single-tenant application is intended for use in one organization. 典型例としては、エンタープライズ開発者が作成した基幹業務 (LOB) アプリケーションが挙げられます。It's typically a line-of-business (LoB) application written by an enterprise developer. シングルテナント アプリケーションには、アプリケーションを登録したテナントと同じテナントに存在するアカウントのユーザーのみがアクセスできます。A single-tenant application can only be accessed by users with accounts in the same tenant as the application registration. このため、1 つのディレクトリにプロビジョニングするだけで済みます。As a result, it only needs to be provisioned in one directory.
  • マルチテナント アプリケーションは、多数の組織で使用することを想定しています。A multi-tenant application is intended for use in many organizations. サービスとしてのソフトウェア (SaaS) Web アプリケーションとも呼ばれ、独立系ソフトウェア ベンダー (ISV) が作成したアプリケーションがその典型例です。Referred to as a software-as-a-service (SaaS) web application, it's typically written by an independent software vendor (ISV). マルチテナント アプリケーションは、ユーザーがアクセスする必要があるテナントそれぞれにプロビジョニングする必要があります。Multi-tenant applications must be provisioned in each tenant where users need access. アプリケーションが登録されているテナント以外のテナントの場合、登録にはユーザーまたは管理者の同意が必要です。For tenants other than the one where the application is registered, user or administrator consent is required in order to register them. ネイティブ クライアント アプリケーションは、リソース所有者のデバイスにインストールされるので、既定でマルチテナントになります。Note that native client applications are multi-tenant by default as they are installed on the resource owner's device. 同意フレームワークの詳細については、前の「同意フレームワークの概要」セクションを参照してください。See the preceding Overview of the consent framework section for details on the consent framework.

アプリケーションをマルチテナントにするには、アプリケーション登録の変更と、Web アプリケーション自体に対する変更の両方が必要です。Making an application multi-tenant requires both application registration changes, as well as changes to the web application itself. 以下のセクションでは、そのどちらについても説明します。The following sections cover both.

マルチテナントのサポートのためのアプリケーション登録の変更Changing the application registration to support multi-tenant

組織の外部の顧客やパートナーが利用できるアプリケーションを作成する場合には、Azure Portal でアプリケーションの定義を更新する必要があります。If you are writing an application that you want to make available to your customers or partners outside of your organization, you need to update the application definition in the Azure portal.

重要

Azure AD では、マルチテナント アプリケーションのアプリ ID URI がグローバルで一意になっている必要があります。Azure AD requires the App ID URI of multi-tenant applications to be globally unique. アプリ ID URI は、プロトコル メッセージでアプリケーションを識別する手段の 1 つです。The App ID URI is one of the ways an application is identified in protocol messages. シングル テナント アプリケーションの場合、アプリ ID URI はそのテナント内で一意であれば十分です。For a single tenant application, it is sufficient for the App ID URI to be unique within that tenant. これに対してマルチテナント アプリケーションの場合、Azure AD が全テナントから該当するアプリケーションを特定できるように、アプリ ID URI がグローバルで一意になっている必要があります。For a multi-tenant application, it must be globally unique so Azure AD can find the application across all tenants. グローバルな一意性を確保するため、アプリ ID URI には Azure AD テナントの検証済みドメインと一致するホスト名が含まれていなければならないという条件が存在します。Global uniqueness is enforced by requiring the App ID URI to have a host name that matches a verified domain of the Azure AD tenant. たとえば、テナントの名前が contoso.onmicrosoft.com の場合、有効なアプリ ID URI は https://contoso.onmicrosoft.com/myapp のようになります。For example, if the name of your tenant is contoso.onmicrosoft.com then a valid App ID URI would be https://contoso.onmicrosoft.com/myapp. また、テナントの検証済みドメインが contoso.com の場合、有効なアプリ ID URI は https://contoso.com/myapp のようになります。If your tenant has a verified domain of contoso.com, then a valid App ID URI would also be https://contoso.com/myapp. アプリ ID URI がこのパターンに従っていないと、アプリケーションのマルチテナントとしての設定が失敗します。If the App ID URI doesn’t follow this pattern, setting an application as multi-tenant fails.

外部ユーザーがアプリケーションにアクセスできるようにするには、次の操作を行います。To give external users the ability to access your application:

  1. Azure Portal にサインインします。Sign in to the Azure portal.
  2. ご利用のアカウントで複数の Azure AD テナントにアクセスできる場合は、右上隅でアカウントをクリックし、ポータルのセッションを目的のテナントに設定します。If your account gives you access to more than one, click your account in the top right corner, and set your portal session to the desired Azure AD tenant.
  3. 左側のナビゲーション ウィンドウで、[Azure Active Directory] サービスをクリックし、[アプリの登録] をクリックして、構成するアプリケーションを検索/クリックします。In the left-hand navigation pane, click the Azure Active Directory service, click App registrations, then find/click the application you want to configure. アプリケーションのメイン登録ページが表示され、そのアプリケーションの [設定] ページが開きます。You are taken to the application's main registration page, which opens up the Settings page for the application.
  4. [設定] ページで [プロパティ] をクリックし、[マルチテナント] スイッチを [はい] に変更します。From the Settings page, click Properties and change the Multi-tenanted switch to Yes.

ここに挙げた変更が終わると、他の組織のユーザーと管理者からその組織のユーザーに対して、アプリケーションへのサインインを許可できるようになります。その結果、アプリケーションがそのユーザーのテナントで保護されているリソースにアクセスできるようになります。After you have made the changes, users and administrators in other organizations are able to grant their users the ability to sign in to your application, allowing your application to access resources secured by their tenant.

マルチテナントのサポートのためのアプリケーションの変更Changing the application to support multi-tenant

マルチテナント アプリケーションのサポートは、Azure AD の同意フレームワークに大きく依存しています。Support for multi-tenant applications relies heavily on the Azure AD consent framework. 同意とは、他のテナントのユーザーからアプリケーションに対して、そのユーザーのテナントで保護されているリソースへのアクセスを許可できるようにするメカニズムです。Consent is the mechanism that allows a user from another tenant to grant the application access to resources secured by the user's tenant. このエクスペリエンスを "ユーザーの同意" と呼びます。This experience is referred to as "user consent."

Web アプリケーションではほかにも、次のものが提供されることがあります。Your web application may also offer:

  • 管理者による "会社のサインアップ"。The ability for administrators to "sign up my company." このエクスペリエンスは "管理者の同意" とも呼ばれ、管理者が組織内の "すべてのユーザー" に代わって同意を与えることができるようにするものです。This experience, referred to as "admin consent", gives an administrator the capability to grant consent on behalf all users in their organization. 管理者の同意を与えることができるのは、グローバル管理者ロールに属するアカウントで認証したユーザーのみです。それ以外のユーザーが同意しようとしても、エラーが発生します。Only a user that authenticates with an account that belongs to the Global Admin role can provide admin consent; others receive an error.

  • ユーザーのサインアップ エクスペリエンス。A sign-up experience for users. ユーザーの画面に [サインアップ] ボタンが表示されます。このボタンを押すと、ブラウザーが Azure AD OAuth2.0 の /authorize エンドポイントまたは OpenID Connect の /userinfo エンドポイントにリダイレクトされます。It is expected that the user is provided a "sign-up" button that will redirect the browser to the Azure AD OAuth2.0 /authorize endpoint or an OpenID Connect /userinfo endpoint. これらのエンドポイントでは、アプリケーションが id_token を調べて、新しいユーザーに関する情報を取得できます。These endpoints allow the application to get information about the new user by inspecting the id_token. サインアップ フェーズの後は、「同意フレームワークの概要」セクションで示したものとよく似た同意プロンプトがユーザーに表示されます。Following the sign-up phase the user is presented with a consent prompt, similar to the one shown in the Overview of the consent framework section.

マルチテナント アクセスとサインイン/サインアップ エクスペリエンスのサポートに必要なアプリケーションの変更の詳細については、次を参照してください。For more information on the application changes required to support multi-tenanted access and sign-in/sign-up experiences, see:

シングル ページ アプリケーションでの OAuth 2.0 Implicit Grant の有効化Enabling OAuth 2.0 implicit grant for Single Page Applications

シングル ページ アプリケーション (SPA) の場合、ブラウザーで実行される JavaScript ヘビーなフロント エンドを備え、このフロントエンドからアプリケーションの Web API バックエンドを呼び出してビジネス ロジックを実行するというのが典型的な構造です。Single Page Application’s (SPAs) are typically structured with a JavaScript-heavy front end that runs in the browser, which calls the application’s web API back-end to perform its business logic. Azure AD でホストされている SPA では、Azure AD によるユーザー認証と、アプリケーションの JavaScript クライアントによるバックエンド Web API の呼び出しを保護するためのトークンの取得に、OAuth 2.0 Implicit Grant を使用します。For SPAs hosted in Azure AD, you use OAuth 2.0 Implicit Grant to authenticate the user with Azure AD and obtain a token that you can use to secure calls from the application's JavaScript client to its back-end web API.

この認証プロトコルはほかにも、ユーザーが同意した後、クライアントとアプリケーション用に構成されている他の Web API リソースとの間に発生する呼び出しを保護するトークンを取得するときにも利用できます。After the user has granted consent, this same authentication protocol can be used to obtain tokens to secure calls between the client and other web API resources configured for the application. 暗黙的な認可付与の詳細と、それが自身のアプリケーションのシナリオに適しているかどうかの判断に役立つ情報は、「Azure Active Directory (AD) での OAuth2 の暗黙的な許可フローについて」を参照してください。To learn more about the implicit authorization grant, and help you decide whether it's right for your application scenario, see Understanding the OAuth2 implicit grant flow in Azure Active Directory.

既定では、アプリケーションに対して OAuth 2.0 Implicit Grant が無効になっています。By default, OAuth 2.0 implicit Grant is disabled for applications. アプリケーションに対して OAuth 2.0 Implicit Grant を有効にするには、アプリケーション マニフェストoauth2AllowImplicitFlow の値を設定します。You can enable OAuth 2.0 Implicit Grant for your application by setting the oauth2AllowImplicitFlow value in its application manifest.

OAuth 2.0 Implicit Grant を有効にするにはTo enable OAuth 2.0 implicit grant

注意

アプリケーション マニフェストを編集する方法の詳細については、前の「Web API を公開するためのリソース アプリケーションの構成」セクションを参照してください。For details on how to edit the application manifest, be sure to first review the preceding section, Configuring a resource application to expose web APIs.

  1. Azure Portal にサインインします。Sign in to the Azure portal.
  2. ご利用のアカウントで複数の Azure AD テナントにアクセスできる場合は、右上隅でアカウントをクリックし、ポータルのセッションを目的のテナントに設定します。If your account gives you access to more than one, click your account in the top right corner, and set your portal session to the desired Azure AD tenant.
  3. 左側のナビゲーション ウィンドウで、[Azure Active Directory] サービスをクリックし、[アプリの登録] をクリックして、構成するアプリケーションを検索/クリックします。In the left-hand navigation pane, click the Azure Active Directory service, click App registrations, then find/click the application you want to configure. アプリケーションのメイン登録ページが表示され、そのアプリケーションの [設定] ページが開きます。You are taken to the application's main registration page, which opens up the Settings page for the application.
  4. アプリケーションの登録ページで [マニフェスト] をクリックして、[マニフェストの編集] ページに切り替えます。Switch to the Edit manifest page, by clicking Manifest from the application's registration page. Web ベースのマニフェスト エディターが開き、ポータルでマニフェストを編集できます。A web-based manifest editor opens, allowing you to Edit the manifest within the portal. "oauth2AllowImplicitFlow" を探し、値を "true" に設定します。Locate and set the "oauth2AllowImplicitFlow" value to "true." 既定値は "false" です。By default, it is set to "false."

    "oauth2AllowImplicitFlow": true,
    
  5. 更新したマニフェストを保存します。Save the updated manifest. 保存が完了すると、ユーザー認証に OAuth 2.0 Implicit Grant を使用するように Web API が構成されます。Once saved, your web API is now configured to use OAuth 2.0 Implicit Grant to authenticate users.

アプリケーションの削除Removing an application

このセクションでは、Azure AD テナントからアプリケーションの登録を削除する方法について説明します。This section describes how to remove an application's registration from your Azure AD tenant.

組織が作成したアプリケーションの削除Removing an application authored by your organization

テナントの [アプリの登録] メイン ページで [マイ アプリ] フィルターを適用すると、組織が登録したアプリケーションが表示されます。Applications that your organization has registered appear under the "My apps" filter on your tenant's main "App registrations" page. 表示されるアプリケーションは、Azure Portal から手動で登録したか、PowerShell または Graph API を使ってプログラムにより登録したものです。These applications are ones you registered manually via the Azure portal, or programmatically via PowerShell or the Graph API. さらに具体的には、テナント内でアプリケーション オブジェクトとサービス プリンシパル オブジェクトの両方によって表されるアプリケーションです。More specifically, they are represented by both an Application and Service Principal object in your tenant. 詳細については、アプリケーション オブジェクトおよびサービス プリンシパル オブジェクトに関するページを参照してください。For more information, see Application Objects and Service Principal Objects.

ディレクトリからシングルテナント アプリケーションを削除するにはTo remove a single-tenant application from your directory

  1. Azure Portal にサインインします。Sign in to the Azure portal.
  2. ご利用のアカウントで複数の Azure AD テナントにアクセスできる場合は、右上隅でアカウントをクリックし、ポータルのセッションを目的のテナントに設定します。If your account gives you access to more than one, click your account in the top right corner, and set your portal session to the desired Azure AD tenant.
  3. 左側のナビゲーション ウィンドウで、[Azure Active Directory] サービスをクリックし、[アプリの登録] をクリックして、構成するアプリケーションを検索/クリックします。In the left-hand navigation pane, click the Azure Active Directory service, click App registrations, then find/click the application you want to configure. アプリケーションのメイン登録ページが表示され、そのアプリケーションの [設定] ページが開きます。You are taken to the application's main registration page, which opens up the Settings page for the application.
  4. アプリケーションのメイン登録ページで [削除] をクリックします。From the application's main registration page, click Delete.
  5. 確認メッセージが表示されたら、 [はい] をクリックします。Click Yes in the confirmation message.

ホーム ディレクトリからマルチテナント アプリケーションを削除するにはTo remove a multi-tenant application from its home directory

  1. Azure Portal にサインインします。Sign in to the Azure portal.
  2. ご利用のアカウントで複数の Azure AD テナントにアクセスできる場合は、右上隅でアカウントをクリックし、ポータルのセッションを目的のテナントに設定します。If your account gives you access to more than one, click your account in the top right corner, and set your portal session to the desired Azure AD tenant.
  3. 左側のナビゲーション ウィンドウで、[Azure Active Directory] サービスをクリックし、[アプリの登録] をクリックして、構成するアプリケーションを検索/クリックします。In the left-hand navigation pane, click the Azure Active Directory service, click App registrations, then find/click the application you want to configure. アプリケーションのメイン登録ページが表示され、そのアプリケーションの [設定] ページが開きます。You are taken to the application's main registration page, which opens up the Settings page for the application.
  4. [設定] ページで [プロパティ] を選択し、[マルチテナント][いいえ] に切り替えてアプリケーションをシングルテナントに変更してから、[保存] をクリックします。From the Settings page, choose Properties and change the Multi-tenanted switch to No, to first change your application to single-tenant, then click Save. アプリケーションのサービス プリンシパル オブジェクトは、そのアプリケーションに既に同意を与えている組織すべてのテナントで保持されます。The application's service principal objects remain in the tenants of all organizations that have already consented to it.
  5. アプリケーションのメイン登録ページで [削除] をクリックします。Click on the Delete button from the application's main registration page.
  6. 確認メッセージが表示されたら、 [はい] をクリックします。Click Yes in the confirmation message.

別の組織によって承認されているマルチテナント アプリケーションの削除Removing a multi-tenant application authorized by another organization

テナントの [アプリの登録] メイン ページで [すべてのアプリ] フィルターを適用すると表示されるアプリケーションのうち、[マイ アプリ] に登録されているものを除いたものが、マルチテナント アプリケーションです。A subset of the applications that appear under the "All apps" filter (excluding the "My apps" registrations) on your tenant's main "App registrations" page, are multi-tenant applications. 技術的な話をすると、ここに挙げたマルチテナント アプリケーションは、別のテナントに存在し、同意プロセスの最中に組織のテナントに登録されたものです。In technical terms, these multi-tenant applications are from another tenant, and were registered into your tenant during the consent process. さらに具体的には、組織のテナントの中に対応するアプリケーション オブジェクトが存在せず、サービス プリンシパル オブジェクトのみによって表されるアプリケーションです。More specifically, they are represented by only a service principal object in your tenant, with no corresponding application object. アプリケーション オブジェクトとサービス プリンシパル オブジェクトの違いの詳細については、Azure AD のアプリケーション オブジェクトとサービス プリンシパル オブジェクトに関するページを参照してください。For more information on the differences between application and service principal objects, see Application and service principal objects in Azure AD.

(同意を与えた後に) ディレクトリに対するマルチテナント アプリケーションのアクセス権を削除するには、会社の管理者がアプリケーションのサービス プリンシパルを削除する必要があります。In order to remove a multi-tenant application’s access to your directory (after having granted consent), the company administrator must remove its service principal. 削除にあたっては、管理者にグローバル管理者のアクセス権が必要になります。Azure portal で削除するか、Azure AD PowerShell コマンドレットを使用して削除できます。The administrator must have global admin access and can remove it through the Azure portal or use the Azure AD PowerShell Cmdlets.

次の手順Next steps