開發委派的許可權策略

本文可協助您身為開發人員，實作在應用程式中管理許可權的最佳方法，並使用 零信任 原則進行開發。 如取得存取資源的授權中所述，委派的許可權會與委派存取搭配使用，以允許應用程式代表使用者採取行動，只存取使用者可以存取的內容。 應用程式許可權 會與直接存取搭配使用，以允許應用程式存取與許可權相關聯的任何數據。 只有服務主體的系統管理員和擁有者可以同意應用程式許可權。

許可權和同意模型主要是指應用程式。 許可權和同意程式無法控制使用者可以執行的動作。 它會控制應用程式允許執行的動作。

參考下列 Venn 圖表。 使用委派的許可權時，使用者允許執行的動作和允許應用程式執行的動作之間會有交集。 該交集是應用程式系結的有效許可權。 每當您使用委派的許可權時，有效的許可權就會系結它。

“Venn 圖表描述：左圓文字：應用程式會獲得應用程式作業範圍的同意。 右圓形文字：使用者具有其組織所管理之作業的許可權。 圓形文字的交集：有效許可權：應用程式許可權和使用者功能的交集。」

例如，在應用程式前面擁有使用者的應用程式會取得更新租使用者中每個使用者配置檔的許可權。 這並不表示任何執行應用程式的人可以更新其他人的配置檔。 如果系統管理員決定授與您的應用程式 User.ReadWrite.All，則他們認為您的應用程式在更新任何使用者配置檔時正在執行正確的動作。 您的應用程式可能會記錄變更，並適當地保護資訊。 系統管理員對應用程式進行價值判斷，而不是使用者。

最低許可權方法

API 可能相當複雜。 簡單的 API 可能沒有許多作業。 Microsoft Graph 之類的複雜 API 會封裝應用程式可能想要使用的許多要求。 只是因為應用程式有權讀取，並不表示它應該有權更新。 例如，Microsoft Graph 有數千個 API。 只是因為您有權讀取使用者配置檔，因此您也不應該有許可權刪除其所有 OneDrive 檔案。

身為開發人員，您應該：

• 知道應用程式所呼叫的 API。
• 瞭解 API 檔，以及 API 所需的許可權。
• 使用可能最少的許可權來完成您的工作。

API 通常會提供組織數據存放區的存取權，並吸引想要存取該數據的攻擊者的注意。

評估您要求的許可權，以確保您尋求絕對最低許可權集以完成作業。 避免要求更高的許可權許可權;相反地，請仔細處理圖形所提供的大量 API 許可權，例如 Microsoft。 找出並使用最低許可權來解決您的需求。 如果您未撰寫程式代碼來更新使用者的配置檔，則不會向您的應用程式要求。 如果您只存取使用者和群組，則不會要求存取目錄中的其他資訊。 如果您沒有撰寫存取使用者電子郵件的程式代碼，則不會要求管理使用者電子郵件的許可權。

在 零信任 應用程式開發中：

• 定義應用程式的意圖及其需求。
• 請確定不良動作項目無法入侵並使用您的應用程式，以您不想要的方式使用。
• 提出核准要求，以在其中定義需求（例如，讀取使用者的郵件）。

許可權和同意中的使用者和租用戶系統管理員角色

可核准要求的人員分為兩種類別：一律同意許可權要求和非系統管理員的一般使用者。 不過，租用戶系統管理員在其租使用者中有關於哪些許可權需要系統管理員同意，以及使用者可以同意哪些許可權的最終發言權。

當 API 設計工具需要系統管理員同意許可權時，該許可權一律需要管理員同意。 租用戶系統管理員無法推翻該原則，而且只需要使用者同意。

當 API 設計工具定義需要使用者同意的許可權時，租用戶系統管理員可以推翻 API 設計工具的使用者同意建議。 租用戶系統管理員可以在租使用者中使用「大型切換」來執行此動作：所有專案都需要管理員同意。 他們可以使用許可權和同意管理，以更細微的方式推翻使用者同意。 例如，他們可能會允許使用者同意已 驗證發行者 的使用者同意要求，但不能來自其他發行者。 在另一個範例中，他們可能會允許 User.Read 登入使用者並讀取其配置檔，但需要系統管理員同意要求郵件或檔案許可權的應用程式。

