Azure Active Directory でセキュリティ保護された API への接続Connect to API secured with Azure Active Directory

SharePoint Framework ソリューションを構築する場合は、カスタム API に接続してデータを取得するか、または基幹業務アプリケーションと通信する必要があります。When building SharePoint Framework solutions, you might need to connect to your custom API to retrieve some data or to communicate with line of business applications. カスタム API を Microsoft Azure Active Directory (Azure AD) でセキュリティ保護することにより、多くのメリットを受けることができ、また、そのセキュリティ保護はさまざまな方法で行うことができます。Securing custom APIs with Microsoft Azure Active Directory (Azure AD) offers you many benefits and can be done in a number of ways. API を構築した後にこれにアクセスするには、いくつかの方法があります。After you have built the API, there are several ways in which you can access it. これらの方法の複雑さはそれぞれ異なっており、いずれも特定の考慮事項があります。These ways vary in complexity and each have their specific considerations.

この記事ではさまざまな方法について考察し、Azure AD でセキュリティ保護された API を保護し接続するための段階的なプロセスについて説明します。This article discusses the different approaches and describes the step-by-step process of building and connecting to an API secured with Azure AD.

重要

Azure AD でセキュリティ保護された API への接続するとき、現在一般に利用可能な MSGraphClient および AadHttpClient のクラスを使用することを推奨します。When connecting to Azure AD-secured APIs, we recommend that you use the MSGraphClient and AadHttpClient classes, which are now generally available. 推奨されるモデルの詳細については、 SharePoint Framework ソリューションでの Azure AD で保護された API への接続MSGraphClient を使って Microsoft Graph に接続するを参照してください。For more information about the recommended models, see Connect to Azure AD-secured APIs in SharePoint Framework solutions and Use the MSGraphClient to connect to Microsoft Graph.

Azure AD による API のセキュリティ保護Secure an API with Azure AD

Office 365 を使用している場合、Azure AD を使用してカスタム API をセキュリティ保護することは、是非検討していただきたいアーキテクチャ オプションです。If you're using Office 365, securing custom APIs using Azure AD is an architectural option that you should definitely consider. 何よりもまず、Office 365 と Azure AD によって既に管理されている、組織の既存の資格情報を使用して、API へのアクセスを保護することができます。First and foremost, it allows you to secure the access to the API using existing organizational credentials that are already managed through Office 365 and Azure AD. アクティブなアカウントを持つユーザーは、Azure AD によりセキュリティ保護された API を利用するアプリケーションとシームレスに作業できます。Users with an active account can seamlessly work with applications that leverage APIs secured with Azure AD. Azure AD 管理者は、Azure AD に登録されているその他のすべてのアプリケーションへのアクセスを管理するのと同じ方法で、API へのアクセスを一元管理できます。Azure AD administrators can centrally manage access to the API, the same way they manage access to all other applications registered with Azure AD.

API 開発者としては、Azure AD を使用して API を保護することにより、ユーザー資格情報の独自セットの管理と、API 用のカスタム セキュリティ レイヤーの実装から解放されます。As the API developer, using Azure AD to secure your API frees you from managing a proprietary set of user credentials and implementing a custom security layer for your API. さらに、Azure AD では、モバイル アプリからクライアント側ソリューションまでのさまざまな種類のアプリケーションから API に接続することができる OAuth プロトコルをサポートしています。Additionally, Azure AD supports the OAuth protocol, which allows you to connect to the API from a range of application types varying from mobile apps to client-side solutions.

カスタム API を構築するときに、Azure AD で API を保護する方法は、大きく分けて 2 つあります。When building custom APIs, there are two main ways in which you can secure your API with Azure AD. Microsoft Azure App Service で API をホストしている場合、App Service の認証オプションを利用できるメリットがあります。If you host the API in Microsoft Azure App Service, you can benefit from the App Service Authentication option. 独自のインフラストラクチャや Docker コンテナーで API をホストするなど、ホストの柔軟性をさらに求める場合は、コードで API をセキュリティ保護する必要があります。If you look for more hosting flexibility for your API, such as hosting it on your own infrastructure or in Docker containers, you need to secure it in code. そのような場合、実装は使用するプログラミング言語とフレームワークによって異なります。In such cases, the implementation depends on your programming language and framework.

この記事では、このオプションを説明するときに C# と、フレームワークとして ASP.NET Web API を使用します。In this article, when discussing this option, you will use C# and the ASP.NET Web API as the framework.

Azure App Service 認証を使用した API のセキュリティ保護Secure the API using Azure App Service Authentication

カスタム API を Azure App Service に配置する場合は、App Service 認証オプションのメリットを使用して、Azure AD で API を保護することができます。When deploying custom APIs to Azure App Service, you can benefit from the App Service Authentication option to secure the API with Azure AD. アプリケーション サービスの認証を使用する最大のメリットは、その単純さです。Azure ポータルで使用可能な構成の手順を実行することで、ウィザードにより認証の構成を設定することができます。The biggest benefit of using App Service Authentication is its simplicity: by following the configuration steps available in the Azure Portal, you can have the wizard set up the authentication configuration for you. 基本的なセットアップを選択する場合は、現在のサブスクリプションと関連付けられた Azure AD に、ウィザードで新規 Azure AD アプリケーションを作成します。If you choose the basic setup, the wizard creates a new Azure AD application in Azure AD associated with the current subscription. 高度な構成では、API をホストする App Service へのアクセスに、どの Azure AD アプリケーションを使用するかを選択できます。In the advanced configuration, you can choose which Azure AD application should be used to secure the access to the App Service hosting the API.

Azure ポータルに表示されるアプリケーション サービスの認証の設定

App Service 認証を設定した後、API にアクセスしようとするユーザーは、API をセキュリティ保護するために使用する Azure AD アプリケーションと同じ Azure AD に所属する組織のアカウントでサインインするように求められます。After App Service Authentication has been configured, users trying to access your API are prompted to sign in with their organizational account that belongs to the same Azure AD as the Azure AD application used to secure the API. サインインすると、HttpContext.Current.User プロパティを使用して現在のユーザーに関する情報にアクセスできます。After signing in, you are able to access the information about the current user through the HttpContext.Current.User property. Azure App Service 認証を使用する場合、アプリケーションに必要な追加の構成はありません。When using Azure App Service Authentication, there is no additional configuration required in your application.

Azure App Service 認証は、Azure App Service でのみ使用可能な機能です。Azure App Service Authentication is a feature available only in Azure App Service. この機能は API での認証の実装を大幅に簡素化する一方で、Azure App Service 内部で認証が実行されることになります。While this capability significantly simplifies implementing authentication in your API, it ties it to running inside Azure App Service. 別のクラウド プロバイダーを使用して、または Docker コンテナー内部で API をホストする場合は、まず認証レイヤーを実装する必要があります。If you want to host the API with another cloud provider or inside a Docker container, you need to implement the authentication layer first.

