授權基本概念

  • 發行項

授權 （有時縮寫為 AuthZ）可用來設定許可權，以評估資源的存取權或功能。 相反地， 驗證 （有時縮寫為 AuthN）著重於證明像是使用者或服務的實體確實是他們聲稱身分的實體。

授權可以包含指定允許實體存取的功能、資源或數據。 授權也會指定如何使用數據來完成的工作。 此授權動作通常稱為 訪問控制。

驗證和授權不僅限於使用者的概念。 服務或精靈應用程式通常會建置為本身，而不是代表特定使用者要求資源。 在本文中，「實體」一詞用來參考使用者或應用程式。

授權方法

有數種常見的方法來處理授權。 角色型訪問控制目前是使用 Microsoft 身分識別平台 最常見的方法。

驗證即授權

可能最簡單的授權形式是根據提出要求之實體是否已通過驗證來授與或拒絕存取權。 如果要求者可以證明他們是誰，他們可以存取受保護的資源或功能。

存取控制清單

使用訪問控制清單 （ACL） 的授權牽涉到維護特定實體的明確清單，這些實體具有或沒有資源或功能的存取權。 ACL 可更精細地控制驗證即授權，但隨著實體數目增加而變得難以管理。

角色型存取控制

角色型訪問控制 （RBAC） 可能是在應用程式中強制執行授權最常見的方法。 使用 RBAC 時，會定義角色來描述實體可能執行的活動類型。 應用程式開發人員會授與角色的存取權，而不是授與個別實體的存取權。 然後，系統管理員可以將角色指派給不同的實體，以控制哪些角色可以存取哪些資源和功能。

在進階 RBAC 實作中，角色可能會對應至許可權集合，其中許可權會描述可執行的細微動作或活動。 然後，角色會設定為許可權的組合。 結合指派給實體之各種角色的許可權，計算實體的整體許可權集合。 此方法的一個很好的範例是管理 Azure 訂用帳戶中資源的存取權的 RBAC 實作。

注意

應用程式 RBAC 與 Azure RBAC 和 Microsoft Entra RBAC 不同。 Azure 自定義角色和內建角色都是 Azure RBAC 的一部分，可協助管理 Azure 資源。 Microsoft Entra RBAC 允許管理 Microsoft Entra 資源。

屬性型訪問控制

屬性型訪問控制 （ABAC） 是更精細的訪問控制機制。 在此方法中，規則會套用至實體、要存取的資源，以及目前的環境。 規則會決定資源與功能的存取層級。 例如，在工作日上午 9 點 - 下午 5 點期間，只有管理員才能存取以元數據標記識別的檔案。 在此情況下，存取權取決於檢查使用者的屬性（狀態為管理員]、資源的屬性（檔案上的元數據標記），以及環境屬性（目前時間）。

ABAC 的其中一個優點是，您可以透過規則和條件評估來達成更細微且動態訪問控制，而不需要建立大量的特定角色和 RBAC 指派。

使用 Microsoft Entra ID 達成 ABAC 的其中一種方法是使用 動態群組。 動態群組可讓系統管理員根據具有所需值的特定使用者屬性，動態將使用者指派給群組。 例如，可以建立 Author 群組，其中具有職稱 Author 的所有用戶都會動態指派給 Author 群組。 動態群組可以與 RBAC 搭配使用，以進行授權，您可以在其中將角色對應至群組，並動態將使用者指派給群組。

Azure ABAC 是目前可用的 ABAC 解決方案範例。 Azure ABAC 是以 Azure RBAC 為基礎，根據特定動作內容中的屬性新增角色指派條件。

實作授權

授權邏輯通常會在需要訪問控制的應用程式或解決方案內實作。 在許多情況下，應用程式開發平臺會提供中間件或其他 API 解決方案，以簡化授權的實作。 範例包括在 Angular 中使用 AuthorizeAttribute ASP.NET 或 Route Guards 。

對於依賴已驗證實體相關信息的授權方法，應用程式會評估驗證期間交換的資訊。 例如，使用安全性令牌內提供的資訊。 如果您打算使用令牌中的資訊進行授權，建議您遵循 此指引，以透過宣告驗證正確保護應用程式。 in 如需安全性令牌中未包含的資訊，應用程式可能會對外部資源進行額外的呼叫。

開發人員不需要完全在應用程式內嵌授權邏輯。 相反地，專用的授權服務可用來集中進行授權實作和管理。

下一步