Technology Deep Dives & Best Practices18 items

Technology Deep Dives & Best Practices18 items
OAuth2 vs SSO vs JWT — how they interact

OAuth2 is an authorization framework. JWT is a token format that may carry claims. SSO is a user experience typically implemented using protocols like SAML or OpenID Connect (OIDC).

Common pattern: OIDC provides identity (who you are) and OAuth2 provides access (what you can do). The API accepts a JWT access token if it recognizes the issuer and validates signature, audience, and expiry.

Client Authorization Server Resource Server (API) Identity Provider (SSO) OAuth2 Auth Code Access Token (JWT) Call API with Bearer OIDC (SSO identity)
Header: {alg, typ} Payload: {sub, aud, exp, scope} Signature JWT = base64url(header).base64url(payload).base64url(signature)
JWT structure
API Gateway Security Layers (edge → auth → validation → observability)

API gateways centralize security: edge protection (WAF/bots/DDoS), authentication/authorization (JWT/OIDC, mTLS), input validation and egress controls, and observability (correlation IDs, audit, detections).

Use the gateway to enforce deny-by-default route policies, scope mapping, and global rate limits. Shift-left with schema validation.

Edge: WAF/Rate Limiting/Bot Mitigation AuthN/AuthZ: JWT/OIDC, mTLS, Scope & ABAC Validation: Schema, Size, Canonicalization, SSRF Egress Observability: Correlation IDs, Audit, Threat Detection
Client API Gateway (WAF, Rate, AuthZ) Upstream Service AuthN (JWT/OIDC/mTLS), Schema Validation, Logging WAF & Bot Mitigation Rate Limiting / Quotas Request/Response Transform & Redaction
API Gateway request path
Key Management Models: SSE, CSE, BYOK, HYOK

SSE: The provider encrypts data at rest on the server. CSE: The client encrypts data before sending it to the provider.

BYOK: You supply the key to the provider's KMS. HYOK: Your keys stay in your HSM boundary; the provider never holds them.

SSE (Server-Side Encryption) CSE (Client-Side Encryption) BYOK (Vendor uses your key) HYOK (Keys never leave your HSM)
Zero Trust Architecture (NIST 800-207)

Assume breach; verify explicitly. Access decisions are made per request using strong identity, device posture, and context, not network location.

Replace broad network access (VPN) with per-app ZTNA; log/monitor continuously.

User/Device Policy Engine App/Resource Continuous verification: identity, device, context, posture
IAM Role & Policy Hierarchies (AWS vs Azure vs GCP)

AWS: Organizations → Accounts → IAM Roles/Policies (SCPs at org).

Azure: Management Group → Subscription → Resource Group → Resource (Role Assignments; PIM).

GCP: Organization → Folder → Project → Resource (IAM Roles with Conditions; Org Policies).

User (IdP) AWS STS Role in Account AssumeRole → Temp creds
AWS STS AssumeRole overview
SAML vs OIDC — choosing the right federation

SAML is XML-based and widely used for enterprise SSO; OIDC is JSON/REST-friendly and better for modern apps and mobile.

Prefer OIDC for new greenfield apps; keep SAML for legacy SaaS where OIDC is not supported.

SAML uses XML assertions; OIDC uses JSON Web Tokens (JWTs).

OIDC is a thin identity layer on top of OAuth 2.0, ideal for APIs and SPAs.

SAML typically operates via browser POSTs and redirects, making it less suitable for mobile apps.

Migration tip: Use an identity broker that can speak both protocols during transition.

SSRF Defenses — egress control and parsing hardening

Deny outbound to metadata and RFC1918 by default; enforce egress allowlists via proxies.

Use robust URL parsing; re-resolve redirects; enforce protocol and DNS policies.

Mitigate SSRF by enforcing egress filtering at the network layer and using metadata service v2 tokens in AWS.

Validate and normalize URLs before requests; deny non-HTTP(s) schemes.

Use DNS resolution after redirects to prevent bypasses.

Browser Security Headers & CSP

Set HSTS, X-Frame-Options/Frame-Ancestors, X-Content-Type-Options, Referrer-Policy, and a strict CSP.

Avoid unsafe-inline; use nonces/hashes for scripts; separate origins for untrusted content.

Security headers should be combined with application-layer controls.

HSTS should be preloaded for maximum protection.