ASP.NET 認証を使用した API のセキュリティ保護Secure the API using ASP.NET authentication

API がホストされる場所やその展開方法に関して最大の柔軟性を求める場合は、ASP.NET の Azure AD 認証サポートの実装を検討する必要があります。If you want to have the maximum flexibility with regards to where your API is hosted and how it is deployed, you should consider implementing the support for Azure AD authentication in ASP.NET. Visual Studio により、この実装プロセスは大幅に簡素化されます。また、認証セットアップ ウィザードを完了した後は、API がユーザーに、組織のアカウントを使用してサインインするよう要求します。Visual Studio simplifies the implementation process significantly, and after completing the authentication setup wizard, your API requires users to sign in by using their organizational account.

Visual Studio の認証セットアップ ウィザード

構成プロセスの間に、Visual Studio は必要なすべての参照と設定を ASP.NET Web API プロジェクトに追加します。これには、API をセキュリティ保護するための新しい Azure AD アプリケーションの登録も含まれています。During the configuration process, Visual Studio adds all the necessary references and settings to your ASP.NET Web API project, including registering a new Azure AD application to secure your API.

Azure AD でセキュリティ保護された API への SharePoint Framework ソリューションからのアクセスAccess an API secured with Azure AD from SharePoint Framework solutions

SharePoint Framework ソリューションは完全にクライアント側のソリューションなので、セキュリティ保護された API への接続に必要な機密情報を安全に格納することができません。SharePoint Framework solutions are fully client-side and as such are incapable of securely storing secrets required to connect to secured APIs. クライアント側ソリューションとの安全な通信を行うために、Azure AD は認証 Cookie や OAuth の暗黙的フローなど、多くのメカニズムをサポートしています。To support secure communication with client-side solutions, Azure AD supports a number of mechanisms such as authentication cookies or the OAuth implicit flow.

通常、 SharePoint Framework ソリューションを構築する場合 、MSGraphClient を使用して Microsoft Graph に接続し、 AadHttpClient を使用して Azure AD でセキュリティ保護されたエンタープライズ API に接続します。Typically, when building SharePoint Framework solutions, you would use the MSGraphClient to connect to the Microsoft Graph and the AadHttpClient to connect to an enterprise API secured with Azure AD. しかし、AngularJS や jQuery などの Web 要求を実行するための独自のサービスを持つ JavaScript フレームワークを使用している場合や、ソリューションが SharePoint Framework の古いバージョンの上に構築されている場合は、Azure AD で保護されたAPI へのアクセス トークンを取得するために、他の方法をとることが必要となる場合があります。If you however work with a JavaScript framework that has its own service for executing web requests, such as AngularJS or jQuery or your solution is built on an older version of the SharePoint Framework, you might need to use other approaches to obtain an access token to APIs secured with Azure AD.

Azure AD 認証フローAzure AD authorization flows

Office 365 は、Azure Active Directory (Azure AD) を使用して、Microsoft Graph からアクセスされる API をセキュリティで保護します。Office 365 uses Azure Active Directory (Azure AD) to secure its APIs, which are accessed through Microsoft Graph. Azure AD は、認証プロトコルとして OAuth を使用します。Azure AD uses OAuth as the authorization protocol. アプリケーションは OAuth 認証フローを完了すると、一時的なアクセス トークンを取得します。When an application completes the OAuth authorization flow, it gets a temporary access token. トークンは、ユーザーがアプリケーションに付与したアクセス許可を使用して、そのユーザーに代わって特定のリソースへのアクセスを提供します。The token provides access to specific resources on behalf of the user by using permissions granted to the application by that user.

OAuth フローには、アプリケーションの種類に応じてさまざまな種類があります。Web アプリケーションは、アプリケーションをホストする URL に Azure AD がリダイレクトする OAuth フローを使用します。リダイレクトは、そのアプリケーションの信頼性を確認する追加のセキュリティ対策です。There are different types of OAuth flows depending on the kind of application. Web applications use an OAuth flow where Azure AD redirects to the URL where the application is hosted. The redirect is an additional security measure to verify the authenticity of that application.

Android と iOS のアプリなどのクライアント アプリケーションには URL がなく、リダイレクトを使用することはできません。このため、これらのアプリケーションは、リダイレクトなしで OAuth フローを完了します。Web アプリケーションとクライアント アプリケーションの両方とも、一般に公開されているクライアント ID と Azure AD とアプリケーションにのみに公開されているプライベートで保持されているクライアント シークレットを使用します。Client applications, such as Android and iOS apps, do not have a URL and cannot use a redirect. So they complete the OAuth flow without the redirect. Both web applications and client applications use a publicly known client ID and a privately held client secret known only to Azure AD and the application.

クライアント側の Web アプリケーションは Web アプリケーションに似ていますが、JavaScript を使用して実装され、ブラウザーのコンテキストで実行されます。Client-side web applications are similar to web applications but are implemented using JavaScript and run in the context of a browser. これらのアプリケーションは、ユーザーにクライアント シークレットを公開しない場合、クライアント シークレットを使用することはできません。These applications are incapable of using a client secret without revealing it to users. したがって、これらのアプリケーションは、** OAuth暗黙的フロー**と呼ばれる認証フローを使用して、Azure AD でセキュリティ保護されたリソースにアクセスします。Therefore these applications use an authorization flow called OAuth implicit flow to access resources secured with Azure AD. このフローでは、一般に公開されているクライアント ID とアプリケーションがホストされている URL に基づいて、アプリケーションと Azure AD 間の契約が確立されます。In this flow, the contract between the application and Azure AD is established based on the publicly-known client ID and the URL where the application is hosted. これは、Azure AD によってセキュリティで保護されたリソースに接続するために SharePoint Framework のクライアント側 Web パーツが使用するフローです。This is the flow that SharePoint Framework client-side web parts must use in order to connect to resources secured with Azure AD.

アクセス トークンを取得するために、AadTokenProvider を使用するUse the AadTokenProvider to retrieve access token

Web 要求を実行するための独自のサービスを持つ JavaScript ライブラリを使用する場合、Azure AD でセキュリティ保護された API へのアクセス トークンを取得する推奨される方法は、SharePoint Framework v1.6.0 から利用可能な AadTokenProvider を使用することです。When working with JavaScript libraries that have their own services for executing web requests, the recommended way to obtain an access token to an API secured with Azure AD is by using the AadTokenProvider available from SharePoint Framework v1.6.0. ほかのソリューションと比較して、AadTokenProvider は、SharePoint Framework ソリューションで OAuth 暗黙フローを実装するすべての複雑な作業を常に行うため、アプリケーションの構築に専念できます。Comparing to other solution, the AadTokenProvider takes always all intricacies of implementing OAuth implicit flow in SharePoint Framework solutions allowing you to focus on building your application.

