Office 365 Management API の使用を開始する

[アーティクル]
01/25/2023

Office 365 Management API と同じようにセキュリティで保護されたサービスへのアクセスを必要とするアプリケーションを作成するときは、アプリケーションがサービスへのアクセス権を保持しているかを確認する方法をサービスに提供する必要があります。 Office 365 Management API では、Azure AD を使用してサービスへのアクセス権をアプリケーションに付与するための認証サービスを提供します。

以下の 4 つの手順があります。

Azure AD でアプリケーションを登録する。アプリケーションが Office 365 Management API にアクセスできるようにするには、アプリケーションを Azure AD に登録する必要があります。これにより、アプリケーションの ID を設定し、API にアクセスするために必要なアクセス許可レベルを指定することができます。
Office 365 テナント管理者の同意を得る。 Office 365 Management API を使用してアプリケーションがテナントのデータにアクセスする許可への同意を、Office 365 テナント管理者が明示的に付与する必要があります。同意プロセスでは、テナント管理者がブラウザーを操作して Azure AD の同意 UI にサインインし、アプリケーションが要求するアクセス許可を確認して要求を許可または拒否します。同意が与えられると、UI は認証コードを含めた URL を使用してユーザーをアプリケーションにリダイレクトします。アプリケーションは Azure AD にサービスからサービスへの呼び出しを行い、この認証コードをテナント管理者とアプリケーションの両方に関する情報が含まれているアクセストークンと交換します。テナント ID はアクセストークンから抽出され、将来使用するために格納される必要があります。
Azure AD からアクセストークンを要求する。 Azure AD で設定されているアプリケーションの資格情報を使用すると、アプリケーションは、テナント管理者の追加の操作を必要とせず、継続的に同意済みのテナントの追加のアクセストークンを要求することができます。これらのアクセストークンはテナント管理者に関する情報が含まれていないため、アプリ専用トークンと呼ばれます。
Office 365 Management API の呼び出し。アプリケーションを認証して承認するため、アプリ専用アクセストークンが Office 365 Management API に渡されます。

次の図は、同意とアクセストークンの要求のシーケンスを示しています。

管理 API が承認フローを開始する

重要

Office 365 管理アクティビティ API を介してデータにアクセスする前に、Office 365 組織の統合監査ログを有効にする必要があります。これを実行するには、Office 365 監査ログをオンにします。手順については、「Office 365 監査ログの検索を有効または無効にする」を参照してください。

Office 365 サービス通信 API のみを使用している場合は、統合監査ログを有効にする必要はありません。

Azure AD でアプリケーションを登録する

Office 365 Management API は、Office 365 テナントデータに対し、Azure AD を使用してセキュリティ保護された認証を行います。 Office 365管理 API にアクセスするには、Azure AD にアプリを登録する必要があります。構成の一環として、アプリが API にアクセスするために必要なアクセス許可レベルを指定します。

前提条件

Azure AD でアプリを登録するには、Office 365 サブスクリプションと、Office 365 サブスクリプションに関連付けられている Azure のサブスクリプションが必要です。開始するには、Office 365 と Azure の両方に、試用版のサブスクリプションを使用できます。詳細については、Office 365 開発者プログラムへようこそを参照してください。

Azure portal を使用してアプリケーションを Azure AD で登録する

適切なサブスクリプションを持つ Microsoft のテナントがあれば、Azure AD でアプリケーションを登録できます。

使用するサブスクリプションを持つ Microsoft テナントの資格情報を使用して、Azure portalにサインインOffice 365。 Microsoft 365 管理センターの左側のナビゲーションウィンドウに表示されるリンクを使用して、Azure Portal にアクセスすることもできます。
左側のナビゲーションウィンドウで、[Azure Active Directory] (1) を選択します。
[Azure Active Directory]ページで、[アプリの登録] (2) を選択し、[新規登録] (3) を選択します。
[アプリの登録] ページで、[新規登録] を選択します。

アプリの登録を開始する新しいページが表示されます。
[アプリケーションの登録] ページで、次の操作を行います。
1. アプリに名前を付けます。
2. アプリを使用し、API にアクセスできるユーザーを選択します。
3. 必要に応じて、認証後のユーザーリダイレクト用リダイレクト URL を指定します。
[登録] をクリックして、新しいアプリを登録します。

Azure AD でアプリケーションのプロパティを構成する

