將最佳做法套用至 Microsoft Graph

  • 3 分鐘

本單元說明您可套用的最佳做法，以充分利用 Microsoft Graph，並且讓您的應用程式對終端使用者而言更加可靠。

驗證

若要存取 Microsoft Graph 中的資料，您的應用程式需要取得 OAuth 2.0 存取權杖，並在下列任一方法中將它呈現給 Microsoft Graph:

  • HTTP 授權要求標頭，作為持有人權杖
  • 使用 Microsoft Graph 用戶端程式庫時的圖形用戶端建構函式

使用 Microsoft 驗證程式庫 API (MSAL) 來取得 Microsoft Graph 的存取權杖。

在應用程式中套用同意和授權的下列最佳做法：

  • 使用最低權限。 只有必要的要求權限，而且只有在您需要權限時。 針對應用程式呼叫的 API，檢查方法主題中的權限一節。 例如，請參閱建立使用者並選擇最低特殊權限。

  • 根據案例使用正確的權限類型。 如果您要建置已有使用者登入的互動式應用程式，您的應用程式應使用委派的權限。 不過，如果您的應用程式在沒有使用者登入的情況下執行 (例如背景服務或精靈)，您的應用程式應使用應用程式權限。

    警告

    針對互動式案例使用應用程式權限，可能讓應用程式面臨合規性和安全性風險。 務必檢查使用者的權限，以確保他們沒有不想要的資訊存取權，或正避開系統管理員所設定的原則。

  • 請考慮終端使用者和系統管理員體驗。 直接影響終端使用者和系統管理員體驗。 例如：

  • 考慮多租用戶應用程式。 預期客戶在不同的狀態中具有各種應用程式和同意控制項。 例如：

    • 租用戶系統管理員可以停用終端使用者對應用程式行使同意權的能力。 在此情況下，系統管理員必須代表其使用者同意。

    • 租用戶系統管理員可以設定自訂授權原則，例如阻止使用者讀取其他使用者的設定檔，或將自助式群組建立限制為一組有限的使用者。 在此情況下，您的應用程式應該會在代表使用者採取行動時處理 403 錯誤回應。

有效地處理回應

根據您對 Microsoft Graph 提出的要求，您的應用程式應準備好處理不同類型的回應。 以下是一些要遵循的最重要做法，可確保您的應用程式可靠地且可預測地為終端使用者運作。 例如：

  • 分頁:查詢資源集合時，您應該預期由於伺服器端頁面大小限制，Microsoft Graph 會傳回多個頁面的結果集。 您的應用程式應一律處理回應本質上分頁的可能性，並使用 @odata.nextLink 屬性來取得下一個分頁的結果集，直到讀取結果集的所有頁面為止。 最後一頁不包含 @odata.nextLink 屬性。 如需詳細資訊，請瀏覽分頁。

  • 可演進的列舉：將成員新增至現有的列舉可能會中斷已使用這些列舉的應用程式。 可演進的列舉是 Microsoft Graph API 用於將新成員新增至現有列舉的機制，並不會對應用程式造成重大變更。 根據預設，GET 作業只會傳回可演進列舉類型屬性的已知成員，而您的應用程式只需要處理已知的成員。 如果您也將應用程式設計為處理未知的成員，您可以選擇使用 HTTP Prefer 要求標頭來接收這些成員。

將資料儲存在本機

您的應用程式在理想情況下應該呼叫 Microsoft Graph，視需要即時擷取資料。 您應該只在本機快取或儲存特定案例所需的資料。 如果您的使用規定和隱私策略涵蓋該使用案例，而且不會違反 Microsoft API 使用規定，您的應用程式也應該實作適當的保留和刪除原則。