共用方式為

授權基本概念

  • 發行項

授權 (有時會縮寫為 AuthZ) 的用途是設定權限，以評估對資源或功能的存取權。 相反地，驗證 (有時會縮寫為 驗證) 會著重於證明使用者或服務之類的實體確實是他們所宣稱的身分。

授權可以包含指定允許實體存取的功能、資源或資料。 授權也會指定可以使用資料完成的內容。 此授權動作通常稱為「存取控制」。

驗證和授權是不受限於使用者的概念。 服務或精靈應用程式通常是用來以本身的方式 (而非代表特定使用者) 來提出資源要求。 在本文中，「實體」一詞是用來表示使用者或應用程式。

授權方法

有幾個常見的方法可以處理授權。 角色型存取控制目前是使用 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:00 至下午 5:00 期間存取以「僅限管理員在工作時間期間」中繼資料標籤所識別的檔案。 在此情況下，藉由檢查使用者的屬性 (狀態為管理員)、資源的屬性 (檔案上的中繼資料標籤) 以及環境屬性 (目前時間) 來決定存取權。

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

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

Azure ABAC 是現今可用的 ABAC 解決方案範例。 Azure ABAC 會根據特定動作內容中的屬性新增角色指派條件，以在 Azure RBAC 上建立。

實作授權

授權邏輯通常會在需要存取控制的應用程式或解決方案內實作。 在許多情況下，應用程式開發平台會提供中介軟體或其他 API 解決方案，以簡化授權的實作。 範例包括在 ASP.NET 中使用 AuthorizeAttribute 或 Angular 中使用路由防護。

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

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

下一步