アプリケーションを登録すると、いくつかの重要なプロパティを指定する必要があります。プロパティでは、Azure AD 内でアプリケーションがどのように機能するか、また、テナント管理者が Office 365 Management API を使用してアプリケーションにテナントデータへのアクセス許可に同意する方法を指定します。

Azure AD アプリケーションの全般的なアプリケーション構成の詳細については、「Application オブジェクトのプロパティ」を参照してください。

クライアント ID。この値は Azure AD で自動的に生成されます。アプリケーションは、テナント管理者に同意を求めるとき、および Azure AD からアプリ専用トークンを要求するときに、この値を使用します。
アプリケーションはマルチテナントです。テナント管理者が Office 365 Management API を使用してアプリケーションにテナントデータへのアクセス許可に同意するには、このプロパティは [はい] に設定する必要があります。このプロパティが [いいえ] に設定されている場合、アプリケーションは、独自のテナントデータにしかアクセスすることはできません。
応答 URL。これは、Office 365 Management API を使用してアプリケーションのデータへのアクセス許可に同意した後にテナント管理者がリダイレクトされる URL です。必要に応じて、複数の応答 URL を設定できます。 Azure は、アプリケーションを作成する際、指定したサインオン URL に最初に一致した URL を自動的に設定しますが、必要に応じてこの値を変更することができます。

これらのプロパティを変更した後は、必ず [保存] をクリックしてください。

アプリケーションの新しいキーを生成する

キー (クライアントシークレットとも呼ばれます) は、アクセストークンの認証コードを交換するときに使用されます。

Azure portal の [Azure Active Directory]ページで、[アプリの登録] を選択し、お使いのアプリケーションを選択します。
アプリのページが表示されたら、左側のウィンドウで [証明書 & シークレット (1)] を選択します。このページでは、証明書をアップロードし、新しいクライアントシークレット (2) を作成できます。
[ 証明書 & シークレット (1)] ページで、[ 新しいクライアントシークレット (2)] を選択し、説明を入力し、キーの期間 (3) を選択し、[ 追加] (4) を選択します。
クライアントシークレットの作成後、値が [クライアントシークレット] (2) の下に表示されます。クリップボードアイコン (3) をクリックし、クライアントシークレット値をクリップボードにコピーします。

重要

クライアントシークレット値は、最初に生成したときにだけ、Azure に表示されます。後でこのページに戻ってクライアントシークレット値を取得することはできません。後で使用できるよう、必ずコピーして安全な場所に保存してください。

サービス間の呼び出しを有効にする X.509 証明書を構成します。

デーモンやサービスなど、バックグラウンドで実行されているアプリケーションは、最初の同意が与えられた後、繰り返しテナント管理者に同意を求めることがなく、アプリ専用アクセストークン要求にクライアントの資格情報を使用できます。

詳細については、「クライアント資格情報を使用したサービス間の呼び出し」を参照してください。

Azure AD からアプリ専用アクセストークンを要求するときは、X.509 証明書をクライアントの資格情報として使用するよう、アプリケーションを構成しなければなりません。プロセスは 2 つの手順で行います。

X.509 証明書を取得する。自己署名証明書または公的に信頼された証明機関によって発行された証明書を使用することができます。
拇印と、証明書の公開キーを含むようにアプリケーションマニフェストを変更します。

次の手順は、Visual Studio または Windows SDK makecert ツールを使用して自己署名証明書を生成し、base64 でエンコードされたファイルに公開キーをエクスポートする方法を示しています。

コマンドラインから、次を実行します。
```
 makecert -r -pe -n "CN=MyCompanyName MyAppName Cert" -b 03/15/2015 -e 03/15/2017 -ss my -len 2048
```
注:

X.509 証明書の生成時に、キーの長さが 2048 以上になっていることを確認します。キーの長さがそれより短い場合は、有効なキーとして受け入れられません。
証明書 MMC スナップインを開き、自分のユーザーアカウントに接続します。
[個人用] フォルダーで新しい証明書を見つけて、公開キーを base64 でエンコードされたファイル (たとえば) mycompanyname.cerにエクスポートします。アプリケーションは、この証明書を Azure AD との通信に使用するため、秘密キーへのアクセスも確実に維持されるようになります。

注:

Windows PowerShell を使用すると、拇印および Base64 でエンコードされた公開キーを抽出できます。その他のプラットフォームには、証明書のプロパティを取得する同様のツールがあります。

