Security MOC

Tags

Security MOC

Navigation hub for 10 security pattern notes across five concern categories: authentication, authorization, transport and secrets, browser boundary, and architecture posture. See Design-Patterns-MOC for the root vault entry point.

Authentication

PatternIntentUse When
OAuth2-OIDC-FlowsDelegated authorization and federated identity using Authorization Code, Client Credentials, and Device flows with OIDC identity layer.User-facing clients (SPA, mobile, CLI) need delegated authorization; service-to-service via Client Credentials
JWTStateless, self-contained token format carrying verifiable claims signed with RS256/ES256 or HMAC.Portable, verifiable claims between services; stateless API auth where you can validate signature without a round-trip to the issuer
Session-ManagementServer-side session lifecycle: creation, rotation on privilege change, fixation prevention, expiry, and revocation.Sensitive applications where server-side revocation is required; SPA-with-BFF backends that store tokens in Redis behind an httpOnly cookie
API-Key-AuthenticationLong-lived opaque keys for machine-to-machine authentication with dual-active rotation and scoped permissions.M2M integrations where OAuth2 token lifecycle (refresh, expiry, audience binding) is overhead without matching benefit

Authentication selection guide: Use OAuth2-OIDC-Flows whenever a human user is involved or when a third-party service must act on behalf of a user. For service-to-service calls inside your own system, use Client Credentials flow from OAuth2-OIDC-Flows when you already run an authorization server, or API-Key-Authentication when OAuth2 infrastructure is not worth operating. Use JWT as the token format when you need portable, verifiable claims between services — always validate signature before trusting any claim (signature first, then expiry, then audience). Use Session-Management for sensitive apps (banking, admin panels) where server-side revocation is a hard requirement and where the OAuth2-BFF-Pattern is storing tokens in Redis behind an httpOnly cookie.

Authorization

PatternIntentUse When
RBAC-ABACRole-Based Access Control and Attribute-Based Access Control: static role assignments vs policy-evaluated attribute sets with hybrid enforcement points.Controlling what authenticated principals are permitted to do after identity is established

Authorization selection guide: RBAC is the right default when roles are stable, the number of distinct roles is small (< 20), and access decisions do not depend on resource attributes or environmental context. ABAC is necessary when fine-grained attribute-level policies are required — for example, "a manager can approve expense reports only if the report belongs to a direct report in the same department and the amount is within budget." A hybrid approach is common in practice: use RBAC for coarse-grained role assignment and add ABAC policies at enforcement points where attribute-level granularity is needed. Start with RBAC and add ABAC policies incrementally as requirements demand them.

Transport and Secrets

PatternIntentUse When
EncryptionProtect data by state: AES-256-GCM at rest, TLS 1.3 in transit, envelope encryption (DEK+KEK) for key hierarchy, AEAD for authenticated encryption.Any data with confidentiality or integrity requirements — encrypt by default, choose algorithm by data state
Secrets-ManagementCentralised secret store with dynamic secret generation, dual-credential rotation for zero-downtime rotation, and short-lived leases.Any service consuming database credentials, API keys, TLS certificates, or signing keys — never hardcode secrets in code or environment variables

Transport and secrets selection guide: For Encryption, choose by data state: AES-256-GCM for data at rest (symmetric, authenticated, 96-bit nonce), TLS 1.3 for data in transit (forward secrecy via ephemeral key exchange), and envelope encryption (DEK+KEK pattern) when you need to re-key large datasets without re-encrypting all data. For Secrets-Management, prefer dynamic secrets (database credentials generated on demand with short TTL) over static secrets. When rotating static secrets without downtime, use dual-credential rotation: provision new credential, deploy consumers that accept both old and new, then revoke old. Never store secrets as plaintext environment variables in container manifests or CI pipelines.

Browser Boundary

PatternIntentUse When
CORS-CSPCross-Origin Resource Sharing controls which origins may make cross-origin requests; Content Security Policy controls which resources the browser may load.Any web application that loads third-party resources, accepts cross-origin API calls, or needs to prevent XSS via resource loading restrictions
Input-ValidationAllowlist-based validation at trust boundaries: schema validation, parameterised queries, output encoding, and file upload controls.Every service that accepts external input — validate at the trust boundary, not only at the UI layer

