Authorization Study Guide

📖 Core Concepts Authorization – Determines what a verified subject may do with a resource, based on an access policy. Subject – Any entity that can request access (human user, software, hardware). Resource – Anything protected by policy (files, data items, programs, devices, app functions). Access Control – The enforcement mechanism that approves or rejects requests according to the authorization policy. Authentication vs. Authorization – Authentication proves identity; authorization decides permitted actions after identity is known. Least Privilege – Grant subjects only the permissions needed to perform their job, no more. Policy Expression Formats – ACLs, capabilities, XACML, etc., are concrete ways to write the abstract policy. Tokens (keys, certificates, tickets) – Credential artefacts that convey authorization without re‑authenticating the holder. --- 📌 Must Remember Authorization ≠ Authentication – one verifies who you are, the other defines what you can do. Roles → Permissions – In RBAC, a subject gains access if it holds a role that is assigned to the resource. OAuth 2.0 – Enables third‑party apps to obtain limited access to a user’s resources without exposing the user’s password. Principle of Least Privilege – Always the default stance for secure policy design. Broken Authorization – The top‑rated security risk for web applications; look for missing or overly‑permissive policies. Authority vs. Custodian – Authority (e.g., manager) decides who gets what; Custodian (e.g., sysadmin) implements it in the system. --- 🔄 Key Processes Configuration Phase Create user/account. Define the subject’s authorization policy (roles, ACL entries, capabilities). Usage Phase Authenticate the subject. Apply the pre‑configured authorization to decide access (allow/deny). OAuth 2.0 Token Flow (high‑level) Resource owner → authorizes third‑party client. Authorization server issues an access token. Client presents token to resource server → server enforces token‑based authorization. Changing/Removing Authorization Locate the relevant access rule (ACL entry, role assignment, capability). Modify (add/remove permissions) or delete the rule entirely. --- 🔍 Key Comparisons Authorization vs. Authentication AuthN: “Who are you?” → identity verification. AuthZ: “What may you do?” → privilege check. Role‑Based vs. Relationship‑Based Access Control RBAC: Access granted through static roles (e.g., Engineer, HR). Relationship‑Based: Access granted through dynamic social ties (e.g., friend, follower). ACL vs. Capability ACL: List attached to resource (who can do what). Capability: Token attached to subject (what the holder can do). Authority vs. Custodian Authority: Decides who should have which rights. Custodian: Implements those rights in the system. --- ⚠️ Common Misunderstandings “Authorization is the same as authentication.” → Wrong: AuthN confirms identity; AuthZ enforces permissions after auth. “Least privilege means users get no access.” → Incorrect: It means only the necessary access, nothing extra. “A token equals a user’s identity.” → Misleading: Tokens convey authorization; they may be used by anonymous consumers. “RBAC automatically handles all fine‑grained cases.” → Not true: RBAC works well for static role sets; dynamic relationships need other models. --- 🧠 Mental Models / Intuition “Keys and Doors” – Tokens/capabilities are keys; resources are doors with locks (ACLs). Only matching keys open doors. “Gatekeeper” – Authentication is the guard checking ID; Authorization is the rulebook the guard uses to decide if the ID holder may pass. “Layer Cake” – Bottom layer: Authentication → middle layer: Authorization policy → top layer: Access Control enforcement. --- 🚩 Exceptions & Edge Cases Anonymous Consumers – Guests that skip authentication but receive a very limited set of authorizations (often via default ACLs). Token‑Based Access Without Identity – Access tokens can be presented by anyone holding them; the system trusts the token, not the holder’s identity. Relationship‑Based Policies – May change dynamically as social ties evolve; static ACLs may become outdated quickly. --- 📍 When to Use Which OAuth 2.0 – When a third‑party needs limited, revocable access to a user’s resources (e.g., “Sign‑in with Google”). RBAC – Ideal for enterprise environments with clear, relatively static job functions. Relationship‑Based Access – Best for social platforms where permissions depend on friendships, follows, or groups. ACLs – Simple file‑system or OS‑level permissions where the resource owner can list allowed subjects. Capabilities – When delegation of rights is required without exposing a central policy list (e.g., micro‑service token passing). --- 👀 Patterns to Recognize “Limited‑scope token” → Look for statements about third‑party access without sharing credentials → likely OAuth. “Role assignment” + “resource mapping” → Indicates RBAC. “Friend / follower” language → Signals relationship‑based control. “Least privilege” + “only needed resources” → Spot a well‑designed policy. “Broken authorization” in a scenario → Expect missing/over‑permissive ACLs or unchecked token usage. --- 🗂️ Exam Traps Choosing “authentication” when the question asks about “what a user can do.” Why tempting: Both involve security; the key is the verb “do” → Authorization. Selecting RBAC for a social‑media scenario involving “friends.” Why tempting: RBAC is a familiar model; the correct answer is relationship‑based. Assuming “least privilege” means “no privileges.” Why tempting: The phrase sounds restrictive; remember it’s minimum necessary, not zero. Confusing a capability token with a password token. Why tempting: Both are “tokens”; only capabilities convey rights, passwords convey identity. Over‑looking the “authority vs. custodian” distinction when asked who sets policies. Why tempting: Both roles touch policy; the authority decides, the custodian implements.