Windows PowerShellプロンプトで、次のように入力して実行します。

 $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
 $cer.Import("mycer.cer")
 $bin = $cer.GetRawCertData()
 $base64Value = [System.Convert]::ToBase64String($bin)
 $bin = $cer.GetCertHash()
 $base64Thumbprint = [System.Convert]::ToBase64String($bin)
 $keyid = [System.Guid]::NewGuid().ToString()

$base64Thumbprint、$base64Value、および $keyid の値を保存します。これらの値は、次の一連の手順でアプリケーションマニフェストを更新するときに必要になります。

ここで、証明書から抽出された値と、生成されたキー ID を使用して、Azure AD のアプリケーションマニフェストを更新する必要があります。
Azure portal で、[アプリの登録]、>[すべてのアプリケーション] の順に移動し、アプリケーションを選択してから、左側のウィンドウで [マニフェスト] を選択します。
[マニフェスト] ページ (1) の先頭のナビゲーションバーで、[ダウンロード] (2) を選択します。
エディターでダウンロードしたマニフェストを開き、空の keyCredentials プロパティを次の JSON で置き換えます。
```
   "keyCredentials": [
     {
         "customKeyIdentifier" : "$base64Thumbprint_from_above",
         "keyId": "$keyid_from_above",
         "type": "AsymmetricX509Cert",
         "usage": "Verify",
         "value": "$base64Value_from_above"
     }
 ],
```
注:

KeyCredentials プロパティは、ロールオーバーシナリオでは複数の X.509 証明書のアップロードを可能にする、または漏えいシナリオでは証明書を削除することを可能にするコレクションです。
変更内容を保存します。コマンドバーの [管理マニフェスト] を選択して [マニフェストをアップロード] を選択し、更新したマニフェストファイルを参照してそのファイルを選択することで、更新済みのマニフェストをアップロードします。

アプリが Office 365 Management APIにアクセスするために必要な許可を指定します。

最後に、Office 365 Management API でアプリがどのようなアクセス許可を必要とするかを具体的に指定する必要があります。これを行うには、アプリでに Office 365 Management API へのアクセスを追加して、必要なアクセス許可を指定します。

Azure portal で、[アプリの登録]、>[すべてのアプリケーション] の順に移動し、アプリケーションを選択してから、左側のウィンドウで [API アクセス許可] (1) を選択します。 [アクセス許可の追加] (2) をクリックして、[API アクセス許可の要求] (3) ポップアップページを表示します。
[Microsoft API] タブで、[Office 365 管理 API] (4) を選択します。
ポップアップページで、アプリで必要な次の種類のアクセス許可 (3) を選択し、[アクセス許可の追加] をクリックします。
1. 委任されたアクセス許可。クライアントアプリで、サインインしているユーザーに代わって、メールの読み取りやユーザーのプロファイルの変更などの操作を実行できるようにします。
2. アプリケーションのアクセス許可。バックグラウンドサービスやデーモンアプリで使用されるアプリなど、ユーザーとの対話や同意なしにクライアントアプリ自身が認証できるようにするアクセス許可。
Office Management API が、アプリでアクセス許可が必要なアプリケーションの一覧に表示されるようになりました。 [ アプリケーションのアクセス許可] と [ 委任されたアクセス許可] の両方で、必要に応じてアプリケーションに必要なアクセス許可を選択します。各アクセス許可の詳細については、それぞれ特定の API リファレンスを参照してください。
["テナント名" に管理者の同意を与える] を選択して、アプリに与えられたアクセス許可に同意します。

アプリケーションに Office 365 Management API を使用するために必要なアクセス許可が構成されたため、テナント管理者は、アプリケーションが API を使用してテナントのデータにアクセスするために、これらのアクセス許可を明示的に与える必要があります。同意を与えるには、テナント管理者が、次に示す特別に作成された URL を使用して、Azure AD にサインインする必要があります。この URL では、アプリケーションの要求したアクセス許可を確認することができます。自分が所有するテナントのデータにアクセスするために API を使用する場合、この手順は必要ではありません。

https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id={your_client_id}&redirect_uri={your_redirect_url }

リダイレクト URL は、Azure AD でアプリケーション用に構成された応答 URL のいずれかと一致するか、サブパスである必要があります。

次に例を示します。

https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id=2d4d11a2-f814-46a7-890a-274a72a7309e&redirect_uri=http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F

同意 URL をテストするには、その URL をブラウザーに貼り付けて、アプリケーションの登録に使用したテナント以外のテナントの Office 365 管理者の資格情報を使用してサインインします。 Office Management API を使用するために必要なアプリケーションのアクセス許可を付与する要求が表示されます。

