Comprehensive coverage of methods, protocols, design principles, and practical mechanisms for proving identity and enforcing permissions across systems. Authentication topics include credential based methods such as passwords and secure password storage, Multi Factor Authentication, one time passwords, certificate based and passwordless authentication, biometric options, federated identity and single sign on using Open Authorization, OpenID Connect and Security Assertion Markup Language, and service identity approaches such as Kerberos and mutual Transport Layer Security. Covers token based and session based patterns including JSON Web Token and session cookies, secure cookie practices, token lifecycle and refresh strategies, token revocation approaches, refresh token design, and secure storage and transport of credentials and tokens. Authorization and access control topics include role based access control, attribute based access control, discretionary and mandatory access control, access control lists and policy based access control, Open Authorization scopes and permission modeling, privilege management and the principle of least privilege, and defenses against privilege escalation and broken access control. The description also addresses cryptographic foundations that underlie identity systems including symmetric and asymmetric cryptography, public key infrastructure and certificate lifecycle management, secure key management and rotation, and encryption in transit and at rest. Common threats and mitigations are covered, such as credential stuffing, brute force attacks, replay attacks, session fixation, cross site request forgery, broken authentication logic, rate limiting, account lockout strategies, secrets management, secure transport, and careful authorization checks. Candidates should be able to design authentication and authorization flows for both user and service identities, evaluate protocol and implementation trade offs, specify secure lifecycle and storage strategies for credentials and tokens, and propose mitigations for common failures and attacks.
MediumTechnical
59 practiced
As a Security Architect, design an Attribute-Based Access Control (ABAC) policy set for a document management system where access depends on user role, document sensitivity label, project membership, and time-of-day. Provide sample policy expressions and describe the policy evaluation flow including PIP (attribute provider), PDP (policy decision point), and caching considerations.
Sample Answer
**Situation & goal**Design ABAC policies so document access is decided by user.role, document.sensitivity, user.projects, and current time-of-day. Provide sample expressions and explain evaluation flow including PIP, PDP and caching.**High-level policy set**- Policy 1: Allow if user is document owner.- Policy 2: Allow if user.role in {admin, security_officer} regardless of sensitivity.- Policy 3: Allow if user.role == "employee" AND document.sensitivity == "internal" AND user.projects contains document.project AND time in business_hours.- Policy 4: Deny if document.sensitivity == "restricted" and user.clearance < document.clearance_level.**Sample policy expressions (pseudo / XACML-like)**
pseudo
# Policy 3
Permit if (user.role == "employee")
AND (doc.sensitivity == "internal")
AND (doc.project in user.projects)
AND (timeOfDay >= "08:00" AND timeOfDay <= "18:00")
pseudo
# Policy 4 (deny-overrides)
Deny if (doc.sensitivity == "restricted")
AND (user.clearance < doc.clearance_level)
**Policy evaluation flow**1. Policy Administration Point (PAP): Authors, signs, and publishes policies (versioned).2. Policy Enforcement Point (PEP): Intercepts access request, forms XACML request with subject, resource, action, environment attributes.3. Policy Decision Point (PDP): Receives request, queries PIP for missing attributes, evaluates policies (use combining algorithm: deny-overrides).4. Policy Information Point (PIP): Sources attributes from IdP (roles, clearance), CMDB (project memberships), DMS metadata (doc.sensitivity), and time service (NTP / business calendar).5. PDP returns Permit/Deny/NotApplicable/Indeterminate. PEP enforces and logs decision.**PIP & attribute freshness / caching**- Cache read-only attributes (user.role, doc.sensitivity) with short TTLs: 5–15 minutes. Cache high-change attributes (project membership) with 1–5 minute TTL or use cache-invalidation hooks from HR/ID management.- Sensitive attributes (clearance levels) should be validated more often; consider on-change push from IdP.- Use signed attributes or attribute wrappers to prevent stale-authority attacks.**Performance & safety trade-offs**- Use incremental evaluation and short-circuit deny-overrides to reduce checks.- Audit decisions and include explainable obligations for overrides.- Ensure PDP scales horizontally behind a cache-coherent attribute layer and monitor cache hit rates and decision latency metrics (p50/p95).
HardTechnical
51 practiced
Case study: stolen refresh tokens from a mobile app store leak were used to mint access tokens and access user data. As a Security Architect, outline the incident response: immediate detection and containment steps, revocation and invalidation strategy, forensic data to collect, user communication plan, short- and long-term remediations, and changes to reduce recurrence.
Sample Answer
**Situation & role**As the Security Architect I would lead the technical response, coordinate with IR, legal, product and comms, and own the remediation roadmap.**Immediate detection & containment**- Block abusive traffic: apply WAF rules, rate-limit, geoblock suspicious IPs, and blackhole known attacker IPs.- Disable compromised client(s): temporarily disable the affected mobile client_id(s) in the auth server and app store keys.- Enforce emergency session cutover: force logout for impacted user cohorts and require re-authentication.- Increase visibility: enable verbose auth logging, raise SIEM alerting on token minting anomalies (spikes, new IPs, new device IDs).**Revocation & invalidation strategy**- Revoke all refresh tokens issued to the exposed client_id(s) and any tokens with matching jti/aud/issue timestamps.- Revoke/blacklist access tokens derived from those refresh tokens (use token introspection and revocation endpoints).- Rotate OAuth client secrets and private signing keys if they were exposed — coordinate key rotation rollout to avoid downtime (use key-id header and grace window).- Short TTL for new tokens; require fresh authentication with MFA.**Forensic data to collect**- Auth server logs: token issuance (jti, aud, client_id), introspection, revocation events, timestamps.- API gateway logs: source IPs, user-agent, device fingerprints, geolocation.- Mobile telemetry: app version, device IDs, binary hashes, store download metadata.- Database access logs for sensitive records queried post-compromise.- Application and server filesystem snapshots where tokens/secrets could reside.**User communication plan**- Triage users into impacted vs at-risk; notify impacted users within legal SLA with: - Clear summary of what happened, data types accessed, and timeframe. - Required actions: logout, reset credentials, enable MFA, check account activity. - Offer remediation support: dedicated support line, credit monitoring if PII breached.- Public statement with timeline and FAQs; coordinate with legal and PR.**Short-term remediations**- Force password resets / token invalidation for impacted users.- Enforce MFA for all token exchanges.- Reduce token lifetimes and deploy refresh token rotation (one-time use refresh tokens).- Disable deprecated auth flows on mobile clients.**Long-term remediations & recurrence reduction**- Implement refresh-token rotation with binding to client and device (store refresh token hash server-side).- Enforce PKCE for all mobile/native flows; consider mTLS or app attestation (SafetyNet/DeviceCheck/Attestation APIs).- Token binding or Proof-of-Possession to tie tokens to device keys.- Harden mobile app: code obfuscation, certificate pinning, secure storage (keystore), CI/CD supply-chain controls, reproducible builds and code-sign verification.- Improve monitoring: anomaly/behavioral detection (improbable geolocation, velocity, token replay), automated revocation workflows.- Formalize DevSecOps: secret scanning, periodic pentests, key management lifecycle, and disaster playbooks.**Trade-offs & timeline**- Immediate containment prioritized (hours); forensic and customer notifications (24–72 hrs); key rotations and architectural changes (weeks to quarters).- Balance between user friction (MFA, force reauth) and security risk; use staged rollouts and telemetry to tune.I would present this plan to execs for approval, begin containment within hours, and track KPIs (revoked tokens, unauthorized API calls stopped, time-to-detect, time-to-contain).
MediumTechnical
44 practiced
As a Security Architect, propose defenses against credential stuffing and brute-force attacks for a public login endpoint. Include detection techniques, global vs per-account rate limiting, progressive delays or account lockout strategies, CAPTCHAs, device/IP fingerprinting, false-positive mitigation, and monitoring/alerting integration.
Sample Answer
**Situation & goal** As a Security Architect I'd design layered defenses for the public login endpoint to prevent credential stuffing and brute-force while minimizing user friction.**Detection techniques**- Real-time auth telemetry: failed-login rates, velocity per IP/account, username spray patterns, geolocation anomalies, unusual user-agent combos.- ML anomaly scoring combining features (IP, device fingerprint, time-of-day, username entropy).**Rate limiting: global vs per-account**- Global throttles to slow mass attempts (e.g., 100 req/min per IP block), preventing amplification.- Per-account limits tighter (e.g., 5–10 failed attempts / 15 min) to protect individual users.- Use token-bucket with burst allowances and adaptive backoff tied to risk score.**Progressive delays & lockout**- Progressive exponential delay after consecutive failures (0.5s → 1s → 2s → 5s).- Temporary soft lockouts (cool-down) after threshold; escalate to stronger measures only for high risk.- Automatic account lock only after high-confidence compromise signals; require MFA or verified recovery to unlock.**CAPTCHAs & device/IP fingerprinting**- Show CAPTCHA only when risk score > threshold or after several rapid failures.- Persistent device fingerprinting and IP reputation feeds to block known bad actors; use cookie-binding and local storage signals.**False-positive mitigation**- Whitelist known good IPs (enterprise proxies), adaptive allowlists, secondary challenge (email/MFA) instead of full lock.- Provide clear user UX: email notification with remediation steps before hard lock.**Monitoring & alerting**- SIEM integration for aggregated metrics, thresholds, and playbooks.- Alerts for spikes, persistent low-volume attacks, or targeted attempts on high-value accounts; feed into SOAR for automated containment.- Regular red-team tests and tuning of thresholds to balance security/usability.This layered, risk-based approach minimizes disruption while adapting controls dynamically.
EasyTechnical
59 practiced
As a Security Architect, explain the practical difference between authentication and authorization across web apps, APIs, and service-to-service communication. For each layer (client, API gateway, resource server), describe where identity proofing and permission enforcement should occur, examples of mixing responsibilities that led to failures, and architectural consequences of making the wrong choice.
Sample Answer
**Brief framing**Authentication = proving who/what you are. Authorization = what actions you may perform. In distributed systems these must be separated and placed where trust, scale and least privilege align.**Per-layer responsibilities**- Client (browser/mobile): Identity proofing starts here (password/biometrics, MFA). Client should obtain tokens but must not be authoritative for permissions. Do: store short-lived tokens securely. Don’t: rely on client-side checks for access control.- API Gateway: Central authn/authz entry point — validate tokens, enforce coarse-grained policies (rate limits, scopes, tenant isolation). Good for central logging and uniform rejection. Don’t implement fine-grained business rules here.- Resource Server (microservice): Enforce fine-grained authorization based on authenticated identity and contextual attributes (roles, resource ownership, ABAC rules). Trust gateway’s token validation but re-check permissions for sensitive operations.**Examples of failed mixes**- Gateway performs only token forwarding; services trust it blindly → privilege escalation when gateway bugged.- Client enforces role-based UI hiding only; server accepts client-supplied role → data leakage.- Microservice maintains its own authentication store inconsistent with central IdP → stale creds and outages.**Architectural consequences**Wrong placement causes: increased attack surface, duplicated policy logic, inconsistent decisions, scaling bottlenecks, audit blind spots. Best practice: centralize identity proofing & token issuance (IdP), validate tokens at gateway, enforce resource-level authorization at resource servers with standardized token claims and centralized policy definitions (e.g., PDP/OPA).
MediumSystem Design
49 practiced
As a Security Architect, design an MFA rollout plan for a largely remote workforce that still depends on legacy web applications without modern SSO. Describe architecture options (IdP + gateway/agents), migration phases, fallback/recovery strategies, enrollment, and how you'll measure success while balancing security and usability.
Sample Answer
**Approach summary**Design a phased MFA rollout that protects a remote workforce while preserving access to legacy web apps. Use an IdP as the central auth plane and a combination of gateways/agents to cover modern and legacy apps; deploy adaptive (step‑up) policies to balance security and usability.**Architecture options**- IdP-centric: Cloud IdP (Okta/Azure AD/ForgeRock) for SSO, OIDC/SAML for modern apps.- For legacy apps without SSO: - Reverse proxy / app gateway (Akamai, Azure AD App Proxy, Citrix) to inject authentication and enforce MFA. - Agent-based connectors (web access agents) for on‑prem IIS/Apache apps. - CASB or WAF with authentication integration for SaaS gateways.- Authentication methods: push notifications + FIDO2/WebAuthn (primary), TOTP hardware tokens as fallback; avoid SMS where possible.- Adaptive controls: device posture (MDM), geolocation, risk scoring to trigger step‑up MFA.**Migration phases**1. Discovery & risk mapping: inventory apps, dependencies, authentication flows; classify by risk and auth type.2. Pilot (2–4 weeks): select representative remote users + 2–3 legacy apps behind an app proxy; test enrollment and recovery.3. Phased rollout: high-risk apps/users first (admins, finance), then broad remote workforce in waves. For each wave: - Enable IdP for modern apps. - Place proxy in front of legacy apps, enforce MFA. - Monitor and iterate.4. Harden & optimize: enable adaptive step‑up policies, device posture checks, reduce friction (remembered devices).5. Decommission old auth: remove embedded legacy creds once proxy/agents stable.**Enrollment & UX**- Staged self-service enrollment with guided flows and in-line help.- Offer WebAuthn + platform biometrics, company‑issued tokens for high-risk roles, TOTP app for others.- “Remember device” for managed devices; lower friction for low-risk contexts using adaptive policies.- Training, communications, and on-demand enrollment windows.**Fallback & recovery**- Break‑glass one-time emergency codes stored in vault for admins.- Tiered recovery: automated verification (email + ID proofing) → helpdesk assisted (KBA + manager approval) → in‑person/secure video verification for sensitive accounts.- Temporary access tokens with strict expiry and full audit logging.**Measurement & KPIs**- Adoption rate: % users enrolled per wave and overall.- Auth success/failure rates and false rejects.- Helpdesk MFA tickets per wave and time-to-resolution.- Time-to-access (latency introduced by proxy).- Reduction in risky authentications and account compromise incidents.- Business impact: % apps protected vs baseline and user satisfaction (survey).**Tradeoffs & rationale**- Proxy/agent adds latency and management overhead but permits uniform MFA for non‑SSO apps — acceptable during migration.- Prioritize FIDO2 for security/usability; keep OTP tokens for contingency.- Adaptive policies reduce user friction while maintaining strong security where needed.This plan gives an IdP as the source of truth, uses gateways/agents to cover legacy gaps, stages rollout to reduce operational risk, defines recovery and metrics, and balances security with user experience through adaptive MFA.
Unlock Full Question Bank
Get access to hundreds of Authentication and Access Control interview questions and detailed answers.
