探索 AuthZ 的定義，AuthN 與 AuthZ 的區別，AuthZ 的運作方式，以及授權的最佳實踐。
AuthZ 是 授權 的簡稱。授權是與 身份驗證 分開的機制。身份驗證確認你是誰，而授權則決定你是否可以訪問特定的資源以及可在其上執行哪些操作。
在現實世界的例子中，資源可以包括軟件、系統、文檔、訂單和資產。授權提供了額外的控制層，用於指明誰可以在什麼條件下訪問這些資源。
授權與身份驗證分開但通常會與其連接。例如，標準協議如 OAuth 2.0、OIDC 和 SAML 都包含基於令牌的授權機制。
在基於令牌的授權系統中，授權服務器向用戶授予一個 訪問令牌。這個包含權限的令牌決定了用戶是否可以訪問特定的資源。
將權限直接分配給用戶可能會效率低下，特別是當需要更詳細的條件時。例如，訪問可能取決於特定情況，如用戶的位置，這使得需要訪問控制策略來更好地管理權限。
以下是一個授權如何運作的高層級步驟流程：
想了解 OAuth 2.0 授權請求流程的詳細信息，可以查看 授權請求
基於角色的訪問控制 (RBAC) 使用角色來管理訪問。每個用戶都被分配了一個或多個預定義角色，每個角色都包含一組權限。RBAC 的關鍵在於理解主體（或用戶）、角色和權限之間的關係。
要理解基於角色的訪問控制 (RBAC) 的運作方式，你需要了解：
user 或 machine-to-machine application。admin memberread: order。
基於屬性的訪問控制 (ABAC) 在授權中廣泛使用，並支持更複雜的情境，通過使用實體的特定屬性，而不僅僅是角色。
例如，一家公司管理一個全球的文件共享平台，員工需要根據其工作角色、地點及文件的分類等級獲得受控訪問敏感文件的權限。
屬性可設計成以下方式：
還有其他訪問控制模型，如基於政策的訪問控制 (PBAC) 。每個模型都有其優勢和劣勢，選擇模型取決於你的使用案例和需求。
B2C 軟件通常需要基於業務需求的特定角色。例如，一個書店管理應用可能包括有不同職責的角色，如管理資源和服務。
B2B 應用通常使用多租戶架構，其中每個租戶代表一個組織。組織內需要角色，如管理員和成員。在這裡，授權（AuthZ）在管理組織層級的用戶中發揮關鍵作用，通常使用基於角色的訪問控制 (RBAC)。
機器對機器 沒有人工交互，直接發生在服務之間。例如，通過調用 API 服務。通常涉及令牌（如 OAuth 2.0 訪問令牌）以確保安全、動態和精細的訪問。
以下是一些確保安全有效訪問控制的 授權（authZ）最佳實踐：
最小特權原則
這可確保未經授權的訪問或由受損賬戶造成的損害風險最小化。用戶和系統僅應訪問其角色所需的資源和操作。
採用基於令牌的授權
基於令牌的訪問控制提供了更大的靈活性和精細控制，同時遵循開放標準。使用安全令牌（例如 OAuth 2.0、JWTs）授予時效性和範圍內的訪問。
定期審計和監控
定期查看訪問日誌和授權策略，以便及時發現異常或過時的權限。
應用職責分離
從實施精細的權限開始，比如定義特定動作和資源（如讀取、寫入、刪除）。在創建角色時，使用清晰的角色名稱並強制執行職責分離，以最小化由單一用戶造成的詐騙或錯誤風險。
支持多租戶（如果適用）
對於多租戶系統，租戶隔離至關重要。通過將其與基於角色的訪問控制結合，可以實現數據資源的分離，確保適當的角色只能在其租戶內訪問資源。這防止意外或惡意訪問其他租戶的資源。
動態撤銷訪問
在設計你的 AuthZ 系統時，確保在條件變更時（例如角色更新，或雇用終止）可以及時更新或撤銷權限。這可以通過動態 API 檢查、webhooks 或其他方法實現。目標是實時防止未經授權的訪問。
身份驗證和授權之間的區別在於它們在身份和訪問管理中的目的和過程。
AuthN（身份驗證）回答的是“你是誰以及你擁有哪個身份。”這是一個驗證用戶、服務或設備身份的過程。身份驗證確保嘗試訪問系統或資源的實體是真實的。常見的方法包括密碼、生物識別和雙因素身份驗證（2FA）。例如，當你使用你的電子郵件和密碼登錄賬戶時，系統通過身份驗證確認你的身份。
AuthZ（授權）回答的是“你被允許做什麼？”這是一個基於用戶的權限或角色授予或拒絕訪問資源的過程。授權在身份驗證之後發生，並決定已驗證的用戶可以執行哪些操作。例如，登入後，管理員用戶可以修改設置，而普通用戶只能查看它們。
總之，AuthN（身份驗證）確認身份，而 AuthZ（授權）定義訪問。身份驗證先發生，然後是授權以確保資源的安全和適當使用。
Logto Cloud 提供基於開放標準協議如 OIDC、OAuth 2.0 和 SAML 的關鍵授權服務。其功能包括基於角色的訪問控制、組織（多租戶）和自定義令牌聲明，滿足你從各種角度的授權需求。