アクセス許可の同意ページ

[承諾] を選択すると、指定のページにリダイレクトされます。ページにはクエリ文字列でコードが記載されています。

次に例を示します。

http://www.mycompany.com/myapp/?code=AAABAAAAvPM1KaPlrEqdFSB...

アプリケーションは、この認証コードを使用して Azure AD からアクセストークンを取得します。そのトークンからテナント ID を抽出できます。テナント ID を抽出して格納すると、テナント管理者のサインインを必要とすることなく、その後のアクセストークンを取得できます。

Azure AD からアクセストークンを要求する

Azure AD からアクセストークンを要求する方法は 2 つです。

承認コード付与フローには、明示的な同意を付与するテナント管理者が含まれます。これにより、承認コードがアプリケーションに返されます。その後、アプリケーションは承認コードをアクセストークンと交換します。このメソッドは、アプリケーションが API を使用してテナントデータにアクセスする必要があることを最初に同意するために必要であり、テナント ID を取得して格納するには、この最初のアクセストークンが必要です。
クライアント資格情報の許可フローでは、古いアクセストークンが期限切れになったときに、テナント管理者がサインインして同意を明示的に与える必要なしで、アプリケーションは以降のアクセストークンを要求できるようになります。このメソッドは、初期テナント管理者の同意が与えられた後、API を呼び出すバックグラウンドで継続的に実行するアプリケーションで使用する必要があります。

承認コードを使用してアクセストークンを要求する

テナント管理者が同意を与えると、テナント管理者が Azure AD によって指定の URL にリダイレクトされるときに、アプリケーションはクエリ文字列パラメーターとして認証コードを受け取ります。

http://www.mycompany.com/myapp/?code=AAABAAAAvPM1KaPlrEqdFSB...

アプリケーションはアクセストークンの認証コードを交換するために Azure AD に HTTP REST POST を実行します。テナント ID がまだ不明であるため、POST は「共通」のエンドポイントに送られます。このエンドポイントの URL にはテナント ID が埋め込まれていません。

https://login.windows.net/common/oauth2/token

POST の本文には、次の記述が含まれています。

resource=https%3A%2F%2Fmanage.office.com&amp;client_id=a6099727-6b7b-482c-b509-1df309acc563 &amp;redirect_uri= http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F &amp;client_secret={your_client_key}&amp;grant_type=authorization_code&amp;code= AAABAAAAvPM1KaPlrEqdFSB...

要求の例

POST https://login.windows.net/common/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: login.windows.net
Content-Length: 944

resource=https%3A%2F%2Fmanage.office.com&amp;client_id=a6099727-6b7b-482c-b509-1df309acc563 &amp;redirect_uri= http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F &amp;client_secret={your_client_key}&amp;grant_type=authorization_code&amp;code=AAABAAAAvPM1KaPlrEqdFSB...

アクセストークンを含むいくつかのプロパティには、応答の本文が含まれます。

応答例

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 3265

{"expires_in":"3599","token_type":"Bearer","scope":"ActivityFeed.Read ActivityReports.Read ServiceHealth.Read","expires_on":"1438290275","not_before":"1438286375","resource":"https://manage.office.com","access_token":"eyJ0eX...","refresh_token":"AAABAAA...","id_token":"eyJ0eXAi..."}

返されるアクセストークンは、同意とアクセスを要求するアプリケーションの両方に関する情報が含まれる JWT トークンです。エンコードされていないトークンの例を次に示します。アプリケーションは、このトークンからテナント ID「tid」を抽出し、期限切れの際に管理者のさらなる介入なしに追加のアクセストークンを要求するために使用できるよう、保存する必要があります。

トークンの例

{
  "aud": "https://manage.office.com",
  "iss": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "iat": 1427246416,
  "nbf": 1427246416,
  "exp": 1427250316,
  "ver": "1.0",
  "tid": "41463f53-8812-40f4-890f-865bf6e35190",
  "amr": [
    "pwd"
  ],
  "oid": "1cef1fdb-ff52-48c4-8e4e-dfb5ea83d357",
  "upn": "admin@contoso.onmicrosoft.com",
  "puid": "1003BFFD8EC47CA6",
  "sub": "7XpD5OWAXM1OWmKiVKh1FOkKXV4N3OSRol6mz1pxxhU",
  "given_name": "John",
  "family_name": "Doe",
  "name": "Contoso, Inc.",
  "unique_name": "admin@contoso.onmicrosoft.com",
  "appid": "a6099727-6b7b-482c-b509-1df309acc563",
  "appidacr": "1",
  "scp": "ActivityFeed.Read ServiceHealth.Read",
  "acr": "1"
}

