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 ポータルにサインインします。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. たとえば、http://localhost:31544 は、ローカル マシンで実行されている Web アプリの URL である可能性があります。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.)

    注意

    既定では、新しく登録されたアプリケーションは、同じテナントのユーザーのみがアプリケーションにサインインできるように構成されます。By default, the newly registered 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, including multi-tier 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 のサービスへのアクセスに使用)、その他の 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 Cloud Services のその他のデータ オブジェクトにアクセスできます。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.

同意フレームワークは、OAuth 2.0 と、パブリック クライアントまたは秘密のクライアントを使用した各種フロー (認証コードの付与やクライアント資格情報の付与など) を基盤としています。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 andAuthentication 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 is done your application page in the Azure portal. アプリケーションの [設定] ページで、[必要なアクセス許可][アクセス許可の付与] ボタンの順にクリックします。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 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 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 Online および 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.

    注意

    委任されたアクセス許可をアプリケーションに追加しても、テナント内のユーザーに同意が自動的に付与されるわけではありません。この点が Azure クラシック ポータルと異なります。Adding a delegated permission to an application does not automatically grant consent to the users within the tenant, as it did in the Azure classic portal. 委任されたアクセス許可が追加されたら、ユーザーは引き続き実行時に手動で同意する必要があります。ただし、管理者が 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 ポータルにサインインします。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.
    • [Save] をクリックします。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.
    • [Add] (追加) ボタンをクリックします。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 ポータルにサインインします。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. この例では、次の JSON 要素を oauth2Permissions コレクションに追加して、Employees.Read.All と呼ばれる新しいスコープをリソース/API で公開します。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 アクセス トークンが発行されます。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 API の概念に関する記事をご覧ください。For a complete discussion on scopes exposed by Microsoft Graph API, see the Permission scopes | Microsoft Graph API concepts article.

注意

現在の制限により、ネイティブ クライアント アプリケーションは、"組織のディレクトリにアクセスする" アクセス許可を使用する場合に、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 ポータルにサインインします。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 での 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. アプリケーション マニフェストoauth2AllowImplicitFlow の値を設定することにより、アプリケーションに対して OAuth 2.0 Implicit Grant を有効化できます。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 ポータルにサインインします。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 show 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 ポータルにサインインします。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 ポータルにサインインします。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 show 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 through the Azure portal the Azure AD PowerShell Cmdlets to remove access.

次のステップNext steps