注意

SharePoint Framework ソリューションを定期的に最新バージョンの SharePoint Framework に更新して、Microsoft により追加される改善事項と新機能のメリットを得ることを推奨します。It's recommended to regularly update your SharePoint Framework solutions to the most recent version of the SharePoint Framework to benefit of the improvements and new capabilities added by Microsoft.

Azure AD のセキュリティで保護された API へのアクセス許可を要求します。Request permissions to API secured with Azure AD

SharePoint Framework ソリューションが、Microsoft Graph やエンタープライズ アプリケーションなど、Azure AD でセキュリティ保護された特定のリソースへのアクセス許可を必要とする場合、これらのリソースと、必要なアクセス許可をソリューションの構成で指定できます。If your SharePoint Framework solution requires permissions to specific resources secured with Azure AD, such as Microsoft Graph or enterprise applications, you can specify these resources along with the necessary permissions in the configuration of your solution.

  1. SharePoint Framework プロジェクトで、config/package-solution.jsonファイルを開きます。In your SharePoint Framework project, open the config/package-solution.json file.

  2. solutionプロパティに、ソリューションに必要なすべてのリソースと対応するアクセス許可を一覧表示するwebApiPermissionRequestsプロパティを追加します。To the solution property, add the webApiPermissionRequests property that lists all the resources and corresponding permissions that your solution needs.

    次は、エンタープライズの API へのアクセスを要求している SharePoint フレームワーク ソリューションの例です。Following is an example of a SharePoint Framework solution requesting access to read user calendars using the Microsoft Graph:

    {
     "$schema": "https://dev.office.com/json-schemas/spfx-build/package-solution.schema.json",
     "solution": {
       "name": "spfx-client-side-solution",
       "id": "5d16587c-5e87-44d7-b658-1148988f212a",
       "version": "1.0.0.0",
       "includeClientSideAssets": true,
       "skipFeatureDeployment": true,
       "webApiPermissionRequests": [
         {
           "resource": "Enterprise-API-Name",
           "scope": "user_impersonation"
         }
       ]
     },
     "paths": {
       "zippedPackage": "solution/spfx-api.sppkg"
     }
    }
    

    注意

    resource プロパティの値として、アクセス許可を要求したいアプリケーションの displayNameobjectId を指定できます。For the value of the resource property, you can specify either the displayName or the objectId of the application to which you want to request permissions. displayName を使用すると、読みやすくなるだけでなく、ソリューションを一度だけ構築して複数のテナントで再利用することができます。Using the displayName not only is more readable but also allows you to build your solution once and reuse it across multiple tenants. Azure AD アプリケーションの objectId はテナントごとに異なりますが、displayName は同じです。While the objectId of an Azure AD application is different on each tenant, the displayName stays the same.

  3. このソリューションが SharePoint アプリ カタログに展開されている場合、管理者は要求されたアクセス許可を確認し、それを付与または拒否するよう求められます。When this solution is deployed to the SharePoint app catalog, it prompts the administrator to verify the requested permissions and either grant or deny them. アクセス許可要求を管理するさまざまな方法の詳細については、 アクセス許可の要求の管理 の記事を読んでください。Read Manage permission requests article to learn more about different ways of managing permission requests.

アクセストークンを取得するAcquire an access token

以下は、Azure AD でセキュリティで保護されたエンタープライズ API のアクセス トークンを取得し、jQuery を使用して web 要求を実行するために AadTokenProvider を使用する方法です。Following is how you would use the AadTokenProvider to retrieve an access token for an enterprise API secured with Azure AD and use it to perform a web request using jQuery:

// ...
import * as $ from 'jquery';
import { AadTokenProvider } from '@microsoft/sp-http';

export default class OrdersWebPart extends BaseClientSideWebPart<IOrdersWebPartProps> {
  // ...

  public render(): void {
    this.context.statusRenderer.displayLoadingIndicator(this.domElement, 'orders');

    this.context.aadTokenProviderFactory
      .getTokenProvider()
      .then((tokenProvider: AadTokenProvider): Promise<string> => {
        // retrieve access token for the enterprise API secured with Azure AD
        return tokenProvider.getToken('09c4b84d-13c4-4451-9350-3baedf70aab4');
      })
      .then((accessToken: string): void => {
        // call the enterprise API using jQuery passing the access token
        $.get({
          url: 'https://contoso.azurewebsites.net/api/Orders',
          headers: {
            authorization: `Bearer ${accessToken}`,
            accept: 'application/json'
          }
        })
        .done((orders: any): void => {
          this.context.statusRenderer.clearLoadingIndicator(this.domElement);
            this.domElement.innerHTML = `
            <div class="${ styles.orders}">
              <div class="${ styles.container}">
                <div class="${ styles.row}">
                  <div class="${ styles.column}">
                    <span class="${ styles.title}">Orders</span>
                    <p class="${ styles.description}">
                      <ul>
                        ${orders.map(o => `<li>${o.Rep} $${o.Total}</li>`).join('')}
                      </ul>
                    </p>
                    <a href="https://aka.ms/spfx" class="${ styles.button}">
                      <span class="${ styles.label}">Learn more</span>
                    </a>
                  </div>
                </div>
              </div>
            </div>`;
        });
      });
  }

  // ...
}

まず、aadTokenProviderFactoryを使用して AadTokenProvider のインスタンスを取得します。You start, by retrieving an instance of the AadTokenProvider using the aadTokenProviderFactory. 次に、AadTokenProvider を使用して Azure AD でセキュリティ保護された API のアクセス トークンを取得します。Next, you use the AadTokenProvider to retrieve the access token for your API secured with Azure AD. アクセス トークンを取得したら、要求ヘッダーのアクセス トークンを含むエンタープライズ API に対する AJAX 要求を実行します。Once you have obtained the access token, you execute the AJAX request to the enterprise API including the access token in the request headers.

ADAL JS を使用して認証を処理し、アクセス トークンを取得するUse ADAL JS to handle authorization and retrieve access token