クライアントの資格情報を使用してアクセストークンを要求する

テナント ID が判明すると、アプリケーションは、Azure AD にサービス間の呼び出しを行い、期限切れの際に追加のアクセストークンを要求することができます。これらのトークンには、同意を許可した管理者ではなく、要求元のアプリケーションについてのみ情報が含まれます。サービス間の呼び出しでは、アプリケーションが X.509 証明書を使用して、base64 でエンコードされ、SHA256 で署名されている JWT ベアラートークンの形式でクライアントのアサーションを作成する必要があります。

.NET でアプリケーションを開発するときには、Microsoft Authentication Library (MSAL) を使用してクライアントのアサーションを作成できます。他の開発プラットフォームにも同様のライブラリが必要です。

エンコードされていない JWT トークンは、次のプロパティを持つヘッダーとペイロードで構成されます。

HEADER:

{
  "alg": "RS256",
  "x5t": "{thumbprint of your X.509 certificate used to sign the token",
}

PAYLOAD:

{
  "aud": "https://login.windows.net/{tenantid}/oauth2/token",
  "iss": "{your app client ID}",
  "sub": "{your app client ID}",
  "jti": "{random GUID}",
  "nbf": "{epoch time, before which the token is not valid}",
  "exp": "{epoch time, after which the token is not valid}"
}

JWT トークンの例

HEADER:

{
  "alg": "RS256",
  "x5t": "YyfshJC3rPQ-kpGo5dUaiY5t3iU",
}

PAYLOAD:

{
  "aud": "https://login.windows.net/41463f53-8812-40f4-890f-865bf6e35190/oauth2/token",
  "iss": "a6099727-6b7b-482c-b509-1df309acc563",
  "sub": "a6099727-6b7b-482c-b509-1df309acc563",
  "jti": "0ce254c4-81b1-4a2e-8436-9a8c3b49dfb9",
  "nbf": 1427248048,
  "exp": 1427248648,
}

その後、クライアントアサーションは、サービス間呼び出しの一部として Azure AD に渡され、アクセストークンを要求します。クライアント資格情報を使用してアクセストークンを要求する場合は、テナント固有のエンドポイントへの HTTP POST を使用します。ここで、以前に抽出および格納されたテナント ID が URL に埋め込まれています。

https://login.windows.net/{tenantid}/oauth2/token

POST の本文には、次の記述が含まれています。

resource=https%3A%2F%2Fmanage.office.com&amp;client_id={your_app_client_id}&amp;grant_type=client_credentials&amp;client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&amp;client_assertion={encoded_signed_JWT_token}

要求の例

POST https://login.windows.net/41463f53-8812-40f4-890f-865bf6e35190/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: login.windows.net
Content-Length: 994

resource=https%3A%2F%2Fmanage.office.com&amp;client_id= a6099727-6b7b-482c-b509-1df309acc563&amp;grant_type=client_credentials &amp;client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&amp;client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Ill5ZnNoSkMzclBRLWtwR281ZFVhaVk1dDNpVSJ9.eyJhdWQiOiJodHRwczpcL1wvbG9naW4ud2luZG93cy5uZXRcLzQxNDYzZjUzLTg4MTItNDBmNC04OTBmLTg2NWJmNmUzNTE5MFwvb2F1dGgyXC90b2tlbiIsImV4cCI6MTQyNzI0ODY0OCwiaXNzIjoiYTYwOTk3MjctNmI3Yi00ODJjLWI1MDktMWRmMzA5YWNjNTYzIiwianRpIjoiMGNlMjU0YzQtODFiMS00YTJlLTg0MzYtOWE4YzNiNDlkZmI5IiwibmJmIjoxNDI3MjQ4MDQ4LCJzdWIiOiJhNjA5OTcyNy02YjdiLTQ4MmMtYjUwOS0xZGYzMDlhY2M1NjMifQ.vfDrmCjiXgoj2JrTkwyOpr-NOeQTzlXQcGlKGNpLLe0oh4Zvjdcim5C7E0UbI3Z2yb9uKQdx9G7GeqS-gVc9kNV_XSSNP4wEQj3iYNKpf_JD2ikUVIWBkOg41BiTuknRJAYOMjiuBE2a6Wyk-vPCs_JMd7Sr-N3LiNZ-TjluuVzWHfok_HWz_wH8AzdoMF3S0HtrjNd9Ld5eI7MVMt4OTpRfh-Syofi7Ow0HN07nKT5FYeC_ThBpGiIoODnMQQtDA2tM7D3D6OlLQRgLfI8ir73PVXWL7V7Zj2RcOiooIeXx38dvuSwYreJYtdphmrDBZ2ehqtduzUZhaHL1iDvLlw