Browser boundary selection guide: CORS-CSP addresses two distinct browser security mechanisms that are often confused. CORS is a server-side policy that tells the browser which origins may make cross-origin requests — misconfiguring CORS to allow wildcard origins with credentials is a common vulnerability. CSP is a browser-enforced policy that restricts which resources (scripts, styles, images, frames) the browser may load from which origins. Use nonce-based CSP for applications with dynamically generated scripts; hash-based CSP for static inline scripts. For Input-Validation, apply the allowlist principle at every trust boundary: validate structure and type before any business logic, use parameterised queries or prepared statements for all database access, HTML-encode output in rendering contexts, and treat every byte of a file upload as untrusted. Input validation at the UI layer alone is not sufficient — server-side enforcement is mandatory.

Architecture

PatternIntentUse When
Zero-Trust-ArchitectureArchitectural posture (NIST SP 800-207) that eliminates implicit trust from network position: every request is authenticated, authorised, and encrypted regardless of origin.Cloud-native multi-tenant systems, remote-first workforces, or any environment where the network perimeter is insufficient as a trust boundary

Architecture selection guide: Zero Trust is an architectural posture, not a product. NIST SP 800-207 defines it as a set of principles — verify explicitly, use least privilege, assume breach — implemented through three planes: identity plane (IdP-issued tokens, certificate-based workload identity), policy engine (policy decision point evaluating each request), and network plane (microsegmentation, mutual TLS via Service-Mesh-Pattern). Adopt Zero Trust when perimeter-based security is architecturally insufficient: cloud-native multi-tenant systems, environments with a large remote workforce, or systems where lateral movement after perimeter breach would be catastrophic. Zero Trust is not equivalent to deploying a service mesh — a service mesh enforces only the network plane, not the identity or policy planes.

Security Concern Selector

Is the concern about proving who the user is or which system is making the call? -> Yes, user-facing client (SPA, mobile, CLI): OAuth2-OIDC-Flows (Authorization Code + PKCE) -> Yes, service-to-service within your own system: OAuth2-OIDC-Flows (Client Credentials) or API-Key-Authentication -> Yes, validating a token format between services: JWT -> Yes, server-side session lifecycle and revocation: Session-Management -> No: Continue

Is the concern about what an authenticated principal is permitted to do? -> Yes: RBAC-ABAC (RBAC for stable roles; ABAC for attribute-level policies; hybrid for both) -> No: Continue

Is the concern about protecting data in transit or at rest? -> Yes, data at rest: Encryption (AES-256-GCM) -> Yes, data in transit: Encryption (TLS 1.3) -> Yes, key hierarchy or large dataset re-keying: Encryption (envelope encryption, DEK+KEK) -> No: Continue

Is the concern about managing credentials, API secrets, or service signing keys? -> Yes, centralised lifecycle with rotation: Secrets-Management -> Yes, M2M key rotation with zero downtime: API-Key-Authentication (dual-active rotation) -> No: Continue

Is the concern about browser request origin controls or browser resource loading policy? -> Yes, which origins may call your API cross-origin: CORS-CSP (CORS policy) -> Yes, which resources the browser may load: CORS-CSP (CSP nonce or hash) -> No: Continue

Is the concern about blocking malicious input before it reaches business logic? -> Yes: Input-Validation (allowlist schema validation at trust boundary, parameterised queries, output encoding) -> No: Continue

Is the concern about architectural trust posture — eliminating implicit trust from network position? -> Yes: Zero-Trust-Architecture (identity plane + policy engine + microsegmentation)

Cross-Domain Lineage Chains

Lineage chains trace how security concerns propagate through the vault's pattern graph.

ChainLineage
IdentityOAuth2-OIDC-Flows -> JWT -> RBAC-ABAC -> Session-Management (identity is established via OAuth2 flows, carried as JWT claims, evaluated by RBAC/ABAC policies, and maintained via session lifecycle)
Infrastructure TrustZero-Trust-Architecture -> Service-Mesh-Pattern -> API-Gateway-Pattern -> API-Key-Authentication (trust-nothing posture enforced through mutual TLS in the mesh, ingress policy at the gateway, and key-scoped M2M authentication)
Browser DefenseCORS-CSP -> Input-Validation -> OAuth2-BFF-Pattern (browser boundary defense: origin controls at the CORS layer, input sanitization at every trust boundary, tokens stored in BFF behind httpOnly cookie)

Sources

  • NIST SP 800-207 — Zero Trust Architecture
  • RFC 6749 — The OAuth 2.0 Authorization Framework
  • RFC 7519 — JSON Web Token (JWT)
  • OWASP Top 10 (2021)
  • OWASP Application Security Verification Standard (ASVS)

Linked mentions