|||UNTRANSLATED_CONTENT_START|||If you're using an older version of the SharePoint Framework that v1.6.0 and can't use the AadTokenProvider, you can use the ADAL JS library to handle the OAuth implicit flow and retrieve the access token for the specific API secured with Azure AD.|||UNTRANSLATED_CONTENT_END|||If you're using an older version of the SharePoint Framework that v1.6.0 and can't use the AadTokenProvider, you can use the ADAL JS library to handle the OAuth implicit flow and retrieve the access token for the specific API secured with Azure AD. AngularJS を使って構築されたアプリケーションの場合、ADAL JS は必要なアクセス トークンを、発信 Web 要求のヘッダーに自動的に追加する HTTP 要求インターセプターを提供します。For applications built using AngularJS, ADAL JS offers an HTTP request interceptor that automatically adds required access tokens to headers of outgoing web requests. この要求元を使用すると、開発者は、Azure AD でセキュリティ保護された API への Web  要求を変更する必要がなく、代わりに、アプリケーションの構築に集中できます。By using this requestor, developers don't need to modify web requests to APIs secured with Azure AD and can focus on building the application instead.

クライアント側 Web パーツで ADAL JS を使用する場合の制限事項Limitations when using ADAL JS with client-side web parts

ADAL JS ライブラリでは、クライアント側 Web アプリケーション内にある Azure AD の OAuth フローの実装が大幅に簡略化されます。ただし、SharePoint Framework のクライアント側 Web パーツと併用する場合は、多くの制限事項があります。これらの制限事項があるのは、他のアプリケーションとページを共有せずに、ページ全体を所有するクライアント側 Web アプリケーションによって使用されるように、ADAL JS が設計されているためです。The ADAL JS library significantly simplifies implementing the OAuth flow for Azure AD in client-side web applications. But it has a number of limitations when used with SharePoint Framework client-side web parts. These limitations are due to the fact that ADAL JS is designed to be used by client-side web applications that own the whole page and do not share the page with other applications.

共有ストレージShared storage

プロジェクトでの ADAL JS ライブラリの構成方法に応じて、データはブラウザーのローカル ストレージまたはセッション ストレージのいずれかに格納されます。Depending on how you configured the ADAL JS library in your project, it stores its data either in the browser's local storage or in the session storage. どちらにしても、ADAL JS によって格納されている情報は、同じページ上の任意のコンポーネントからアクセスできます。Either way, the information stored by ADAL JS is accessible to any component on the same page. たとえば、1 つの Web パーツが Microsoft Graph のアクセス トークンを取得すると、同じページ上にある他のすべての Web パーツがそのトークンを再利用して、Microsoft Graph を呼び出すことができます。For example, if one web part retrieves an access token for Microsoft Graph, any other web part on the same page can reuse that token and call Microsoft Graph.

シングルトンとしての ADAL JSADAL JS as a singleton

ADAL JS は、ページのグローバル スコープに登録されているシングルトン サービスとして動作するよう設計されています。ADAL JS is designed to work as a singleton service registered in the global scope of the page. IFrame で OAuth フローのコールバックを処理する場合は、ADAL JS コードはメイン ウィンドウから登録済みのシングルトン参照を使用して、トークン フローを解決します。When processing OAuth flow callbacks in IFrames, ADAL JS code uses the registered singleton reference from the main window to resolve the token flow. 各 Web パーツは別々の Azure AD アプリケーションに登録されているので、ADAL JS の同じインスタンスを再利用すると、すべての Web パーツがページ上に読み込まれた最初の Web パーツに登録されたのと同じ構成を使用するようになるという、望ましくない結果が生じます。Because each web part is registered with a different Azure AD application, reusing the same instance of ADAL JS leads to undesirable results where every web part uses the same configuration as the one registered by the first web part loaded on the page.

リソースベースのストレージResource-based storage

既定では、ADAL JS ライブラリは、Microsoft Graph や SharePoint など、特定のリソースに関連付けられている一連のキーの現在のアクセス トークンまたはその有効期限などの情報を格納します。By default, the ADAL JS library stores information such as the current access token or its expiration time in a set of keys associated with the particular resource, for example Microsoft Graph or SharePoint. さまざまなアクセス許可を使用して同じリソースにアクセスする複数のコンポーネントが 1 つのページにある場合、最初に取得されたトークンは ADAL JS によってすべてのコンポーネントに提供されます。If there are multiple components on one page accessing the same resource with different permissions, the first retrieved token is served by ADAL JS to all components. さまざまなコンポーネントが同じリソースへのアクセスを必要とする場合、それらは失敗する可能性があります。If different components require access to the same resource, they might fail. この制限事項を示すために、以下の例を考えてみます。To illustrate this limitation, consider the following example.

ページ上に、今後の会議を一覧表示する Web パーツと新しい会議を作成する Web パーツの 2 つの Web パーツがあるとします。Imagine that there are two web parts on the page: one that lists upcoming meetings, and one that creates a new meeting. 今後の会議を取得するために、今後の会議の Web パーツはユーザーの予定表を読み取るためのアクセス許可を持つ Microsoft Graph のアクセス トークンを使用します。To get upcoming meetings, the upcoming meetings web part uses a Microsoft Graph access token with permissions to read users' calendars. 一方、新しい会議を作成する Web パーツでは、ユーザーの予定表に書き込むためのアクセス許可を持つ Microsoft Graph のアクセス トークンが必要です。The web part that creates new meetings, on the other hand, requires a Microsoft Graph access token with permissions to write to users' calendars.

最初に、今後の会議の Web パーツが読み込まれると、ADAL JS は読み取りアクセス許可のみを持つトークンを取得します。If the upcoming meetings web part loads first, ADAL JS retrieves its token with only the read permission. 次に、ADAL JS によって、同じトークンが新しい会議を作成する Web パーツに提供されます。The same token is then served by ADAL JS to the web part creating new meetings. このように、Web パーツが新しい会議を作成しようとすると、アクセス拒否エラーが発生し、Web パーツは失敗します。As you can see, when the web part attempts to create a new meeting, the web part fails with an access denied error. リソース ベースのストレージであるため、以前に取得したトークンが期限切れになるまで、ADAL JS は Microsoft Graph の新しいトークンを取得しません。Because of the resource-based storage, ADAL JS wouldn't retrieve a new token for Microsoft Graph until the previously retrieved token expired.

認証コールバックの処理Processing authorization callbacks

OAuth 暗黙的フローは、Azure AD とフローに参加しているアプリケーション間のリダイレクトに基づいています。OAuth implicit flow is based on redirects between Azure AD and the application participating in the flow. 認証プロセスが開始されると、アプリケーションは Azure AD のサインイン ページにリダイレクトします。When the authentication process starts, the application redirects you to the Azure AD sign-in page. 認証が完了すると、Azure AD はアプリケーションに再度リダイレクトして、アプリケーションの URL ハッシュの ID トークンを送信して処理します。After the authentication completes, Azure AD redirects you back to the application, and sends the identity token in the URL hash for the application to process. SharePoint ページ上に配置された Web パーツの観点から見ると、この動作には 2 つの欠点があります。From the perspective of a web part placed on a SharePoint page, this behavior has two drawbacks.

