Microsoft 身分識別平台最佳做法和建議 (部分機器翻譯)
本文重點說明與 Microsoft 身分識別平台整合時的最佳做法、建議和常見疏忽。 這份檢查清單會引導您進行高品質且安全的整合。 定期檢閱這份清單，以確保您保有應用程式與身分識別平台整合的品質和安全性。 檢查清單不適合用來檢閱整個應用程式。 當我們對平台進行改善時，檢查清單的內容可能會變更。
如果您剛開始使用，請參閱 Microsoft 身分識別平台文件，以了解驗證基本資料、Microsoft 身分識別平台中的應用程式案例等等。
使用下列檢查清單，以確保您的應用程式能夠有效地與 Microsoft 身分識別平台整合。
提示
[整合小幫手] 可協助您套用許多最佳做法和建議。 選取您的任何應用程式註冊，然後選取 [整合小幫手] 功能表項目以開始使用小幫手。
基本概念
閱讀並了解 Microsoft 平台原則。 確定應用程式符合所述的條款，因為其是為保護使用者和平台所設計。
擁有權
確定與您用來註冊和管理應用程式的帳戶相關聯的資訊是最新的。
商標
遵守應用程式的商標方針。
為您的應用程式提供有意義的名稱和標誌。 此資訊會出現在應用程式同意提示中。 確定您的名稱和標誌都代表您的公司/產品，讓使用者能夠做出明智的決策。 確定您未違反任何商標。
隱私權
提供您應用程式的服務條款與隱私權聲明連結。
安全性
管理您的重新導向 URI：
- 維持所有重新導向 URI 的擁有權，並將其 DNS 記錄維持在最新狀態。
- 請勿在您的 URI 中使用萬用字元 (*)。
- 針對 Web 應用程式，請確定所有 URI 都是安全的且經過加密 (例如，使用 https 配置)。
- 若為公用用戶端，在適用的情況下使用平台特定的重新導向 URI (主要適用於 iOS 和 Android)。 否則，請使用具有大量隨機性的重新導向 URI，以防止在向應用程式回呼時發生衝突。
- 如果應用程式的使用是透過隔離的 Web 代理程式進行，您可以使用
https://login.microsoftonline.com/common/oauth2/nativeclient。 - 請定期檢閱並修剪所有未使用或不必要的重新導向 URI。
如果應用程式已在目錄中註冊，請將應用程式註冊擁有者清單縮至最小，並手動監視。
除非明確要求，否則請不要啟用 OAuth2 隱含授與流程的支援。 您將在這裡瞭解有效的情節。
超越使用者名稱/密碼。 請不要使用資源擁有者密碼認證流程 (ROPC)，此流程會直接處理使用者的密碼。 此流程需要高度的信任和使用者暴露，而且應只在其他更安全的流程無法使用時，才使用此流程。 在某些情節中，仍然需要此流程 (例如 DevOps)，但請注意，使用它會對您的應用程式施加限制式。 針對更現代化的方法，請閱讀驗證流程和應用程式情節。
保護和管理 Web 應用程式、Web API 和精靈應用程式的機密應用程式認證。 請使用憑證認證，而非密碼認證 (用戶端密碼)。 如果您必須使用密碼認證，請不要進行手動設定。 請勿將認證儲存在程式碼或設定中，也不允許人工處理這些項目。 可能的話，請使用適用於 Azure 資源的受控識別或 Azure Key Vault 來儲存和定期輪替認證。
確保您的應用程式要求的是最低的權限。 只要求您的應用程式絕對需要的權限，而且只在需要時才要求。 瞭解不同類型的權限。 只有在必要時才使用應用程式權限；可能的話，請使用委派的權限。 如需 Microsoft Graph 權限的完整清單，請參閱此權限參考。
如果您要使用 Microsoft 身分識別平台來保護 API，請仔細思考其應該公開的權限。 請考慮您解決方案的正確細微性，以及哪些權限需要管理員同意。 進行任何授權決策之前，請先查看傳入權杖中是否有應有的權限。
實作
使用新式驗證解決方案 (OAuth 2.0、OpenID Connect)，以安全的方式登入使用者。
請不要直接針對 OAuth 2.0 和 Open ID 等通訊協定進行程式設計。 反之，利用 Microsoft 驗證程式庫 (MSAL)。 MSAL 程式庫會安全地將安全性通訊協定包裝在容易使用的程式庫中，您可以取得條件式存取情節的內建支援、全裝置單一登入 (SSO)，以及內建的權杖快取支援。 如需詳細資訊，請參閱 Microsoft 支援的用戶端程式庫清單。 如果您必須手動編寫驗證通訊協定的程式碼，則應遵循 Microsoft SDL 或類似的開發方法。 請密切注意每個通訊協定的標準規格中的安全性考量。
請勿查看存取令牌值，或嘗試將它剖析為用戶端。 他們可以變更值、格式，甚至在沒有警告的情況下進行加密；如果您的用戶端需要了解使用者的相關資訊，請一律使用識別碼權杖。 只有 Web API 可以剖析存取權杖 (因為其是定義格式及設定加密金鑰的權杖)。 用戶端直接將存取權杖傳送至 API 是一種安全性風險，因為其是授與特定資源存取權的敏感性認證。 開發人員不應該假設可以信任用戶端來驗證存取權杖。
將現有應用程式從 Azure Active Directory 驗證程式庫 (ADAL) 移轉至 Microsoft 驗證程式庫。 MSAL 是 Microsoft 最新的身分識別平台解決方案，並且可在 .NET、JavaScript、Android、iOS、macOS、Python 和 Java 上使用。 深入瞭解如何移轉 ADAL.NET、ADAL.js和 ADAL.NET 和 iOS 訊息代理程式應用程式。
針對行動應用程式，使用應用程式註冊體驗設定每個平台。 為了讓應用程式能夠利用 Microsoft Authenticator 或 Microsoft 公司入口網站進行單一登入，應用程式需要設定「訊息代理程式重新導向 URI」。 這可讓 Microsoft 在驗證之後將控制權交還給應用程式。 設定每個平台時，應用程式註冊體驗將引導您完成此程序。 使用快速入門下載可運作的範例。 在 iOS 上，請盡可能使用訊息代理程式和系統 Web 檢視。
在 Web 應用程式或 Web API 中，每個帳戶都保留一個權杖快取。 針對 Web 應用程式，權杖快取應以帳戶識別碼作為索引鍵。 對於 Web API 而言，該帳戶應要以用於呼叫該 API 的權杖雜湊作為索引鍵。 MSAL.NET 在 .NET 和 .NET Framework 中提供自訂權杖快取序列化。 基於安全性和效能的考量，建議您為每個使用者序列化一個快取。 如需詳細資訊，請參閱權杖快取序列化。
如果應用程式所需的資料可以透過 Microsoft Graph 取得，請使用 Microsoft Graph 端點 (而非個別 API) 來要求此資料的權限。
終端使用者體驗
瞭解同意體驗，並設定應用程式的同意提示片段，讓使用者和系統管理員有足夠的資訊來判斷他們是否信任您的應用程式。
在互動式流程之前嘗試無訊息驗證 (取得無訊息權杖)，以將使用者在使用您應用程式時需要輸入登入認證的次數降至最小。
請不要將 "prompt=consent" 用於每次登入。 只有在您已確定需要要求其他權限的同意時，才能使用 prompt=consent (例如，您已變更應用程式必要權限的情況下)。
在適用的情況下，以使用者資料來擴充應用程式。 使用 Microsoft Graph API 是簡單的做法。 可協助您開始使用的 Graph Explorer 工具。
註冊您的應用程式所需的一組完整權限，讓管理員可以輕鬆地將同意授與其租用戶。 在執行時間使用增量同意，以協助使用者瞭解應用程式為何要求權限，在第一次啟動時要求這些權限可能會使使用者感到擔憂或混淆。
實作全新的單一登出體驗。 其是一種隱私權和安全性需求，可提供更好的使用者體驗。
測試
測試是否有條件式存取原則可能影響使用者使用應用程式的能力。
請使用您打算要支援的所有可能帳戶來測試您的應用程式 (例如，公司或學校帳戶、個人 Microsoft 帳戶、子女帳戶和主權帳戶)。
其他資源
探索有關 v2.0 的深入資訊：