API 設計工具會提出建議，但租用戶系統管理員有最後的判斷權。 因此，身為開發人員，您不一定知道您的應用程式何時需要系統管理員同意。 最好是針對這個進行規劃和設計，但請記住，當您提出令牌要求時，可能會因為任何原因而被拒絕。 在您的程式代碼中，您需要正常處理未取得令牌，因為客戶或使用者執行應用程式的租用戶系統管理員決定何時需要系統管理員同意許可權。

使用 JavaScript MSAL 的範例

針對此範例中的驗證，您會使用我們的 JavaScript Microsoft驗證連結庫 （MSAL），在瀏覽器執行所有應用程式邏輯的單頁應用程式 （SPA） 中登入使用者。

從相關的 快速入門文章中，您可以 下載 並執行程式碼範例。 它示範 JavaScript 單頁應用程式 （SPA） 如何使用授權碼流程搭配 Code Exchange 證明金鑰 （PKCE） 來登入使用者並呼叫 Microsoft Graph。 程序代碼範例示範如何取得存取令牌，以呼叫 Microsoft Graph API 或任何 Web API。

如下列範例程式代碼所示，您會具現化公用客戶端，因為完全在瀏覽器中執行的應用程式必須是公用用戶端。 當使用者的程式代碼在瀏覽器中時，使用者可以掌握應用程式的內部。

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

然後使用我們的 MSAL 連結庫。 在 MSAL JavaScript 中，有特定的 API 可登入。 有兩個 API 會利用瀏覽器內的特定功能。 其中一個是使用快顯體驗登入;另一個是使用瀏覽器重新導向體驗登入。

如下列程式代碼範例所示，登入彈出視窗會藉由呼叫 signIn 函式來處理用戶必須執行的驗證。

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

您的應用程式可以取得使用者的相關信息，例如其顯示名稱或使用者識別碼。 接下來，您的應用程式需要授權，才能透過遵循您在整個 MSAL 連結庫中使用的模式，從 Microsoft Graph 讀取使用者的完整設定檔。

如下列範例程式代碼所示，您的應用程式會藉由呼叫 AcquireTokenSilent來嘗試取得授權。 如果Microsoft Entra ID 可以發出令牌而不與用戶互動，則 AcquireTokenSilent 傳回您的應用程式代表使用者存取 Microsoft Graph 所需的令牌。

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            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);
            }
    });
}

不過，通常Microsoft Entra ID 在與使用者互動的情況下無法發出令牌（例如，用戶已變更其密碼或未授與同意）。 因此， AcquireTokenSilent 將錯誤傳回需要使用者互動的應用程式。 當您的應用程式收到錯誤時，請回覆呼叫 AcquireTokenPopup。

此時，Microsoft Entra ID 與使用者進行交談，讓他們可以驗證使用者，並授權您的應用程式代表使用者採取行動（例如，執行 MFA、提供其密碼、授與同意）。 然後，您的應用程式會取得其向前移動所需的令牌。

企業 零信任 旅程的主要步驟是採用更強大的驗證方法，而不只是使用者標識碼和密碼。 上述範例程式代碼完全可讓企業移至企業選擇的更強身份驗證方法。 例如，多重要素驗證，具有 FIDO2 金鑰的完整無密碼，Microsoft Authenticator。

下一步

• 取得存取資源的授權可協助您瞭解如何在取得應用程式的資源訪問許可權時，最好確保 零信任。
• 開發應用程式許可權策略 可協助您決定認證管理的應用程式許可權方法。
• 自定義令牌描述您可以在 Entra 令牌 中接收的資訊Microsoft。 它說明如何自定義令牌，以改善彈性和控制，同時提高應用程式零信任安全性與最低許可權。
• 在令牌 中設定群組宣告和應用程式角色會示範如何使用應用程式角色定義來設定應用程式，並將安全組指派給應用程式角色。 這些方法有助於改善彈性和控制，同時以最低許可權增加應用程式零信任安全性。
• API 保護說明透過註冊、定義許可權和同意來保護 API 的最佳做法，以及強制執行存取以達成您的 零信任 目標。
• 從另一個 API 呼叫 API 可協助您確保有一個 API 需要呼叫另一個 API，並在應用程式代表使用者運作時安全地開發應用程式時，零信任。
• 授權最佳做法 可協助您為應用程式實作最佳的授權、許可權和同意模型。
• 在應用程式開發生命週期中使用 零信任 身分識別和存取管理開發最佳做法，以建立安全的應用程式。