SharePoint にサインインしていても、Azure AD を使用してセキュリティで保護されたリソースに Web パーツがアクセスできるようにするには、Azure AD で個別に認証する必要があります。Even though you are signed in to SharePoint, you need to separately authenticate with Azure AD in order for your web part to be able to access resources secured with Azure AD. Web パーツはページ全体のごく一部ですが、認証プロセスを完了するためにページ全体から移動する必要があります。これは良いユーザー エクスペリエンスではありません。The web part is a small part of the overall page, but to complete the authentication process, you need to leave the whole page, which is a poor user experience.

認証が完了すると、Azure AD はアプリケーションに再度リダイレクトします。After the authentication completes, Azure AD redirects you back to your application. URL ハッシュには、アプリケーションで処理する必要がある ID トークンが含まれています。In the URL hash, it includes the identity token that your application needs to process. 残念なことに、1 つのページに複数の Web パーツがある場合、ID トークンにはその生成元に関する情報は含まれていないので、すべての Web パーツは URL からの ID トークンを処理しようとします。Unfortunately, because the identity token doesn't contain any information about its origin, if you had multiple web parts on one page, all of them would try to process the identity token from the URL.

ADAL JS を使用して Azure AD でセキュリティ保護された API と通信する際の考慮事項Considerations when using ADAL JS to communicate with APIs secured with Azure AD

制限事項とは別に、SharePoint Framework ソリューションでADAL JS を実装する前に念頭に置くべき考慮事項がいくつかあります。Aside the limitations, there are some considerations that you should take into account before implementing ADAL JS in your SharePoint Framework solution yourself.

ADAL JS は、シングルページ アプリケーションのために使用することが意図されています。ADAL JS is meant to be used for single-page applications

ADAL JS は単一ページのアプリケーションで使用するように設計されています。そのため、既定では、SharePoint Framework ソリューションで使用した場合に正しく機能しません。ただし、パッチを適用すると SharePoint Framework プロジェクトで正常に使用できます。ADAL JS has been designed to be used with single-page applications. As such, by default it doesn't work correctly when used with SharePoint Framework solutions. By applying a patch however, it can be successfully used in SharePoint Framework projects.

可能なすべての認証の例外を自分で処理するHandle all possible authentication exceptions yourself

ADAL JS と OAuth を使用して、Azure AD でセキュリティ保護された API にアクセスする場合、認証フローは Azure によって実現します。When using ADAL JS and OAuth to access APIs secured with Azure AD, the authentication flow is facilitated by Azure. すべてのエラーは、Azure サインイン ページで処理されます。Any errors are handled by the Azure sign-in page. ユーザーが組織のアカウントでサインインすると、アプリケーションは、有効なアクセス トークンを取得しようとします。After the user has signed-in with her organizational account, the application tries to retrieve a valid access token. この段階で発生するすべてのエラーは、アプリケーションの開発者によって明示的に処理される必要があります。アクセス トークンの取得は対話型ではなく、ユーザーに UI を表示しないで行われるためです。All errors that occur at this stage have to be explicitly handled by the developer of the application because retrieving access tokens is non-interactive and doesn't present any UI to the user.

Azure AD にすべてのクライアント側アプリケーションを登録するRegister every client-side application in Azure AD

ADAL JS を使用するクライアント側アプリケーションはどれも、Azure AD のアプリケーションとして登録する必要があります。Every client-side application that wants to use ADAL JS needs to be registered as an Azure AD application. 登録情報の一部として、アプリケーションが存在する URL があります。A part of the registration information is the URL where the application is located. アプリケーションは完全にクライアント側であり、機密情報を安全に格納できないため、URL はアプリケーションと Azure AD 間のセキュリティを確立するための取り決めの一部です。Because the application is fully client-side and is not capable of securely storing a secret, the URL is a part of the contract between the application and Azure AD to establish security. 開発者は特定の Web パーツが使用される URL すべてを前もって知ることはできないため、SharePoint Framework ソリューションにとってこの要件は問題となります。This requirement is problematic for SharePoint Framework solutions because developers cannot simply know upfront all URLs where a particular web part will be used. さらに現時点では、Azure AD は最大 10 の応答 URL を指定できますが、シナリオによってはこれは十分ではない可能性があります。Additionally, at this moment, Azure AD supports specifying up to 10 reply URLs, which might not be sufficient in some scenarios.

各 web パーツ内の承認フローを実装します。Implement authorization flow in each web part

クライアント側のアプリケーションが特定のリソースへのアクセス トークンを取得する前に、ユーザーを認証し、アクセス トークンに交換できる ID トークンを取得する必要があります。Before a client-side application can retrieve an access token to a specific resource, it needs to authenticate the user to obtain the ID token which can then be exchanged for an access token. ユーザーが組織のアカウントを使用して既にサインインしている SharePoint で SharePoint Framework ソリューションがホストされている場合でも、SharePoint Framework ソリューションは現在のユーザーの認証情報を利用できません。Even though SharePoint Framework solutions are hosted in SharePoint, where users are already signed in using their organizational accounts, the authentication information for the current user isn't available to SharePoint Framework solutions. 代わりに、それぞれのソリューションがユーザーに対し、明示的にサインインを要求する必要があります。Instead, each solution must explicitly request the user to sign in. これを行うには、ユーザーを Azure サインイン ページにリダイレクトするか、サインイン ページでポップアップ ウィンドウを表示します。This can be done either by redirecting the user to the Azure sign-in page or by showing a pop-up window with the sign-in page. 後者はページ上の多くの要素の 1 つなので、Web パーツの場合にあまり目立ちません。The latter is less intrusive in the case of a web part, which is one of the many elements on a page. ページに複数の SharePoint Framework のクライアント側 Web パーツがある場合、それぞれが自身の状態を個別に管理し、その特定の Web パーツに明示的にサインインするよう、ユーザーに要求します。If there are multiple SharePoint Framework client-side web parts on the page, each of them manages its state separately and requires the user to explicitly sign in to that particular web part.

Internet Explorer のセキュリティゾーンを構成するInternet Explorer security zones

