提高您開發的用戶端應用程式中，驗證和授權的復原能力

了解如何在用戶端應用程式中使用 Microsoft 身分識別平台和 Microsoft Entra ID 登入使用者，並代表這些使用者執行動作，藉此建立復原能力。

使用 Microsoft 驗證程式庫 (MSAL)

Microsoft 驗證程式庫 (MSAL) 是 Microsoft 身分識別平台的一部分。 MSAL 會取得、管理、快取及重新整理權杖，並採用支援復原能力的最佳做法。 MSAL 可協助開發人員建立安全的解決方案。

深入了解：

• Microsoft 驗證程式庫概觀
• 什麼是 Microsoft 身分識別平台？
• Microsoft 身分識別平台文件

MSAL 會快取權杖，並使用無聲的權杖取得模式。 在原生提供通用 Windows 平台(UWP)、iOS 和 Android 等安全儲存體的作業系統上，MSAL 會將權杖快取序列化。 當您使用下列項目時，請自訂序列化行為：

• Microsoft.Identity.Web
• MSAL.NET
• 適用於 Java 的 MSAL
• 適用於 Python 的 MSAL

深入了解：

• 權杖快取序列化

• MSAL.NET 中的權杖快取序列化 (英文)

• 在適用於 Java 的 MSAL 中將自訂權杖快取序列化

• 在適用於 Python 的 MSAL 中將自訂權杖快取序列化。

  

當您使用 MSAL 時，將可支援權杖快取、重新整理和無聲取得。 使用簡單模式來取得驗證所需的權杖， 並支援多種語言。 在 Microsoft 身分識別平台程式碼範例上尋找程式碼範例。

C#

try
{
    result = await app.AcquireTokenSilent(scopes, account).ExecuteAsync();
}
catch(MsalUiRequiredException ex)
{
    result = await app.AcquireToken(scopes).WithClaims(ex.Claims).ExecuteAsync()
}

JavaScript

return myMSALObj.acquireTokenSilent(request).catch(error => {
    console.warn("silent token acquisition fails. acquiring token using redirect");
    if (error instanceof msal.InteractionRequiredAuthError) {
        // fallback to interaction when silent call fails
        return myMSALObj.acquireTokenPopup(request).then(tokenResponse => {
            console.log(tokenResponse);

            return tokenResponse;
        }).catch(error => {
            console.error(error);
        });
    } else {
        console.warn(error);
    }
});

MSAL 可以重新整理權杖。 當 Microsoft 身分識別平台發出長期權杖時，可以將資訊傳送至用戶端以重新整理權杖 (refresh_in)。 應用程式在舊權杖有效時可執行，但需要較長的時間才能取得另一個權杖。

MSAL 版本

我們建議開發人員建置程序以使用最新的 MSAL 版本，因為驗證是應用程式安全性的一部分。 請針對開發中的連結庫採用此做法，並改善應用程式復原能力。

尋找最新版本和版本資訊：

• microsoft-authentication-library-for-js
• microsoft-authentication-library-for-dotnet
• microsoft-authentication-library-for-python
• microsoft-authentication-library-for-java
• microsoft-authentication-library-for-objc
• microsoft-authentication-library-for-android
• microsoft-identity-web

權杖處理的復原模式

如果您未使用 MSAL，請採用權杖處理的復原模式。 MSAL 連結庫會實作最佳做法。

一般情況下，使用新式驗證的應用程式會呼叫端點來取得驗證使用者的權杖，或授權應用程式來呼叫受保護的 API。 MSAL 會處理驗證並實作模式，以改善復原能力。 如果您未使用 MSAL，請使用本節中的指引來取得最佳做法。 否則，MSAL 會自動實作最佳做法。

快取權杖

請確定應用程式會從 Microsoft 身分識別平台正確快取權杖。 應用程式收到權杖之後，HTTP 回應所含權杖的 expires_in 屬性會指出快取的持續時間，以及重複使用的時間點。 請確認應用程式不會嘗試譯碼 API 存取權杖。