CSP should be deployed in report-only mode first to monitor impact.

Kubernetes Admission Policy Recipes

Deny privileged containers/hostPath; require signed images; enforce resource limits and liveness/readiness probes.

Restrict egress via NetworkPolicies; require image pulls from trusted registries only.

Admission controllers can be validating or mutating; Kyverno and OPA Gatekeeper are validating.

Centralize policy sets and version them alongside application code.

Regularly audit policy exceptions.

Namespace A Namespace B Default deny; explicit allow between apps
K8s network isolation
OAuth2 Grant Types (Auth Code + PKCE, Client Credentials, Device Code)

Use Authorization Code + PKCE for public/native clients, Client Credentials for service-to-service, and Device Code for devices without browsers.

Avoid Implicit flow in modern deployments; enforce short token TTLs and refresh rotation.

Auth Code with PKCE is the most secure for public clients.

Device Code flow should poll with exponential backoff to reduce load.

Client Credentials should be combined with mTLS or private network access.

Auth Code + PKCE (Public) Client Credentials (S2S) Device Code (No Browser) Uses redirect + code verifier No user; app identity User types code on another device
OAuth2 grant types
Token Replay Mitigations

Include nonce/timestamp in signatures; bind tokens to TLS channel or client cert where possible.

Use idempotency keys for writes; strictly enforce clock skew and token TTLs.

Use TLS channel binding to tie the token to the session.

Include jti (JWT ID) claims and store them server-side to detect reuse.

Shorten token lifetimes for sensitive scopes.

Data Residency & Sovereignty

Pin data to required regions; avoid cross-region replication unless mandated; govern subprocessors and cross-border transfers.

Test restore/DR within residency constraints and maintain processor SCCs/DPA annexes.

Use cloud provider org policies to restrict resource location creation.

Ensure backups and replicas also comply with residency rules.

Perform annual audits of provider compliance certifications.

Region A Region B Controls Pin primary + backups to compliant regions
Region pinning & controls
SaaS OAuth App Governance Risks

Third-party apps can request broad scopes to read mail, files, and calendars; enforce admin consent workflows and periodic reviews.

Alert on new app installs and dormancy; restrict high-risk scopes.

Review app consent logs monthly.

Restrict risky OAuth scopes like `Mail.ReadWrite` or `Files.ReadWrite.All`.

Educate users on phishing via malicious OAuth apps.

Secrets Management Patterns

Prefer short-lived credentials and workload identities over static secrets.

Centralize secrets in Vault/KMS; inject at deploy; never bake into images or code.

Integrate secret rotation into CI/CD pipelines.

Use sealed secrets for Kubernetes deployments.

Log and monitor secret access attempts.

Supply Chain: SBOM, VEX, and SLSA

Generate SBOMs during build; attach VEX for exploitability; adopt SLSA levels for provenance.

Verify signatures on artifacts and enforce provenance at deploy.

Integrate SBOM generation into the build process.

Continuously monitor SBOM for vulnerable components.

Implement artifact signing with cosign or similar.

Source Build (SBOM) Sign (Cosign) Provenance Deploy (Verify)
Supply chain pipeline
Kubernetes Multi-Tenancy Patterns

Hard multi-tenancy via separate clusters; soft via namespaces + strong NetworkPolicies + ResourceQuotas.

Isolate CI/CD and restrict cluster-admin; use Gatekeeper/Kyverno to enforce policies.

Strongly isolate namespaces and RBAC bindings.

Use network policies to limit cross-tenant communication.

Provide per-tenant monitoring and logging.

Cloudflare API Shield mTLS & Schema Validation

Use client certs for device/server identity; validate schemas at the edge; combine with bot management for abuse control.

Export logs to SIEM for anomaly detection.

Combine API Shield with schema validation to block unexpected fields.

Rotate client certificates regularly.

Use API Gateway upstream as a second enforcement point.

Client (cert) Server (cert) Mutual validation via CA trust
mTLS handshake (edge↔client)
DDoS Overview: L3/4 vs L7

Use provider DDoS protection for volumetric L3/4; WAF/bot for L7 application attacks.

Rate limiting, caching, and surge queues help absorb bursts.

Layer 3/4: SYN floods, amplification attacks.

Layer 7: Slowloris, HTTP floods.

Use autoscaling and rate limiting to absorb surges.