Azure AD でセキュリティ保護された API と通信に必要なアクセス トークンの取得は、Azure AD エンドポイントへのリダイレクトを処理する非表示の iframe により行われます。Retrieving access tokens required to communicate with APIs secured with Azure AD is facilitated by hidden iframes that handle redirects to Azure AD endpoints. Azure AD のサインイン エンドポイントと SharePoint Online の URL が同じセキュリティ ゾーンにない場合に、OAuth の暗黙的フローでアクセス トークンの取得が失敗することは、Microsoft Internet Explorer の既知の制限です。There is a known limitation in Microsoft Internet Explorer where obtaining access tokens in OAuth implicit flow fails, if the Azure AD sign-in endpoints and the SharePoint Online URL are not in the same security zone. 組織で Internet Explorer を使用している場合は、Azure AD のエンドポイントと SharePoint Online の URL が同じセキュリティ ゾーンで構成されていることを確認してください。If your organization is using Internet Explorer, ensure that the Azure AD endpoint and SharePoint Online URLs are configured in the same security zone. 一貫性を維持するために、グループ ポリシーを使用して、エンドユーザーに対してこれらの設定をプッシュする選択をする組織もあります。To maintain consistency, some organizations choose to push these settings to end-users using group policies.

Azure AD でセキュリティ保護された API に対するすべての AJAX 要求へのアクセス トークンを追加しますAdd access token to all AJAX requests to APIs secured with Azure AD

Azure AD でセキュリティ保護されたAPIには匿名でアクセスできません。APIs secured with Azure AD cannot be accessed anonymously. 代わりに、API を呼び出すアプリケーションにより、有効な資格情報を提示するように要求します。Instead they require a valid credential to be presented by the application calling them. クライアント側アプリケーションで OAuth の暗黙的フローを使用する場合、この資格情報は ADAL JS を使用して取得された、ベアラーのアクセス トークンです。When using the OAuth implicit flow with client-side applications, this credential is the bearer access token obtained using ADAL JS. AngularJS を使用して SharePoint Framework ソリューションを構築した場合、ADAL JS はユーザーが特定のリソースの有効なアクセス トークンを持っていることを自動的に確認し、AngularJS の $http サービスを使用して実行されるすべての送信要求にそれを追加します。If you have built your SharePoint Framework solution using AngularJS, ADAL JS automatically ensures that you have a valid access token for the particular resource, and adds it to all outgoing requests executed by using the AngularJS $http service. 他の JavaScript ライブラリを使用する場合は、有効なアクセス トークンを取得し、さらに必要に応じてそれを更新し、自身で Web 送信要求にそれを添付する必要があります。When using other JavaScript libraries, you have to obtain a valid access token, and if necessary refresh it, and attach it to the outgoing web requests yourself.

クライアント側 Web パーツで ADAL JS を使用するUse ADAL JS with client-side web parts

ADAL JS に関する制限事項に対処して、SharePoint Framework のクライアント側 Web パーツに OAuth を正常に実装することができます。You can overcome the limitations in ADAL JS to implement OAuth successfully in your SharePoint Framework client-side web part.

重要

次のガイダンスは、ADAL JS v1.0.12 に基づいています。The following guidance is based on ADAL JS v1.0.12. SharePoint Framework プロジェクトに ADAL JS を追加する場合、ADAL JS v1.0.12 をインストールしてください。インストールしない場合、この記事に記載されているガイダンスが想定通り動作しません。When adding ADAL JS to your SharePoint Framework projects, ensure that you're installing ADAL JS v1.0.12, or the guidance mentioned in this article will not work as expected.

Web パーツに ADAL JS を読み込むLoad ADAL JS in your web part

Web パーツは TypeScript を使用して構築され、AMD モジュールとして分散されています。モジュラー式アーキテクチャを使用すると、Web パーツで使用されるさまざまなリソースを分離できます。ADAL JS は自身をグローバル スコープに登録するように設計されていますが、次のコードを使用して Web パーツに読み込むことができます。Web parts are built using TypeScript and distributed as AMD modules. Their modular architecture allows you to isolate the different resources used by the web part. ADAL JS is designed to register itself in the global scope, but you can load it in a web part by using the following code:

import * as AuthenticationContext from 'adal-angular';

このステートメントは、Web パーツで使用する ADAL JS 機能を公開する AuthenticationContext クラスをインポートします。モジュールの名前にかかわらず、AuthenticationContext クラスはすべての JavaScript ライブラリで機能します。This statement imports the AuthenticationContext class that exposes the ADAL JS functionality for use in web parts. Despite the name of the module, the AuthenticationContext class works with every JavaScript library.

ADAL JS を SharePoint Framework の Web パーツでの使用に適したものにするMake ADAL JS suitable for use with SharePoint Framework web parts

ADAL JS の現在の機能は、Web パーツでの使用には適していません。次のパッチを使用して、ADAL JS を Web パーツで機能するようにします。The current ADAL JS functionality is unsuitable for use in web parts. Use the following patch to make ADAL JS work in your web part.

WebPartAuthenticationContext.jsWebPartAuthenticationContext.js

const AuthenticationContext = require('adal-angular');

AuthenticationContext.prototype._getItemSuper = AuthenticationContext.prototype._getItem;
AuthenticationContext.prototype._saveItemSuper = AuthenticationContext.prototype._saveItem;
AuthenticationContext.prototype.handleWindowCallbackSuper = AuthenticationContext.prototype.handleWindowCallback;
AuthenticationContext.prototype._renewTokenSuper = AuthenticationContext.prototype._renewToken;
AuthenticationContext.prototype.getRequestInfoSuper = AuthenticationContext.prototype.getRequestInfo;
AuthenticationContext.prototype._addAdalFrameSuper = AuthenticationContext.prototype._addAdalFrame;

AuthenticationContext.prototype._getItem = function (key) {
  if (this.config.webPartId) {
    key = this.config.webPartId + '_' + key;
  }

  return this._getItemSuper(key);
};

AuthenticationContext.prototype._saveItem = function (key, object) {
  if (this.config.webPartId) {
    key = this.config.webPartId + '_' + key;
  }

  return this._saveItemSuper(key, object);
};

AuthenticationContext.prototype.handleWindowCallback = function (hash) {
  if (hash == null) {
    hash = window.location.hash;
  }

  if (!this.isCallback(hash)) {
    return;
  }

  var requestInfo = this.getRequestInfo(hash);
  if (requestInfo.requestType === this.REQUEST_TYPE.LOGIN) {
    return this.handleWindowCallbackSuper(hash);
  }

  var resource = this._getResourceFromState(requestInfo.stateResponse);
  if (!resource || resource.length === 0) {
    return;
  }

  if (this._getItem(this.CONSTANTS.STORAGE.RENEW_STATUS + resource) === this.CONSTANTS.TOKEN_RENEW_STATUS_IN_PROGRESS) {
    return this.handleWindowCallbackSuper(hash);
  }
}

