linkMembers Only
Complete Data Security Playbook
Sign in to view this item.
Data Security, AuthN & AuthZ — Fundamentals to Agentic AI
A curated reference spanning fresher fundamentals through 25+ years staff/principal-level material on authentication, authorization, and data security — OWASP/NIST/IETF primary sources, practical interview-prep notes, and dedicated coverage of agentic AI security (OWASP LLM/Agentic Top 10, MCP authorization). Every link verified live; no filler.
16Items3Types
Read-only public collection
Browse public collectionsnote
Authentication vs Authorization — the mental model (and the one-line interview answer)
**Authentication (AuthN)** answers "who are you?" — proving an identity claim (a password, a passkey, a signed JWT, a mutual-TLS client cert). **Authorization (AuthZ)** answers "what are you allowed to do?" — deciding whether that already-proven identity can perform a specific action on a specific resource. The one-line interview answer that actually lands: **"Authentication happens once per session and establishes identity; authorization happens on every request and is re-evaluated against the current resource and action — you can be authenticated and still be denied."** That distinction is what separates a candidate who's memorized the terms from one who understands why a valid, unexpired session token can still return a 403. A concrete example worth having ready: logging into a banking app is authentication. Being blocked from viewing someone else's account balance while logged in is authorization. OWASP's own risk categories treat these as genuinely separate failure classes for exactly this reason — see the linked Top 10 entries for A01 (Broken Access Control) and A07 (Authentication Failures) in this collection: they are consistently the two most exploited risk categories in real breaches, and interviewers ask about both because conflating them in a design discussion is a real, common mistake — e.g. "we require login" is not the same claim as "we've authorized this specific action."
topic
OWASP Top 10:2025 — Broken Access Control & Authentication Failures
The two OWASP Top 10:2025 risk categories every AuthN/AuthZ discussion should be grounded in — both official, current (2025 edition), and consistently among the most exploited weaknesses in real-world breaches: - [A01:2025 – Broken Access Control](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/) — the #1 risk in the 2025 edition. Covers IDOR, missing function-level access checks, and privilege escalation via forced browsing. - [A07:2025 – Authentication Failures](https://owasp.org/Top10/2025/A07_2025-Authentication_Failures/) — credential stuffing, weak session management, and missing MFA on sensitive operations. Read both together, not separately — most real incidents involve a failure in one that only becomes exploitable because of a gap in the other (e.g. a valid session with no per-action authorization check).
link
OWASP Authentication Cheat Sheet
The practical, implementation-level companion to A07 above — password policy, credential storage, session/transport requirements, and account-recovery pitfalls, maintained by OWASP's Cheat Sheet Series. The single best answer to "how would you actually build a login system correctly" in an interview.
link
OWASP Authorization (Access Control) Cheat Sheet
Deny-by-default, principle of least privilege, and centralizing authorization logic rather than scattering checks across the codebase — the direct practical counterpart to A01 above. Includes a checklist for reviewing whether an access-control fix actually closes a whole class of IDOR bug or just the one reported instance.
link
OAuth 2.0 and OpenID Connect, explained clearly
OAuth 2.0 is an authorization framework ("what can this app do on my behalf"); OpenID Connect is an identity layer built on top of it ("who is this user"). This is the single most common mid-level interview confusion in this space — the clearest explanation of where one ends and the other begins, including the actual token types each one issues (access token vs ID token).
link
RFC 8725 — JSON Web Token Best Current Practices
The IETF's own current-practices document for JWTs — written specifically because the original JWT spec (RFC 7519) left enough implementation choices open that real, widely-exploited vulnerability classes emerged (algorithm confusion, the "alg: none" bypass, key-injection via unvalidated jku/x5u headers). If you use JWTs in production, this is the actual authoritative source, not a blog summary of it.
note
JWT interview traps — the four questions that separate "used a library" from "understands the token"
Four JWT failure modes that come up constantly in senior interviews, each tied to a real vulnerability class documented in RFC 8725 (linked in this collection): 1. **Algorithm confusion ("alg: none" / RS256→HS256 downgrade).** A JWT's header declares its own signing algorithm. A naive verifier that trusts the header can be tricked into accepting an unsigned token, or into treating an RSA public key as an HMAC secret (since public keys are, by definition, public). Fix: the verifier must pin the expected algorithm itself, never read it from the token. 2. **No built-in revocation.** A JWT is self-contained and stateless by design — that's the whole performance argument for using one — which means there is no way to invalidate a single already-issued token before it expires without maintaining server-side state (a denylist, or a version/epoch check against the account). "How do you log a user out immediately if JWTs are stateless?" is asked precisely because the honest answer requires admitting the statelessness has a real cost. 3. **Storage location (localStorage vs an httpOnly cookie).** localStorage is readable by any JavaScript running on the page, so it's directly exposed to XSS. An httpOnly cookie isn't readable by JS at all, but then needs CSRF protection instead. There is no storage location that's simply "safe" — the real answer names the specific tradeoff, not a memorized "always use cookies." 4. **Confusing a JWT's signature with encryption.** A signed (JWS) JWT is tamper-evident, not confidential — anyone can base64-decode and read the payload. Putting a secret or PII in the payload assuming the signature hides it is a real, recurring mistake. Encryption needs a JWE, a genuinely different construction most libraries don't default to.
link
SAML vs OAuth vs OIDC — key differences
Enterprise SSO still runs heavily on SAML (XML assertions, browser-redirect-based) even though OIDC (JWT-based, REST-friendly) is the modern default for new applications — knowing when a client mandates the older protocol, and why, is exactly the kind of judgment call a staff+ engineer is expected to make in a vendor-integration or platform-migration conversation.
topic
Modern authorization architecture — RBAC, ABAC, ReBAC & Zanzibar
Role-based access control (RBAC) is where almost every system starts — and where almost every system outgrows itself once permissions need to depend on more than "which role is this user in." Two later models exist for exactly that reason: - **ABAC (attribute-based)** evaluates a policy against attributes of the user, the resource, and the request context (e.g. "an editor can update a document only during business hours, only if they're in the same department as the document's owner"). More expressive than RBAC, harder to audit at scale. - **ReBAC (relationship-based)**, popularized by Google's internal Zanzibar system (the model behind Google Drive/Docs sharing), makes access a graph-traversal question — "can this user view this document because they have access to its parent folder, or because they're a member of a group that was granted access." This is the model most large-scale SaaS permission systems (Google Workspace, Slack, GitHub) actually run on today. - [OpenFGA docs — Fine-Grained Authorization, ReBAC, ABAC & Zanzibar Explained](https://openfga.dev/docs/authorization-concepts) — CNCF-hosted, open-source Zanzibar implementation; the clearest practical walkthrough of when each model actually breaks down in production, not just the theory. Interview framing worth having ready: RBAC breaks down at "role explosion" (a role per permission combination); ABAC breaks down at auditability (you can't easily answer "who can see X" without evaluating every policy); ReBAC solves both but adds real operational weight (a permission graph is its own piece of infrastructure to run and reason about). Most production systems in 2026 end up composing RBAC for coarse-grained access with ReBAC for resource-level sharing — not picking one model exclusively.
link
NIST SP 800-207 — Zero Trust Architecture
The foundational US government reference for zero trust: no implicit trust based on network location, every access request evaluated on identity + device posture + context, and enforcement pushed as close to the resource as possible. This is the document security architects actually cite when justifying a zero-trust initiative to leadership — worth reading in full at least once at a principal/staff level, not just knowing the buzzword.
link
NIST SP 800-63-4 — Digital Identity Guidelines
The current (finalized July 2025) revision of NIST's digital identity guidelines — defines the three assurance-level framework every serious identity system eventually gets measured against: Identity Assurance Level (how sure are we this identity claim is real), Authenticator Assurance Level (how sure are we this login is really that person), and Federation Assurance Level (how much do we trust an assertion from another identity provider). The vocabulary a principal-level engineer is expected to use precisely when talking to compliance/audit teams.
link
OWASP Top 10 for LLM Applications (2025)
The starting point for AI-specific security, and directly relevant to auth: LLM06:2025 "Excessive Agency" is fundamentally an authorization problem — an AI agent given more tool-access or permission scope than a task actually requires. Prompt injection (LLM01) is the new input-validation problem; sensitive information disclosure (LLM02) is the new data-authorization problem. Read this as "the same AuthN/AuthZ failure classes above, with an LLM as the new attack surface," not as an unrelated new topic.
link
OWASP Top 10 for Agentic Applications (2026)
Released December 2025, this is the current industry-standard threat taxonomy specifically for autonomous AI agents (referenced by Microsoft, AWS, NVIDIA) — goal hijacking, tool misuse, and "identity and privilege abuse" as named, first-class risk categories. The core fact worth internalizing: non-human identities (service accounts, AI agents) already outnumber human identities roughly 50:1 in a typical enterprise, so "authorization" in 2026 increasingly means authorizing an agent's actions, not just a human's.
link
Model Context Protocol — Authorization specification
The actual protocol-level answer to "how does an AI agent authenticate and get authorized to call a tool/API on a user's behalf" — Anthropic's Model Context Protocol standardizes this on OAuth 2.1 with PKCE and RFC 8707 resource indicators (binding a token to the specific MCP server it was issued for, so a stolen token can't be replayed against a different one). This is where classic OAuth knowledge (earlier items in this collection) becomes directly load-bearing for agentic AI security, not just theoretically related.
note
Agentic AI authorization checklist — what changes when the caller isn't a human
Classic AuthN/AuthZ assumes a human at a keyboard: a session that starts at login and ends at logout, a fixed permission set defined by role, and a human able to notice and stop something that looks wrong. An autonomous AI agent breaks every one of those assumptions, which is why "just reuse our existing OAuth setup" is necessary but not sufficient. Five things worth checking explicitly: 1. **Does the agent have its own identity, distinct from the user who invoked it?** Per-agent credentials (not a shared service-account token) are what make it possible to audit "which agent did this" and to revoke one agent without breaking every other integration. 2. **Is the agent's permission scope task-bound, not identity-bound?** A human's OAuth grant is typically broad and long-lived ("this app can read my email"). An agent's grant should be as narrow and short-lived as the specific task requires — this is directly what OWASP's "Excessive Agency" and "identity and privilege abuse" categories (linked earlier in this collection) are warning about. 3. **Can the agent's actions be attributed and audited after the fact, distinctly from the user's own actions?** "The user did X" and "an agent acting on the user's behalf did X" are not the same audit-log entry, and treating them as the same one loses the information you'd need during an incident. 4. **Is there a human-approval step before any irreversible or high-privilege action?** — a deliberate authorization gate, not an assumption that the agent's own judgment is sufficient. 5. **Does token/credential delegation stop at the agent, or can the agent re-delegate further (to a sub-agent, or a tool it calls)?** Unbounded delegation chains are exactly how a narrow, well-scoped initial grant quietly becomes a broad one three hops later. None of this replaces the fundamentals earlier in this collection — it's what gets layered on top of them once the caller on the other end of an authorization decision is autonomous rather than a person who can be asked "did you mean to do that?"