快取的權杖可防止應用程式與 Microsoft 身分識別平台之間產生不必要的流量。 此方法可減少權杖擷取呼叫，讓應用程式更不容易遇到權杖擷取失敗。 快取的權杖可減少應用程式暫停取得權杖的頻率，從而改善應用程式效能。 在權杖存留期內，使用者會在您的應用程式保持已登入狀態。

序列化以及保存權杖

確保應用程式將其權杖快取安全地序列化，以在應用程式執行個體之間保存權杖。 在其存留期內重複使用權杖。 重新整理權杖和存取權杖的核發週期為數個小時。 在此期間，使用者可能會多次啟動您的應用程式。 當應用程式啟動時，確保其尋找有效的存取權或重新整理權杖。 這會增加應用程式復原能力和效能。

深入了解：

• 重新整理存取權杖

• Microsoft 身分識別平台存取權杖

  

請確定持續性權杖儲存體具有與使用者-擁有者或處理序身分識別相關的存取控制和加密。 在許多作業系統上都有認證儲存體功能。

無聲取得權杖

若要驗證使用者或取得呼叫 API 的授權，需要在 Microsoft 身分識別平台中執行多個步驟。 例如，使用者第一次登入時輸入認證，並執行多重要素驗證。 每個步驟都會影響提供服務的資源。 相依性需求最低的最佳使用者體驗是無訊息權杖擷取。

無訊息權杖擷取首先需要應用程式權杖快取的有效權杖。 如果沒有有效的權杖，應用程式會嘗試透過可用的重新整理權杖和權杖端點來取得權杖。 如果兩個選項都無法使用，應用程式會使用 prompt=none 參數取得權杖。 此動作會使用授權端點，但不會向使用者顯示 UI。 在可能的情況下，Microsoft 身分識別平台會提供權杖給應用程式，而不需要使用者互動。 如果沒有方法可產生權杖，則使用者需要手動重新驗證。

注意

一般而言，請確保應用程式不會使用「登入」和「同意」等提示。 這些提示會在不需要互動時，強制使用者進行互動。

回應碼處理

使用下列各節來了解回應碼。

HTTP 429 回應碼

有些錯誤回應會影響復原能力。 如果您的應用程式收到 HTTP 429 回應碼、太多要求，Microsoft 身分識別平台就會對您的要求進行節流。 如果應用程式發出太多要求則會受到節流，而導致應用程式無法接收權杖。 請勿允許應用程式在完成 Retry-after 回應欄位時間之前嘗試取得權杖。 429 回應通常表示應用程式未正確快取和重複使用權杖。 請確認應用程式中的快取和重複使用權杖狀況。

HTTP 5x 回應碼

當應用程式收到 HTTP 5xx 回應碼時，應用程式不可進入快速重試迴圈。 針對 429 回應使用相同的處理方式。 如果未出現 Retry-After 標頭，請實作指數輪詢重試，在回應後至少等待 5 秒再進行第一次重試。

當要求逾時時，不建議立即重試。 請實作指數輪詢重試，在回應後至少等待 5 秒再進行第一次重試。

擷取授權相關資訊

許多應用程式和 API 都需要使用者資訊才能授權。 可用的方法各有優缺點。

語彙基元

身分識別 (識別碼) 權杖和存取權杖具有提供資訊的標準宣告。 如果需要的資訊位於權杖中，最有效的技術是權杖宣告，因為這樣可避免產生另一個網路呼叫。 更少的網路呼叫代表著更好的復原能力。

深入了解：

• Microsoft 身分識別平台識別碼權杖
• Microsoft 身分識別平台存取權杖

注意

有些應用程式會呼叫「使用者資訊」端點，以取得已驗證使用者的相關宣告。 識別碼權杖的資訊是「使用者資訊」端點中資訊的超集。 讓應用程式使用識別碼權杖，而不是呼叫「使用者資訊」端點。

使用選擇性宣告 (例如群組) 來增強標準權杖宣告。 [應用程式群組] 選項涵蓋指派給應用程式的群組。 [所有] 或 [安全性群組] 選項包括相同租用戶中的應用程式群組，可將群組新增至權杖。 評估效果，因為這可以造成權杖膨脹，並要求更多呼叫來取得群組，從而導致權杖中要求群組的效率降低。