AuthenticationContext.prototype._renewToken = function (resource, callback) {
  this._renewTokenSuper(resource, callback);
  var _renewStates = this._getItem('renewStates');
  if (_renewStates) {
    _renewStates = _renewStates.split(',');
  }
  else {
    _renewStates = [];
  }
  _renewStates.push(this.config.state);
  this._saveItem('renewStates', _renewStates);
}

AuthenticationContext.prototype.getRequestInfo = function (hash) {
  var requestInfo = this.getRequestInfoSuper(hash);
  var _renewStates = this._getItem('renewStates');
  if (!_renewStates) {
    return requestInfo;
  }

  _renewStates = _renewStates.split(';');
  for (var i = 0; i < _renewStates.length; i++) {
    if (_renewStates[i] === requestInfo.stateResponse) {
      requestInfo.requestType = this.REQUEST_TYPE.RENEW_TOKEN;
      requestInfo.stateMatch = true;
      break;
    }
  }

  return requestInfo;
}

AuthenticationContext.prototype._addAdalFrame = function (iframeId) {
  var adalFrame = this._addAdalFrameSuper(iframeId);
  adalFrame.style.width = adalFrame.style.height = '106px';
  return adalFrame;
}

window.AuthenticationContext = function() {
  return undefined;
}

パッチは、ADAL JS に対して次の変更を適用します。The patch applies the following changes to ADAL JS:

  • すべての情報は、Web パーツに固有のキーに格納されます (_getItem 関数と _saveItem 関数の上書きを参照してください)。All information is stored in a key specific to the web part (see the override of the _getItem and _saveItem functions).
  • コールバックは、そのコールバックを開始した Web パーツでのみ処理されます (handleWindowCallback 関数の上書きを参照してください)。Callbacks are processed only by web parts that initiated them (see the override of the handleWindowCallback function).
  • コールバックからのデータを確認する場合、グローバルに登録されているシングルトンの代わりに、特定の Web パーツの AuthenticationContext クラスのインスタンスが使用されます (_renewTokengetRequestInfo、および window.AuthenticationContext 関数の空の登録を参照してください)。When verifying data from callbacks, the instance of the AuthenticationContext class of the specific web part is used instead of the globally registered singleton (see _renewToken, getRequestInfo and the empty registration of the window.AuthenticationContext function).
SharePoint Framework の Web パーツで ADAL JS パッチを使用するUse the ADAL JS patch in SharePoint Framework web parts

SharePoint Framework の Web パーツで ADAL JS を正しく機能させるには、特定の方法で構成する必要があります。For ADAL JS to work correctly in SharePoint Framework web parts, you have to configure it in a specific way.

  1. 標準 ADAL JS Config インターフェイスを拡張するカスタム インターフェイスを定義して、構成オブジェクト上に追加のプロパティを公開する必要があります。Define a custom interface that extends the standard ADAL JS Config interface to expose additional properties on the configuration object.

    export interface IAdalConfig extends adal.Config {
     popUp?: boolean;
     callback?: (error: any, token: string) => void;
     webPartId?: string;
    }
    

    プロパティと callback 関数の両方とも既に ADAL JS に実装されていますが、標準の Config インターフェイスの TypeScript 型指定では公開されていません。popUpThe popUp property and the callback function are both already implemented in ADAL JS but are not exposed in the TypeScript typings of the standard Config interface. Azure AD のサインイン ページにリダイレクトするのではなく、ポップアップ ウィンドウを使用して、ユーザーが Web パーツにサインインできるようにするには、それらが必要です。You need them in order to allow users to sign in to your web parts by using a pop-up window instead of redirecting them to the Azure AD sign-in page.

  2. ADAL JS のパッチ、カスタム構成インターフェイス、および構成オブジェクトを Web パーツのメイン コンポーネントに読み込みます。Load the ADAL JS patch, the custom configuration interface, and your configuration object into the main component of your web part.

    import * as AuthenticationContext from 'adal-angular';
    import adalConfig from '../AdalConfig';
    import { IAdalConfig } from '../../IAdalConfig';
    import '../../WebPartAuthenticationContext';
    
  3. コンポーネントのコンストラクターで、追加のプロパティを指定して ADAL JS 構成を拡張し、AuthenticationContext クラスの新しいインスタンスを作成するために使用します。In the constructor of your component, extend the ADAL JS configuration with additional properties and use it to create a new instance of the AuthenticationContext class.

    export default class UpcomingMeetings extends React.Component<IUpcomingMeetingsProps, IUpcomingMeetingsState> {
     private authCtx: adal.AuthenticationContext;
    
     constructor(props: IUpcomingMeetingsProps, state: IUpcomingMeetingsState) {
       super(props);
    
       this.state = {
         loading: false,
         error: null,
         upcomingMeetings: [],
         signedIn: false
       };
    
       const config: IAdalConfig = adalConfig;
       config.webPartId = this.props.webPartId;
       config.popUp = true;
       config.callback = (error: any, token: string): void => {
         this.setState((previousState: IUpcomingMeetingsState, currentProps: IUpcomingMeetingsProps): IUpcomingMeetingsState => {
           previousState.error = error;
           previousState.signedIn = !(!this.authCtx.getCachedUser());
           return previousState;
         });
       };
    
       this.authCtx = new AuthenticationContext(config);
       AuthenticationContext.prototype._singletonInstance = undefined;
     }
    }
    

コードは、まず標準 ADAL JS 構成オブジェクトを取得し、新しく定義した構成インターフェイスの型にキャストします。The code first retrieves the standard ADAL JS configuration object and casts it to the type of the newly defined configuration interface.

次に、すべての ADAL JS の値をページ上の他の Web パーツと競合しない方法で格納できるように、Web パーツ インスタンスの ID を渡します。It then passes the ID of the web part instance so that all ADAL JS values can be stored in a way that they won't collide with other web parts on the page.

その後、ポップアップベースの認証を有効にして、認証が完了したときに実行するコールバック関数を定義して、コンポーネントを更新します。Next, it enables the pop-up-based authentication and defines a callback function that runs when authentication completes to update the component.

最後に、AuthenticationContext クラスの新しいインスタンスを作成して、AuthenticationContext クラスのコンストラクター内の _singletonInstance セットをリセットします。Finally, it creates a new instance of the AuthenticationContext class and resets the _singletonInstance set in the constructor of the AuthenticationContext class. この操作は、すべての Web パーツで独自のバージョンの ADAL JS 認証コンテキストを使用できるようにするために必要です。This is required in order to allow every web part to use its own version of the ADAL JS authentication context.

クライアント側 Web パーツで OAuth 暗黙的フローを使用する際の考慮事項Considerations when using OAuth implicit flow in client-side web parts