応答は前と同じになりますが、トークンは同じプロパティを持ちません。同意を許可する管理者のプロパティが含まれていないためです。

応答例

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 1276

{"token_type":"Bearer","expires_in":"3599","expires_on":"1431659094","not_before":"1431655194","resource":"https://manage.office.com","access_token":"eyJ0eXAiOiJKV1QiL..."}

アクセストークンの例

{
  "aud": "https://manage.office.com",
  "iss": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "iat": 1431655194,
  "nbf": 1431655194,
  "exp": 1431659094,
  "ver": "1.0",
  "tid": "41463f53-8812-40f4-890f-865bf6e35190",
  "roles": [
    "ServiceHealth.Read",
    "ActivityFeed.Read"
  ],
  "oid": "67cb0334-e242-4783-8028-0f39132fb5ad",
  "sub": "67cb0334-e242-4783-8028-0f39132fb5ad",
  "idp": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "appid": "a6099727-6b7b-482c-b509-1df309acc563",
  "appidacr": "1"
}

アプリを作成する

Azure AD にアプリを登録し、必要なアクセス許可で構成したので、アプリをビルドする準備ができました。アプリの設計とビルド時に考慮すべき重要な側面を次に示します。

同意エクスペリエンス。顧客から同意を得るために、前に説明した特別に構築された URL を使用して、ブラウザーで Azure AD Web サイトに誘導する必要があります。また、Azure AD が同意を付与した後に管理者をリダイレクトする Web サイトが必要です。この Web サイトでは、URL から承認コードを抽出し、それを使用して、テナント ID を取得できるアクセストークンを要求する必要があります。
システムにテナント ID を格納する。 Azure AD からアクセストークンを要求するとき、および Office Management API を呼び出すときに必要となります。
アクセストークンを管理します。必要に応じてアクセストークンを要求および管理するコンポーネントが必要です。アプリが API を定期的に呼び出す場合は、必要に応じてトークンを要求できます。また、API を継続的に呼び出してデータを取得する場合は、一定の間隔 (45 分ごとなど) でトークンを要求できます。
Webhook リスナーを実装します。使用している特定の API で必要に応じて。
データを取得し、格納する。使用している特定の API によって、連続的なポーリングを使用して、または Webhook 通知への応答として、各テナントのデータを取得するコンポーネントが必要があります。

Office 365 Management API の使用を開始する

Azure AD でアプリケーションを登録する

前提条件

Azure portal を使用してアプリケーションを Azure AD で登録する

Azure AD でアプリケーションのプロパティを構成する

アプリケーションの新しいキーを生成する

サービス間の呼び出しを有効にする X.509 証明書を構成します。

アプリが Office 365 Management APIにアクセスするために必要な許可を指定します。

Azure AD からアクセストークンを要求する

承認コードを使用してアクセストークンを要求する

要求の例

応答例

トークンの例

クライアントの資格情報を使用してアクセストークンを要求する

JWT トークンの例

要求の例

応答例

アクセストークンの例

アプリを作成する

その他のリソース

その他のリソース

Office 365 Management API の使用を開始する

Azure AD でアプリケーションを登録する

前提条件

Azure portal を使用してアプリケーションを Azure AD で登録する

Azure AD でアプリケーションのプロパティを構成する

アプリケーションの新しいキーを生成する

サービス間の呼び出しを有効にする X.509 証明書を構成します。

アプリが Office 365 Management APIにアクセスするために必要な許可を指定します。

Office 365 テナント管理者の同意を得る

Azure AD からアクセス トークンを要求する

承認コードを使用してアクセス トークンを要求する

要求の例

応答例

トークンの例

クライアントの資格情報を使用してアクセス トークンを要求する

JWT トークンの例

要求の例

応答例

アクセス トークンの例

アプリを作成する

その他のリソース

その他のリソース

Azure AD からアクセストークンを要求する

承認コードを使用してアクセストークンを要求する

クライアントの資格情報を使用してアクセストークンを要求する

アクセストークンの例