深入了解：

• 將選用宣告提供給您的應用程式
• 設定群組選擇性宣告

建議您使用並包含應用程式角色，讓客戶使用入口網站或 API 進行管理。 將角色指派給使用者和群組以控制存取權。 發出權杖時，指派的角色會包含在權杖角色宣告中。 衍生自權杖的資訊可避免更多 API 呼叫。

請參閱：將應用程式角色新增至您的應用程式，並在權杖中接收這些角色 (部分機器翻譯)

根據租用戶資訊新增宣告。 例如，延伸模組具有企業特定的使用者識別碼。

將資訊從目錄新增至權杖可減少相依性，從而提升效率並增加復原能力， 但由於無法取得權杖，因此無法解決復原問題。 為應用程式的主要案例新增選擇性宣告。 如果應用程式需要管理功能的資訊，應用程式可以視需要取得該資訊。

Microsoft Graph

Microsoft Graph 具有統一的 API 端點，可存取有關生產力模式、身分識別和安全性的 Microsoft 365 資料。 使用 Microsoft Graph 的應用程式可以使用 Microsoft 365 資訊來進行授權。

應用程式只需一個權杖即可存取 Microsoft 365，比起需要多個權杖的 Microsoft Exchange 或 Microsoft SharePoint 等 Microsoft 365 元件更具彈性。

使用 Microsoft Graph API 時，請使用 Microsoft Graph SDK，簡化建置可存取 Microsoft Graph 的復原性應用程式。

請參閱：Microsoft Graph SDK 概觀 (英文版)

針對授權，請考慮使用權杖宣告，而非某些Microsoft Graph 呼叫。 權杖中的要求群組、應用程式角色和選擇性宣告。 使用 Microsoft Graph 進行授權需要更多依賴 Microsoft 身分識別平台和 Microsoft Graph 的網路呼叫。 不過，如果您的應用程式依賴 Microsoft Graph 作為其資料層，則使用 Microsoft Graph 進行授權並不會增加風險。

在行動裝置上使用訊息代理程式驗證

在行動裝置上，Microsoft Authenticator 等驗證代理程式可改善復原能力。 驗證代理程式會使用主要重新整理權杖 (PRT) 搭配有關使用者和裝置的宣告。 使用 PRT 作為驗證權杖，以從裝置存取其他應用程式。 當 PRT 要求應用程式存取時，Microsoft Entra ID 會信任其裝置和 MFA 宣告。 如此可藉由減少驗證裝置的步驟來增加復原能力。 使用者不會在同一部裝置上收到多次 MFA 提示。

請參閱：什麼是主要重新整理權杖？ (部分機器翻譯)

MSAL 支援代理程式驗證。 深入了解：

• iOS 上透過驗證代理程式的 SSO (英文版)
• 使用 MSAL 在 Android 上啟用跨應用程式的 SSO (部分機器翻譯)

持續性存取評估

持續性存取評估 (CAE) 會利用長期的權杖來提高應用程式的安全性和復原能力。 使用 CAE 時，系統將根據重大事件和原則評估來撤銷存取權杖，而非短暫的權杖存留期。 針對某些資源 API，因為風險和原則會即時評估，CAE 會增加最多 28 小時的權杖存留期。 MSAL 會重新整理長時間存留的權杖。

深入了解：

• 持續性存取評估 (部分機器翻譯)
• 使用持續性存取評估來保護應用程式 (部分機器翻譯)
• 重大事件評估 (部分機器翻譯)
• 條件式存取原則評估 (部分機器翻譯)
• 如何在您的應用程式中使用啟用 CAE 的 API (部分機器翻譯)

如果您開發資源 API，請移至 openid.net 以取得共享訊號 – 安全 Webhook 架構 (英文版)。

下一步

• 如何在您的應用程式中使用啟用 CAE 的 API (部分機器翻譯)
• 提高您開發的精靈應用程式中，驗證和授權的復原能力 (部分機器翻譯)
• 在您的身分識別與存取管理基礎結構中打造復原能力
• 使用 Azure AD B2C 在客戶身分識別和存取管理中打造復原能力