Azure AD によってセキュリティで保護されたリソースと通信する SharePoint Framework のクライアント側 Web パーツを構築する前に、考慮すべきいくつかの制約があります。Before you build SharePoint Framework client-side web parts that communicate with resources secured by Azure AD, there are some constraints that you should consider. 次の情報は、Web パーツでの OAuth 認証がソリューションと組織に最適な選択である場合を判断するのに役立ちます。The following information helps you determine when OAuth authorization in web parts is the right choice for your solution and organization.

SharePoint Framework の Web パーツは信頼性が高いSharePoint Framework web parts are highly trusted

SharePoint アドインとは異なり、Web パーツは現在のユーザーと同じアクセス許可で実行されます。Unlike SharePoint Add-ins, web parts run with the same permissions as the current user. ユーザーが実行できるすべての操作を Web パーツも同様に実行できます。Whatever the user can do, the web part can do as well. これが、テナント管理者のみが Web パーツのインストールと展開ができる理由です。This is why web parts can be installed and deployed only by tenant administrators. テナント管理者は、展開している Web パーツが信頼できるソースからのものであり、かつテナントでの使用が承認されていることを確認する必要があります。The tenant administrator should verify that web parts they are deploying come from a trusted source and were approved for use in the tenant.

Web パーツはページの一部であり、SharePoint アドインとは異なり、DOM とリソースをページ上の他の要素と共有します。Web parts are a part of the page and, unlike SharePoint Add-ins, share DOM and resources with other elements on the page. Azure AD によってセキュリティで保護されているリソースへのアクセスを付与するアクセス トークンは、Web パーツが配置されているページと同じページへのコールバックを経由して取得されます。Access tokens that grant access to resources secured with Azure AD, are retrieved through a callback to the same page where the web part is located. そのコールバックは、ページ上の任意の要素で処理できます。That callback can be processed by any element on the page. また、コールバックからアクセス トークンが処理された後、アクセス トークンはブラウザーのローカル ストレージまたはセッション ストレージに格納され、ページ上の任意のコンポーネントはそこからアクセス トークンを取得できます。Also, after access tokens are processed from callbacks, they are stored in the browser's local storage or session storage from where they can be retrieved by any component on the page. 悪意のある Web パーツの場合、トークンを読み込んで、そのトークンまたはトークンを使用して取得したデータを外部サービスに公開する可能性があります。A malicious web part could read the token and either expose the token or the data it retrieved using that token to an external service.

URL は、OAuth 暗黙的フローのコントラクトの一部ですURL is a part of the OAuth implicit flow contract

重要

AadTokenProvider を使用する場合、OAuth 暗黙的フローを処理するため、このセクションの情報は適用されません。Information in this section doesn't apply to you if you use the AadTokenProvider as it handles the OAuth implicit flow for you

クライアント側のアプリケーションは、ユーザーに明示しない場合、クライアント シークレットを格納することはできません。Client-side applications are incapable of storing a client secret without revealing it to users. 特定のアプリケーションの信頼性を確認するために、Azure AD とアプリケーションの間の信頼できる契約の一部として、アプリケーションがホストされている URL が使用されます。To verify the authenticity of the particular application, the URL where the application is hosted is used as a part of the trust contract between Azure AD and the application. このため、OAuth 暗黙的フローを使用する Web パーツを含むすべてのページの URL を、Azure AD に登録する必要があります。The consequences of this are that the URL of every page with web parts using OAuth implicit flow must be registered with Azure AD. ページが登録されていない場合は、OAuth フローは失敗し、Web パーツはセキュリティで保護されたリソースへのアクセスを拒否されます。If a page is not registered, the OAuth flow fails, and the web part is denied access to the secured resource.

この必須のセキュリティ対策は、ユーザーによるページへの Web パーツの追加を許可する組織にとって、重要な制限です。This necessary security measure is a significant limitation for organizations that allow users to add web parts to pages. OAuth 暗黙的フローを使用する Web パーツが使用される場所の数を制限することをお勧めします。We recommend that you limit the number of locations where web parts using OAuth implicit flow are used. ホーム ページや特定のランディング ページなど、いくつかのよく知られている場所を使用して、これらの場所を Azure AD に登録します。Use a few well known locations such as the home page or specific landing pages, and have these locations registered with Azure AD.

Internet Explorer のセキュリティ ゾーンInternet Explorer security zones

Internet Explorer では、アクセスした Web サイトにセキュリティ ポリシーを適用するためにセキュリティ ゾーンを使用します。Internet Explorer uses security zones to apply security policies to websites you visit. 異なるセキュリティ ゾーンに割り当てられた Web サイトは独立して実行され、連携することはできません。Websites assigned to different security zones run isolated and cannot cooperate. SharePoint Framework のクライアント側 Web パーツで OAuth 暗黙的フローを使用している場合は、OAuth と Azure AD サインイン ページ (https://login.microsoftonline.com) にある) を使用する Web パーツを含むページは、同じセキュリティ ゾーンに含まれる必要があります。When using OAuth implicit flow in SharePoint Framework client-side web parts, the page with web parts that use OAuth and the Azure AD sign-in page (located at https://login.microsoftonline.com) must be in the same security zone. このような構成がない場合、認証プロセスは失敗し、Web パーツは Azure AD でセキュリティ保護されたリソースと通信できません。Without such configuration, the authentication process fails, and web parts won't be able to communicate with Azure AD-secured resources.

ユーザーは、定期的にサインインする必要がありますUser must sign in frequently

通常の OAuth フローを使用している場合、Web アプリケーションおよびクライアント アプリケーションは、存続期間が短いアクセス トークン(既定では 60 分) と有効期間がより長い更新トークンを取得します。When using regular OAuth flow, web applications and client applications get a short-lived access token and a refresh token that is valid for a longer period of time. アクセス トークンの有効期限が切れたら、更新トークンを使用して新しいアクセス トークンを取得します。When the access token expires, the refresh token is used to get a new access token. この方法により、ユーザーが Azure AD にサインインする頻度を減らすことができます。This approach reduces how often users need to sign in to Azure AD.

クライアント側アプリケーションは安全にシークレットを格納できないため、更新トークンを公開することはセキュリティ上の重大な脅威となります。このため、クライアント側アプリケーションは OAuth 暗黙的フローの一部としてアクセス トークンのみを受信します。Because client-side applications are incapable of securely storing secrets, and disclosing a refresh token is a serious security threat, they only receive the access token as part of the OAuth implicit flow. そのトークンが期限切れになると、アプリケーションは新しい OAuth フローを開始する必要があり、ユーザーは再度サインインすることを求められる場合があります。After that token expires, the application must start a new OAuth flow, which could require the user to sign in again.

関連項目See also