Office 365 Management API の使用を開始する
Office 365 Management API と同じようにセキュリティで保護されたサービスへのアクセスを必要とするアプリケーションを作成するときは、アプリケーションがサービスへのアクセス権を保持しているかを確認する方法をサービスに提供する必要があります。 Office 365管理 API は、Microsoft Entra IDを使用して、アプリケーションにアクセスする権限を付与するために使用できる認証サービスを提供します。
以下の 4 つの手順があります。
アプリケーションをMicrosoft Entra IDに登録します。 アプリケーションがOffice 365管理 API にアクセスできるようにするには、アプリケーションをMicrosoft Entra IDに登録する必要があります。 これにより、アプリケーションの ID を設定し、API にアクセスするために必要なアクセス許可レベルを指定することができます。
Office 365 テナント管理者の同意を得る。 Office 365 Management API を使用してアプリケーションがテナントのデータにアクセスする許可への同意を、Office 365 テナント管理者が明示的に付与する必要があります。 同意プロセスはブラウザーベースのエクスペリエンスであり、テナント管理者はMicrosoft Entra同意 UI にサインインし、アプリケーションが要求しているアクセス許可を確認してから、要求を許可または拒否する必要があります。 同意が与えられると、UI は認証コードを含めた URL を使用してユーザーをアプリケーションにリダイレクトします。 アプリケーションは、Microsoft Entra IDに対してサービス間呼び出しを行い、この承認コードをアクセス トークンと交換します。これには、テナント管理者とアプリケーションの両方に関する情報が含まれています。 テナント ID はアクセス トークンから抽出され、将来使用するために格納される必要があります。
Microsoft Entra IDからアクセス トークンを要求します。 アプリケーションは、Microsoft Entra IDで構成されているアプリケーションの資格情報を使用して、同意されたテナントに対して追加のアクセス トークンを継続的に要求します。テナント管理者の操作を追加する必要はありません。 これらのアクセス トークンはテナント管理者に関する情報が含まれていないため、アプリ専用トークンと呼ばれます。
Office 365 Management API の呼び出し。 アプリケーションを認証して承認するため、アプリ専用アクセス トークンが Office 365 Management API に渡されます。
次の図は、同意とアクセス トークンの要求のシーケンスを示しています。
重要
Office 365 管理アクティビティ API を介してデータにアクセスする前に、Office 365 組織の統合監査ログを有効にする必要があります。 これを実行するには、Office 365 監査ログをオンにします。 手順については、「Office 365 監査ログの検索を有効または無効にする」を参照してください。
Office 365 サービス通信 API のみを使用している場合は、統合監査ログを有効にする必要はありません。
アプリケーションをMicrosoft Entra IDに登録する
Office 365管理 API では、Microsoft Entra IDを使用して、テナント データをOffice 365するためのセキュリティで保護された認証を提供します。 Office 365管理 API にアクセスするには、アプリをMicrosoft Entra IDに登録する必要があります。構成の一環として、アプリが API にアクセスするために必要なアクセス許可レベルを指定します。
前提条件
Microsoft Entra IDでアプリを登録するには、Office 365するサブスクリプションと、Office 365 サブスクリプションに関連付けられている Azure へのサブスクリプションが必要です。 開始するには、Office 365 と Azure の両方に、試用版のサブスクリプションを使用できます。 詳細については、Office 365 開発者プログラムへようこそを参照してください。
Azure Portal を使用してアプリケーションをMicrosoft Entra IDに登録する
適切なサブスクリプションを持つ Microsoft テナントを作成したら、アプリケーションをMicrosoft Entra IDに登録できます。
使用するサブスクリプションを持つ Microsoft テナントの資格情報を使用して、Azure portalにサインインOffice 365。 Microsoft 365 管理センターの左側のナビゲーション ウィンドウに表示されるリンクを使用して、Azure Portal にアクセスすることもできます。
左側のナビゲーション ウィンドウで、[Microsoft Entra ID (1)] を選択します。
[Microsoft Entra ID] ページで、[アプリの登録 (2)] を選択し、[新しい登録 (3)] を選択します。
[アプリの登録] ページで、[新規登録] を選択します。
アプリの登録を開始する新しいページが表示されます。
[アプリケーションの登録] ページで、次の操作を行います。
アプリに名前を付けます。
アプリを使用し、API にアクセスできるユーザーを選択します。
必要に応じて、認証後のユーザー リダイレクト用リダイレクト URL を指定します。
[登録] をクリックして、新しいアプリを登録します。
Microsoft Entra IDでアプリケーションのプロパティを構成する
アプリケーションが登録されたので、Microsoft Entra ID内のアプリケーションの機能を決定し、テナント管理者が Office 365 Management API を使用してアプリケーションがデータにアクセスできるようにする同意を付与する方法を指定する必要がある重要なプロパティがいくつかあります。
一般的なアプリケーション構成Microsoft Entra詳細については、「アプリケーション オブジェクトのプロパティ」を参照してください。
クライアント ID。 この値は、Microsoft Entra IDによって自動的に生成されます。 アプリケーションは、テナント管理者に同意を要求するとき、およびアプリ専用トークンをMicrosoft Entra IDに要求するときに、この値を使用します。
アプリケーションはマルチテナントです。 テナント管理者が Office 365 Management API を使用してアプリケーションにテナント データへのアクセス許可に同意するには、このプロパティは [はい] に設定する必要があります。 このプロパティが [いいえ] に設定されている場合、アプリケーションは、独自のテナント データにしかアクセスすることはできません。
応答 URL。 これは、Office 365 Management API を使用してアプリケーションのデータへのアクセス許可に同意した後にテナント管理者がリダイレクトされる URL です。 必要に応じて、複数の応答 URL を設定できます。 Azure は、アプリケーションを作成する際、指定したサインオン URL に最初に一致した URL を自動的に設定しますが、必要に応じてこの値を変更することができます。
これらのプロパティを変更した後は、必ず [保存] をクリックしてください。
アプリケーションの新しいキーを生成する
キー (クライアント シークレットとも呼ばれます) は、アクセス トークンの認証コードを交換するときに使用されます。
Azure portalの [Microsoft Entra ID] ページで、[アプリの登録] を選択し、アプリケーションを選択します。
アプリのページが表示された後、左側のウィンドウで [証明書とシークレット] (1) を選択します。 このページでは、証明書をアップロードし、新しいクライアント シークレット (2) を作成できます。
[証明書とシークレット] (1) ページで、[新しいクライアント シークレット] (2) を選択し、説明を入力してキー (3) の期間を選択し、[追加] (4) を選択します。
クライアント シークレットの作成後、値が [クライアント シークレット] (2) の下に表示されます。 クリップボード アイコン (3) をクリックし、クライアント シークレット値をクリップボードにコピーします。
重要
クライアント シークレット値は、最初に生成したときにだけ、Azure に表示されます。 後でこのページに戻ってクライアント シークレット値を取得することはできません。 後で使用できるよう、必ずコピーして安全な場所に保存してください。
サービス間の呼び出しを有効にする X.509 証明書を構成します。
デーモンやサービスなど、バックグラウンドで実行されているアプリケーションは、最初の同意が与えられた後、繰り返しテナント管理者に同意を求めることがなく、アプリ専用アクセス トークン要求にクライアントの資格情報を使用できます。
詳細については、「クライアント資格情報を使用したサービス間の呼び出し」を参照してください。
Microsoft Entra IDからアプリ専用アクセス トークンを要求するときにクライアント資格情報として使用されるように、アプリケーションで 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
) にエクスポートします。 アプリケーションでは、この証明書を使用してMicrosoft Entra IDと通信するため、秘密キーへのアクセスも保持してください。注:
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 を使用して、Microsoft Entra IDでアプリケーション マニフェストを更新する必要があります。
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) を選択し、[アクセス許可の追加] をクリックします。
委任されたアクセス許可。 クライアント アプリで、サインインしているユーザーに代わって、メールの読み取りやユーザーのプロファイルの変更などの操作を実行できるようにします。
アプリケーションのアクセス許可。 バックグラウンド サービスやデーモン アプリで使用されるアプリなど、ユーザーとの対話や同意なしにクライアント アプリ自身が認証できるようにするアクセス許可。
Office Management API が、アプリでアクセス許可が必要なアプリケーションの一覧に表示されるようになりました。 [ アプリケーションのアクセス許可] と [ 委任されたアクセス許可] の両方で、必要に応じてアプリケーションに必要なアクセス許可を選択します。 各アクセス許可の詳細については、それぞれ特定の API リファレンスを参照してください。
["テナント名" に管理者の同意を与える] を選択して、アプリに与えられたアクセス許可に同意します。
Office 365 テナント管理者の同意を得る
アプリケーションに Office 365 Management API を使用するために必要なアクセス許可が構成されたため、テナント管理者は、アプリケーションが API を使用してテナントのデータにアクセスするために、これらのアクセス許可を明示的に与える必要があります。 同意を付与するには、テナント管理者は、次の特別に構築された URL を使用してMicrosoft Entra IDにサインインする必要があります。ここで、アプリケーションの要求されたアクセス許可を確認できます。 自分が所有するテナントのデータにアクセスするために 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 は、Microsoft Entra IDでアプリケーション用に構成された応答 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...
アプリケーションでは、この承認コードを使用して、テナント ID を抽出できるMicrosoft Entra IDからアクセス トークンを取得します。 テナント ID を抽出して格納すると、テナント管理者のサインインを必要とすることなく、その後のアクセス トークンを取得できます。
Microsoft Entra IDからアクセス トークンを要求する
Microsoft Entra IDからアクセス トークンを要求する方法は 2 つあります。
承認コード付与フローには、明示的な同意を付与するテナント管理者が含まれます。これにより、承認コードがアプリケーションに返されます。 その後、アプリケーションは承認コードをアクセス トークンと交換します。 このメソッドは、アプリケーションが API を使用してテナント データにアクセスする必要があることを最初に同意するために必要であり、テナント ID を取得して格納するには、この最初のアクセス トークンが必要です。
クライアント資格情報の許可フローでは、古いアクセス トークンが期限切れになったときに、テナント管理者がサインインして同意を明示的に与える必要なしで、アプリケーションは以降のアクセス トークンを要求できるようになります。 このメソッドは、初期テナント管理者の同意が与えられた後、API を呼び出すバックグラウンドで継続的に実行するアプリケーションで使用する必要があります。
承認コードを使用してアクセス トークンを要求する
テナント管理者が同意を許可すると、アプリケーションは、テナント管理者を指定された URL にリダイレクトMicrosoft Entra ID、クエリ文字列パラメーターとして承認コードを受け取ります。
http://www.mycompany.com/myapp/?code=AAABAAAAvPM1KaPlrEqdFSB...
アプリケーションは HTTP REST POST を作成してMicrosoft Entra IDし、アクセス トークンの承認コードを交換します。 テナント ID がまだ不明であるため、POST は「共通」のエンドポイントに送られます。このエンドポイントの URL にはテナント ID が埋め込まれていません。
https://login.windows.net/common/oauth2/token
POST の本文には、次の記述が含まれています。
resource=https%3A%2F%2Fmanage.office.com&client_id=a6099727-6b7b-482c-b509-1df309acc563 &redirect_uri= http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F &client_secret={your_client_key}&grant_type=authorization_code&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&client_id=a6099727-6b7b-482c-b509-1df309acc563 &redirect_uri= http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F &client_secret={your_client_key}&grant_type=authorization_code&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 がわかったら、アプリケーションでサービス間呼び出しを行ってMicrosoft Entra IDに対してサービス間の呼び出しを行い、有効期限が切れると追加のアクセス トークンを要求できます。 これらのトークンには、同意を許可した管理者ではなく、要求元のアプリケーションについてのみ情報が含まれます。 サービス間の呼び出しでは、アプリケーションが 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,
}
クライアント アサーションは、サービス間呼び出しの一部としてMicrosoft Entra IDに渡され、アクセス トークンを要求します。 クライアント資格情報を使用してアクセス トークンを要求する場合は、テナント固有のエンドポイントへの HTTP POST を使用します。ここで、以前に抽出および格納されたテナント ID が URL に埋め込まれています。
https://login.windows.net/{tenantid}/oauth2/token
POST の本文には、次の記述が含まれています。
resource=https%3A%2F%2Fmanage.office.com&client_id={your_app_client_id}&grant_type=client_credentials&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&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&client_id= a6099727-6b7b-482c-b509-1df309acc563&grant_type=client_credentials &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&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"
}
アプリを作成する
アプリをMicrosoft Entra IDに登録し、必要なアクセス許可で構成したので、アプリをビルドする準備ができました。 アプリの設計とビルド時に考慮すべき重要な側面を次に示します。
同意エクスペリエンス。 顧客から同意を得るために、ブラウザーで前に説明した特別に構築された URL を使用して、Microsoft Entra Web サイトに誘導する必要があります。また、管理者が同意を与えた後Microsoft Entra IDリダイレクトする Web サイトが必要です。 この Web サイトでは、URL から承認コードを抽出し、それを使用して、テナント ID を取得できるアクセス トークンを要求する必要があります。
システムにテナント ID を格納する。 これは、Microsoft Entra IDからアクセス トークンを要求するとき、および Office Management API を呼び出すときに必要になります。
アクセス トークンを管理します。 必要に応じてアクセス トークンを要求および管理するコンポーネントが必要です。 アプリが API を定期的に呼び出す場合は、必要に応じてトークンを要求できます。また、API を継続的に呼び出してデータを取得する場合は、一定の間隔 (45 分ごとなど) でトークンを要求できます。
Webhook リスナーを実装します。 使用している特定の API で必要に応じて。
データを取得し、格納する。 使用している特定の API によって、連続的なポーリングを使用して、または Webhook 通知への応答として、各テナントのデータを取得するコンポーネントが必要があります。