OAuth/Authentication Interview Questions for Senior Engineers (2026)

Why OAuth and Authentication Knowledge Matters in Senior Engineering Interviews

Authentication and authorization sit at the foundation of every production system. A single vulnerability in your authentication layer can expose user data, enable account takeover, and result in regulatory penalties that threaten the existence of a company. Senior engineers are expected to understand authentication not as a library they import but as a distributed systems problem with deep security, scalability, and user experience implications.

Interviewers asking OAuth and authentication questions are evaluating multiple dimensions of your expertise. They want to know whether you understand the OAuth 2.0 specification well enough to choose the right grant type for a given scenario, whether you can reason about token security and lifecycle management, whether you have dealt with the operational challenges of running authentication infrastructure at scale, and whether you think about authentication from the attacker's perspective.

At companies like Google, Meta, Okta, and Auth0, authentication systems handle billions of token operations daily. Understanding how these systems work, from the cryptographic foundations to the distributed caching of session state, is what defines senior-level expertise. For foundational knowledge of the protocols discussed in this guide, see how OAuth works, how JWT works, and how SSO works. For comprehensive interview preparation, explore our system design interview guide and learning paths.

1. Explain the OAuth 2.0 Authorization Code flow with PKCE and why it replaced the Implicit flow.

What the interviewer is really asking: Do you understand the evolution of OAuth security, specifically why the Implicit flow was deprecated and how PKCE solves its vulnerabilities?

Answer framework:

The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth 2.0 flow for all client types as of current best practice, including public clients like single-page applications and mobile apps.

The flow works as follows. The client generates a random string called a code_verifier (43-128 characters) and derives a code_challenge by computing its SHA-256 hash (base64url-encoded). The client initiates the authorization request by redirecting the user to the authorization server with the code_challenge. After the user authenticates and consents, the authorization server redirects back to the client with an authorization code. The client exchanges the authorization code for tokens by sending the code along with the original code_verifier to the token endpoint. The authorization server hashes the received code_verifier and compares it with the stored code_challenge. If they match, tokens are issued.

The Implicit flow was designed for JavaScript applications that could not make cross-origin POST requests. It returned the access token directly in the URL fragment (#access_token=xxx). This had critical security problems. The token was exposed in the URL, visible in browser history, server logs, and referrer headers. It was vulnerable to token leakage through open redirector vulnerabilities. There was no mechanism to bind the token to the client that requested it, enabling token injection attacks. And it could not support refresh tokens because there was no secure way to store a long-lived token in a browser.

PKCE solves the code interception attack that was the original motivation for the Implicit flow. Even if an attacker intercepts the authorization code (through a malicious browser extension, compromised redirect URI, or mobile app intent hijacking), they cannot exchange it for tokens because they do not have the code_verifier. The code_challenge sent in the initial request is a one-way hash, so the verifier cannot be derived from it.

A key nuance: PKCE was originally designed for mobile apps (RFC 7636) but is now recommended for all OAuth clients, including confidential clients. This defense-in-depth approach protects against authorization code injection even when client secrets are used. For a comprehensive understanding of the OAuth protocol, see how OAuth works.

Follow-up questions:

• What is the difference between the plain and S256 code_challenge_method, and why should you always use S256?
• How does PKCE interact with client authentication for confidential clients?
• What other security measures should accompany PKCE (state parameter, nonce, etc.)?

2. How would you design a token refresh strategy that balances security with user experience?

What the interviewer is really asking: Do you understand the security trade-offs of token lifetimes, refresh token rotation, and the operational complexity of managing token revocation at scale?

Answer framework:

The core tension is between security (short-lived tokens minimize the damage window if compromised) and user experience (users should not be forced to re-authenticate frequently). A well-designed strategy uses short-lived access tokens (15-60 minutes) paired with longer-lived refresh tokens (days to weeks) with rotation.

For access tokens, use JWTs with a 15-30 minute expiration for most applications. JWTs can be validated locally without a network call to the authorization server, which is critical for low-latency microservice architectures. The short lifetime means that even if a JWT is leaked, the exposure window is limited. For details on JWT structure and validation, see how JWT works.

For refresh tokens, implement rotation: each time a refresh token is used, it is invalidated and a new refresh token is issued alongside the new access token. This limits the lifetime of any individual refresh token to the time between two consecutive refreshes. If a rotated refresh token is reused (indicating it was stolen and the legitimate client already used it), invalidate the entire token family (all refresh tokens for that user/client combination) and require re-authentication.

Store refresh tokens securely on the server side in a database or Redis, not as self-contained JWTs. This allows immediate revocation. When a user changes their password, logs out of all devices, or when suspicious activity is detected, you can invalidate all refresh tokens for that user by deleting them from the server-side store.

For the client-side refresh flow, implement proactive refresh: check the access token expiration before each API call, and if it expires within the next 60 seconds, refresh preemptively. This avoids the latency of a failed request followed by a refresh and retry. Handle concurrent refresh requests by using a mutex so that only one refresh is in flight at a time, and other requests wait for the result.

For sensitive operations (changing email, adding a payment method, viewing financial data), require step-up authentication regardless of token validity. This means the user must re-authenticate with their password or a second factor even if their current session is valid. This is a defense-in-depth measure that limits the damage if an access token is stolen.

Follow-up questions:

• How do you handle refresh token expiration for mobile apps that are not opened for weeks?
• What is the interaction between refresh token rotation and concurrent requests from multiple browser tabs?
• How do you implement token revocation that takes effect within seconds across a distributed system?

3. How does Single Sign-On (SSO) work, and how would you implement it across multiple applications?

What the interviewer is really asking: Do you understand the architecture of enterprise SSO, the protocols involved (SAML, OIDC), and the session management challenges across multiple applications?

Answer framework:

SSO allows a user to authenticate once and access multiple applications without re-entering credentials. The core concept is a centralized identity provider (IdP) that manages authentication and issues identity assertions to service providers (SPs), which are the individual applications.

Two dominant protocols exist. SAML 2.0 (Security Assertion Markup Language) is XML-based, widely used in enterprise environments, and supports complex identity federation. OpenID Connect (OIDC) is built on top of OAuth 2.0, uses JSON/JWT, and is preferred for modern applications. OIDC is essentially OAuth 2.0 plus an identity layer (the ID token, which is a JWT containing user identity claims). For a deep dive, see how SSO works.

The SSO flow with OIDC works as follows. A user visits Application A, which detects no session and redirects to the IdP. The user authenticates at the IdP (which creates an IdP session cookie). The IdP redirects back to Application A with an authorization code. Application A exchanges the code for tokens (access token, refresh token, ID token) and creates its own application session. Later, the user visits Application B, which detects no session and redirects to the IdP. The IdP detects the existing IdP session cookie and redirects back to Application B with an authorization code immediately (no login prompt). Application B exchanges the code for tokens and creates its own session.

The key architectural insight is that there are two levels of sessions: the IdP session (centralized, managed by the IdP) and application sessions (distributed, managed by each application independently). This creates a consistency challenge: when a user logs out of the IdP, how do you invalidate all application sessions?

For single logout, OIDC defines backchannel logout (the IdP sends a logout token to each application's backchannel logout endpoint) and frontchannel logout (the browser loads a hidden iframe for each application's logout URL). Backchannel logout is more reliable because it does not depend on the browser. However, it requires each application to maintain a mapping from IdP session ID to local session ID and support immediate session invalidation.

For enterprise SSO, support SCIM (System for Cross-domain Identity Management) for user provisioning and deprovisioning. When an employee is deactivated in the corporate directory, SCIM notifies all applications to disable the account and revoke all active sessions and tokens.

Follow-up questions:

• How do you handle SSO when one of the applications is a native mobile app?
• What are the security implications of the IdP session having a long lifetime?
• How do you implement SSO for applications that use different identity protocols?

4. How would you design a multi-tenant authentication system?

What the interviewer is really asking: Can you build an authentication system that serves multiple customers (tenants) with isolation, customization, and scalability?

Answer framework:

Multi-tenant authentication must provide strong isolation between tenants (one tenant's data and configuration must never leak to another), customization (each tenant may have different authentication requirements such as MFA policies, password complexity rules, and IdP configurations), and scalability (the system must handle tenants ranging from 10 users to 10 million users).

For tenant identification, determine the tenant from the authentication request. Common approaches: subdomain-based (acme.auth.example.com), path-based (auth.example.com/acme), email domain-based (extract the domain from the user's email), and explicit tenant selection (a dropdown or separate login page). Subdomain-based is the cleanest and allows tenant-specific TLS certificates and cookie isolation.

For data isolation, choose between shared database with tenant_id column (simplest, most cost-efficient, but requires rigorous query-level isolation), database-per-tenant (strongest isolation, highest cost, operationally complex at scale), and schema-per-tenant (middle ground, good isolation within a single database instance). For authentication data, the shared database approach with strict row-level security policies is most common. Use a mandatory tenant_id on every query, enforced at the ORM or database connection level.

For tenant-specific authentication configuration, store per-tenant settings in a configuration store: allowed authentication methods (password, social login, enterprise SSO), password policies (minimum length, complexity requirements, history), MFA requirements (optional, required, specific factors), session durations, and external IdP connections (SAML, OIDC configurations for each tenant's corporate IdP).

For the token strategy, include the tenant_id in all tokens (both JWTs and opaque tokens). This allows downstream services to enforce tenant isolation based on the token alone without an additional lookup. Sign tokens with tenant-specific keys or a shared key with the tenant_id in the claims.

Scale considerations: hot tenants (one large tenant generating disproportionate load) can impact other tenants. Implement per-tenant rate limiting and resource quotas. Consider a dedicated infrastructure tier for the largest tenants (similar to how SaaS companies offer dedicated instances for enterprise customers). Monitor authentication success and failure rates per tenant to detect compromised tenants or misconfigured IdP integrations.

Follow-up questions:

• How do you handle a user who belongs to multiple tenants?
• What is your migration strategy when a tenant needs to be moved to dedicated infrastructure?
• How do you implement tenant-specific branding on the login page without introducing XSS vulnerabilities?

5. What are the security considerations for storing and transmitting JWT tokens?

What the interviewer is really asking: Do you understand the practical security implications of JWTs beyond the theoretical, including storage vulnerabilities, algorithm attacks, and operational security?

Answer framework:

JWT storage location is one of the most debated topics in web security. Each option has trade-offs.

LocalStorage: accessible via JavaScript, vulnerable to XSS attacks. If any script on your page is compromised (third-party analytics, ads, supply chain attack), the attacker can read the token. Simple to implement and works across tabs. Not recommended for tokens with long lifetimes or broad scopes.

HttpOnly cookies: not accessible via JavaScript, immune to XSS token theft. Vulnerable to CSRF attacks (mitigate with SameSite cookie attribute and CSRF tokens). Require careful domain and path scoping. This is the recommended approach for web applications because XSS is a more common and harder-to-prevent attack vector than CSRF.

In-memory (JavaScript variable): not persisted, cleared on page refresh, immune to both XSS token theft (not in storage) and CSRF (not sent automatically). However, requires re-authentication or silent token refresh on every page load. Suitable for high-security applications where the inconvenience is acceptable.

For JWT-specific security concerns, never use the "none" algorithm in production. This was a historical vulnerability where attackers would modify the JWT header to specify algorithm "none" and strip the signature, and poorly implemented libraries would accept it. Modern libraries reject "none" by default, but explicitly configure the allowed algorithms on your validation endpoint.

Prevent algorithm confusion attacks: if your server uses RSA (asymmetric), an attacker could change the algorithm header to HMAC (symmetric) and sign the token with the server's public RSA key (which is public). If the server naively uses the algorithm from the header, it would verify the HMAC using the RSA public key as the HMAC secret, and the signature would validate. Mitigation: never trust the algorithm from the JWT header; always use the algorithm that you configured on the server. For a thorough understanding of JWT mechanics, see how JWT works.

Keep JWT payloads minimal. JWTs are not encrypted by default (they are base64-encoded, not encrypted). Do not include sensitive data (email, phone number, address) in JWT claims unless you use JWE (JSON Web Encryption). Include only the user ID, tenant ID, roles, and token metadata (issued at, expiration, issuer).

Implement token binding when possible. Bind tokens to the client's TLS certificate or device fingerprint so that stolen tokens cannot be used from a different device.

Follow-up questions:

• How do you handle JWT key rotation without invalidating all existing tokens?
• What is the maximum recommended size for a JWT, and what happens when tokens grow too large?
• How do you implement token revocation for JWTs given that they are stateless by design?

6. How would you implement rate limiting for authentication endpoints?

What the interviewer is really asking: Do you understand the specific abuse patterns for authentication endpoints and can you design rate limiting that stops attackers without blocking legitimate users?

Answer framework:

Authentication endpoints are uniquely attractive targets because a successful brute-force attack yields full account access. Rate limiting must be layered and context-aware.

Implement rate limiting at multiple dimensions simultaneously. Per-IP rate limiting: limit the number of authentication attempts per source IP address. A reasonable limit is 20 attempts per minute per IP. This stops basic brute-force attacks but is ineffective against distributed attacks using botnets with thousands of IPs.

Per-account rate limiting: limit authentication attempts per username or email. A reasonable limit is 5 failed attempts in 15 minutes before introducing progressive delays or temporary lockout. This stops targeted attacks against specific accounts but creates a denial-of-service vector: an attacker can lock out any user by intentionally failing authentication attempts with their username.

To mitigate the lockout DoS, use progressive delays instead of hard lockouts: after 5 failures, introduce a 1-second delay; after 10 failures, a 5-second delay; after 20 failures, a 30-second delay. The delays slow down brute-force attacks without fully blocking the legitimate user. Complement with CAPTCHA after a threshold of failures.

Global rate limiting: monitor the total authentication failure rate across all accounts. A sudden spike in failures (10x baseline) indicates a credential stuffing attack using leaked credentials from another service. Response: enable CAPTCHA for all login attempts, increase monitoring, and notify the security team.

For the implementation, use a distributed rate limiter backed by Redis. The sliding window algorithm provides accurate rate limiting: for each dimension (IP, account), maintain a Redis sorted set with timestamps of recent attempts. On each new attempt, remove entries older than the window, count remaining entries, and compare against the threshold.

Differentiate between password-based authentication (needs strict rate limiting) and token-based authentication (less sensitive, higher limits). API key authentication and OAuth token refresh endpoints should have separate, more generous limits.

Log all rate-limited requests with context (source IP, target account, user agent, geographic location) for security analysis. Feed this data into a SIEM (Security Information and Event Management) system for correlation with other security events.

Follow-up questions:

• How do you handle rate limiting when users share IP addresses (corporate NAT, university networks)?
• How do you rate limit OAuth token endpoints without breaking automated client workflows?
• What is the interaction between rate limiting and account enumeration prevention?

7. Explain the differences between authentication, authorization, and identity federation, and how they interact in a modern system.

What the interviewer is really asking: Do you have a clear mental model of the identity layer, and can you articulate how the pieces fit together in a production architecture?

Answer framework:

Authentication answers "who are you?" and verifies the user's identity through credentials (passwords, biometrics, hardware keys, or delegated authentication via OAuth/OIDC). Authorization answers "what are you allowed to do?" and determines the user's permissions for specific resources and actions. Identity federation answers "how do I trust identity assertions from external systems?" and enables cross-organizational authentication.

In a modern microservices architecture, these concerns are typically handled by different systems. Authentication is centralized in an identity provider (IdP) or authentication service that issues tokens upon successful identity verification. Authorization is distributed across services, where each service enforces its own authorization policies based on the claims in the token. Identity federation is handled by the IdP, which supports protocols like SAML and OIDC for accepting identity assertions from external IdPs.

The interaction flow: a user authenticates with the IdP (possibly via federation from their corporate IdP), receives tokens with identity and role claims, and presents the access token to a resource server. The resource server validates the token (authentication check), extracts the claims (identity), and evaluates authorization policies against the claims and the requested resource/action.

For authorization at scale, discuss the evolution from simple role-based access control (RBAC) to attribute-based access control (ABAC) to relationship-based access control (ReBAC). RBAC uses static role assignments (admin, editor, viewer) and works for simple systems. ABAC evaluates policies based on user attributes, resource attributes, and environmental attributes (time of day, IP location), providing fine-grained control. ReBAC models permissions as relationships in a graph (user X is an editor of document Y, and editors can share, so user X can share document Y). Google's Zanzibar system, used for authorization across all Google services, is the canonical ReBAC implementation.

For identity federation, understand the trust model. When your application accepts SAML assertions from a corporate IdP, you trust that IdP to authenticate users correctly. This trust is established through metadata exchange (certificates, endpoints) and configured per tenant. A misconfigured federation trust can allow unauthorized access across organizational boundaries. For details on federation protocols, see how SSO works and how OAuth works.

Follow-up questions:

• How do you handle authorization for resources that span multiple services?
• What is the role of scopes in OAuth, and how do they relate to fine-grained authorization?
• How do you audit and trace authorization decisions in a distributed system?

8. How would you implement passwordless authentication?

What the interviewer is really asking: Do you understand modern authentication methods beyond passwords, including the security model and user experience implications of WebAuthn, magic links, and passkeys?

Answer framework:

Passwordless authentication eliminates the password as the primary authentication factor, replacing it with something the user has (a device, a hardware key) or something the user is (biometrics). This fundamentally improves security because passwords are the most common attack vector: phishing, credential stuffing, brute force, and password reuse all become irrelevant.

WebAuthn/FIDO2 (passkeys) is the leading passwordless standard. The registration flow: the server sends a challenge to the client, the authenticator (fingerprint sensor, Face ID, hardware security key) generates a public-private key pair, stores the private key securely on the device, and returns the public key and signed challenge to the server. The server stores the public key. Authentication: the server sends a new challenge, the authenticator signs it with the private key (after biometric verification), and the server verifies the signature with the stored public key.

Passkeys (synced WebAuthn credentials) solve the device-loss problem by syncing the private key across devices via the platform's cloud keychain (iCloud Keychain for Apple, Google Password Manager for Android/Chrome). This makes WebAuthn viable as the sole authentication factor because users are not locked out when they lose a device.

Magic links are a simpler passwordless approach: the user enters their email, receives a link with a single-use token, clicks the link, and is authenticated. Implementation details that matter: the token must be single-use (delete after first use), time-limited (10-15 minute expiry), cryptographically random (at least 256 bits of entropy), and bound to the requesting session (prevent token forwarding). The security model depends entirely on the security of the user's email account.

OTP (one-time password) via email or SMS is another option but SMS OTPs are increasingly discouraged due to SIM swapping attacks. TOTP (time-based OTP via apps like Google Authenticator) is better because it does not depend on the phone network.

For implementation, support multiple passwordless methods and let users choose. Maintain a fallback path for account recovery (recovery codes generated at registration, stored securely by the user). Monitor authentication method usage to understand adoption and identify issues.

The business case for passwordless: reduced support costs (password resets are a major support volume driver), lower friction (faster login increases conversion), and dramatically improved security posture (no password database to breach).

Follow-up questions:

• How do you handle account recovery when a user loses all their registered authenticators?
• What is the cross-device authentication flow for passkeys, and what are its limitations?
• How do you migrate existing password-based accounts to passwordless without forcing users?

9. How do you prevent and detect account takeover attacks?

What the interviewer is really asking: Do you think about authentication from the attacker's perspective, and can you design defense-in-depth strategies that detect and respond to sophisticated attacks?

Answer framework:

Account takeover (ATO) attacks use stolen credentials, session hijacking, social engineering, or vulnerabilities in the authentication flow to gain unauthorized access to user accounts. A comprehensive defense strategy operates on three levels: prevention, detection, and response.

For prevention, implement credential stuffing protection. Attackers use username/password pairs leaked from other services. Check submitted passwords against known breached password databases (the Have I Been Pwned API's k-anonymity model allows this without sending the full password). Block or flag passwords that appear in breach databases. Implement rate limiting as discussed in question 6.

Prevent phishing by adopting phishing-resistant authentication: WebAuthn/passkeys are bound to the origin (domain), so credentials for example.com cannot be used on evil-example.com. This makes phishing mathematically impossible, not just difficult. For users still on passwords, implement FIDO2 security keys as a second factor.

Prevent session hijacking by binding sessions to client properties. Store a device fingerprint (browser, OS, screen resolution, installed fonts) at session creation. If subsequent requests come from a significantly different fingerprint, require re-authentication. Use the Sec-Fetch headers and client hints to detect suspicious request patterns.

For detection, build a risk scoring engine that evaluates each authentication attempt. Inputs: login location vs historical locations (new country is high risk), device fingerprint vs known devices (new device is medium risk), time of day vs historical patterns (3 AM login for a user who always logs in at 9 AM), authentication velocity (rapid login attempts across multiple accounts from one IP), and impossible travel (login from New York and London within 30 minutes). Output a risk score. Low risk: allow. Medium risk: require MFA step-up. High risk: block and notify the user.

For response, implement immediate automated responses: lock the account after confirmed ATO, invalidate all sessions and tokens, notify the user via a verified backup channel (email, SMS), require identity verification for account recovery (not just an email link), and log the attack details for forensic analysis.

Build a security events pipeline: log all authentication events to a Kafka topic, process them through a stream processing engine for real-time anomaly detection, and store them in a SIEM for historical analysis and compliance.

Follow-up questions:

• How do you balance security friction (MFA challenges, CAPTCHAs) with user experience?
• How do you handle false positives in your risk scoring engine?
• What is your incident response playbook for a large-scale credential stuffing attack?

10. How would you design an OAuth 2.0 authorization server from scratch?

What the interviewer is really asking: Do you understand the OAuth 2.0 specification deeply enough to implement it, including the security requirements, token management, and extensibility for custom grant types?

Answer framework:

An authorization server implements several endpoints and capabilities defined by the OAuth 2.0 specification (RFC 6749) and related RFCs.

Core endpoints: the authorization endpoint (/authorize) handles user-facing flows (authorization code, implicit). It authenticates the user, presents the consent screen, and issues authorization codes. The token endpoint (/token) exchanges authorization codes for tokens, handles refresh token rotation, and supports client authentication. The introspection endpoint (/introspect, RFC 7662) allows resource servers to validate opaque tokens. The revocation endpoint (/revoke, RFC 7009) allows clients to invalidate tokens. The JWKS endpoint (/.well-known/jwks.json) publishes the server's public keys for JWT verification. The discovery endpoint (/.well-known/openid-configuration) publishes server metadata for dynamic client configuration.

For the authorization code store, use a short-lived (10-minute) code stored in Redis with the associated client_id, redirect_uri, user_id, scope, code_challenge (for PKCE), and nonce (for OIDC). Codes must be single-use: delete on first exchange attempt, even if the exchange fails. This prevents code replay attacks.

For token issuance, support both JWT (for stateless validation) and opaque tokens (for revocable tokens). Use JWTs for access tokens in microservice architectures where each service validates tokens independently. Use opaque tokens when you need instant revocation and are willing to accept the latency of token introspection.

For client management, maintain a client registry with client_id, client_secret (hashed, never stored plaintext), allowed grant types, redirect URIs (exact match only, never allow wildcard or open redirects), allowed scopes, and token lifetime configurations. Differentiate between confidential clients (can securely store a secret: server-side applications) and public clients (cannot: SPAs, mobile apps).

For security, implement: PKCE for all authorization code flows, state parameter validation to prevent CSRF, redirect URI exact matching (no subdomain wildcards), client secret rotation without downtime (support two active secrets during rotation), and rate limiting on all endpoints. See how OAuth works for the protocol-level security model.

For scalability, the authorization endpoint is user-interactive and relatively low throughput. The token endpoint handles all token refreshes and is the highest-throughput endpoint. Use connection pooling for database access, cache client configurations in memory (refresh every few seconds), and horizontally scale the token endpoint behind a load balancer.

Follow-up questions:

• How do you implement dynamic client registration (RFC 7591)?
• How would you add support for the Device Authorization Grant (RFC 8628) for TV and IoT devices?
• How do you handle authorization server high availability and disaster recovery?

11. How do you implement fine-grained authorization in a microservices architecture?

What the interviewer is really asking: Can you design an authorization system that works across service boundaries, handles complex permission models, and performs at the latency requirements of production systems?

Answer framework:

Fine-grained authorization in microservices is challenging because permission decisions often depend on data owned by multiple services, and authorization logic must be consistent across all services without creating tight coupling.

Start with the policy enforcement architecture. Three common patterns exist. First, decentralized enforcement: each service implements its own authorization logic. This is simple but leads to inconsistent policy implementation and duplication. Second, centralized policy service: a dedicated authorization service that all services call for every permission check. Consistent but creates a latency bottleneck and a single point of failure. Third, policy distribution: define policies centrally, distribute the compiled policies to each service, and evaluate locally. This combines consistency (central policy definition) with performance (local evaluation). Open Policy Agent (OPA) and Cedar (by AWS) use this pattern.

For the authorization model, choose based on complexity. RBAC (Role-Based Access Control) maps users to roles and roles to permissions. Simple and auditable but does not handle resource-level permissions (user X can edit document Y but not document Z). ABAC (Attribute-Based Access Control) evaluates policies using attributes of the user, resource, and environment. Flexible but policies can become complex and hard to audit. ReBAC (Relationship-Based Access Control) models permissions as relationships between users and resources in a graph. Natural for collaborative applications where permissions derive from organizational structure and sharing.

For implementing ReBAC at scale, study Google's Zanzibar paper. The core idea: store relationship tuples (user:alice, editor, document:123) in a distributed database. To check permission, traverse the relationship graph: alice is an editor of document:123, editors can comment, therefore alice can comment on document:123. Use caching aggressively since permission checks are read-heavy, and relationship changes are relatively infrequent.

For performance, cache authorization decisions at the API gateway level. Use the access token claims (user ID, roles) and the request path/method as the cache key. Set a short TTL (30-60 seconds) to balance performance with freshness. Invalidate the cache when permissions change (publish a permission change event to a pub/sub system).

For auditability, log every authorization decision with the policy version, input attributes, and decision. This is essential for compliance (SOC 2, GDPR) and for debugging "why can't this user access this resource?" questions. For understanding the broader system design patterns, see our system design interview guide.

Follow-up questions:

• How do you handle authorization for cross-service data aggregation endpoints?
• How do you test authorization policies before deploying them to production?
• What is the performance impact of fine-grained authorization, and how do you measure it?

12. How do you implement secure session management in a distributed system?

What the interviewer is really asking: Do you understand the trade-offs between server-side sessions and stateless tokens, and can you design session management that is both secure and scalable?

Answer framework:

Session management in distributed systems requires choosing between server-side sessions (stored in a shared store) and client-side sessions (encoded in a cookie or token). Most production systems use a hybrid approach.

Server-side sessions: generate a cryptographically random session ID (128-bit minimum), store session data in a shared store (Redis is the most common choice), and send the session ID to the client as an HttpOnly, Secure, SameSite cookie. Advantages: session data can be arbitrarily large, sessions can be revoked instantly, and sensitive data never leaves the server. Disadvantages: every request requires a round trip to the session store, the session store becomes a critical dependency, and horizontal scaling requires shared state.

Client-side sessions (JWTs in cookies): encode session data directly in the cookie, signed with HMAC or RSA. Advantages: no server-side state, scales trivially, and no session store dependency. Disadvantages: cannot be revoked without additional infrastructure (a revocation list), size is limited (4KB cookie limit), and all session data is visible to the client (unless encrypted).

The hybrid approach used by most mature systems: use a JWT access token for authentication and authorization (validated locally by each service) paired with a server-side refresh token (stored in Redis for revocation capability). The JWT contains only identity and permission claims (not session-specific data). Application-specific session data (shopping cart, form state, preferences) is stored server-side keyed by user ID.

For session security, implement session fixation prevention: regenerate the session ID after authentication. Implement session binding: associate the session with the client's IP address and user agent, and invalidate if they change significantly. Implement absolute and idle timeouts: absolute timeout forces re-authentication after a maximum duration (for example, 24 hours) regardless of activity; idle timeout expires the session after inactivity (for example, 30 minutes).

For distributed session stores, Redis provides sub-millisecond read latency and built-in TTL expiration. Use Redis Cluster for horizontal scaling and Redis Sentinel for high availability. Replicate the session store across availability zones. Set up monitoring for session store latency, memory usage, and connection count.

Consider the CAP theorem implications: during a network partition, should users be able to continue their sessions (AP) or should sessions fail closed (CP)? For most applications, sessions should fail open (continue working with potentially stale session data) because the alternative is logging out all users during every network blip.

Follow-up questions:

• How do you handle session management across multiple domains (for example, app.example.com and admin.example.com)?
• What is your strategy for session migration during a data center failover?
• How do you implement concurrent session limits (prevent account sharing)?

13. How do you secure API-to-API authentication in a microservices architecture?

What the interviewer is really asking: Do you understand that user-facing authentication is only part of the picture, and can you secure the internal communication between services?

Answer framework:

In a microservices architecture, services communicate with each other extensively. Without API-to-API authentication, a compromised service can impersonate any other service and access any data. Internal authentication is a defense-in-depth measure that limits the blast radius of a security breach.

Mutual TLS (mTLS) is the gold standard for service-to-service authentication. Each service has its own TLS certificate issued by an internal certificate authority (CA). When service A calls service B, both sides verify each other's certificate. This provides authentication (the caller is who they claim to be), encryption (the communication is encrypted in transit), and integrity (the data cannot be tampered with). Service meshes like Istio and Linkerd automate mTLS by injecting sidecar proxies that handle certificate management, rotation, and verification transparently.

JWT-based service authentication is an alternative for environments without a service mesh. Each service has a service account with credentials used to obtain a JWT from a centralized token service. The JWT contains the service identity and is sent in the Authorization header. The receiving service validates the JWT and checks the service identity against an access control list. This approach integrates well with existing OAuth infrastructure.

For authorization propagation, when a user request flows through multiple services, each service needs to know both the calling service identity and the end user identity. Use two tokens: the service token (mTLS or service JWT) for service identity, and the user token (passed through the call chain) for user identity. Each service validates the service token (am I willing to accept requests from this service?) and the user token (is this user authorized for this specific operation?).

For the token propagation pattern, the API gateway authenticates the user, attaches the user JWT, and forwards it to the first service. Each downstream service extracts and validates the user JWT without modifying it. This ensures end-to-end user authentication without requiring each service to re-authenticate the user.

Implement least-privilege access control for service-to-service communication. Define an explicit allowlist of which services can call which endpoints. Service A can call Service B's /users endpoint but not its /admin endpoint. Enforce this at the service mesh level or in the API gateway. For the broader context of securing distributed systems, see our system design interview guide.

Follow-up questions:

• How do you handle certificate rotation for mTLS without downtime?
• What happens when the centralized token service for service JWTs is unavailable?
• How do you audit and trace service-to-service authentication and authorization?

14. How would you implement multi-factor authentication (MFA) that is both secure and usable?

What the interviewer is really asking: Do you understand the spectrum of MFA methods, their security properties, and how to implement MFA without creating friction that drives users to insecure workarounds?

Answer framework:

MFA requires users to prove their identity through multiple independent factors: something they know (password), something they have (phone, hardware key), and something they are (biometrics). The security improvement is multiplicative: if an attacker has a 1 percent chance of compromising a password and a 0.1 percent chance of compromising an MFA factor, the combined probability is 0.001 percent.

Rank MFA methods by security strength. Hardware security keys (FIDO2/WebAuthn) are the strongest: phishing-resistant, no shared secrets, tamper-resistant hardware. TOTP (authenticator apps) is strong: not phishing-resistant (user can enter the code on a phishing site) but not vulnerable to network-based attacks. Push notifications (app-based approval) are moderate: convenient but vulnerable to MFA fatigue attacks where the attacker repeatedly sends push notifications until the user accidentally approves. SMS OTP is the weakest: vulnerable to SIM swapping, SS7 interception, and social engineering.

For implementation, the enrollment flow: after password authentication, present available MFA methods. For TOTP: generate a random secret, encode it as a QR code (otpauth:// URI), have the user scan it with their authenticator app, and verify by requiring two consecutive valid codes. Store the secret encrypted in the database, indexed by user ID.

For the authentication flow, after successful password verification, determine which MFA challenge to present based on the user's enrolled methods and the risk level of the authentication attempt. Implement remember-this-device functionality using a secure device cookie (HttpOnly, Secure, long-lived) that skips MFA for trusted devices. The device cookie should be bound to a device fingerprint and invalidated if the fingerprint changes.

To prevent MFA fatigue attacks on push-based MFA, implement number matching: display a two-digit number on the login screen that the user must enter in the push notification prompt. This proves the user is actively looking at the login screen and not just blindly approving a push.

For recovery, generate 10 single-use backup codes at MFA enrollment. Store them hashed (like passwords). Warn users to store them securely. Implement an admin-assisted recovery path for enterprise users (identity verification by IT, followed by MFA reset). For consumer applications, implement progressive re-verification: start with automated verification (email link to backup email, SMS to backup phone), escalate to identity document verification for high-value accounts.

Follow-up questions:

• How do you enforce MFA adoption across an organization without disrupting productivity?
• What is your approach to MFA for service accounts and automated processes?
• How do you handle MFA in regions where SMS delivery is unreliable and hardware keys are uncommon?

15. How do you handle authentication and authorization for real-time WebSocket connections?

What the interviewer is really asking: Can you bridge the gap between traditional request-response authentication and the unique challenges of persistent, stateful connections?

Answer framework:

WebSocket authentication presents unique challenges because the standard HTTP authentication mechanisms (Authorization headers, CSRF tokens) do not apply after the initial handshake, and the connection may persist for hours while user permissions change. For foundational WebSocket knowledge, see how WebSocket works.

For initial authentication, the most secure approach for web applications is cookie-based authentication during the WebSocket handshake. The browser automatically includes cookies with the upgrade request, so if the user has an active session (HttpOnly session cookie), the server can validate it during the handshake and reject the upgrade with 401 if the session is invalid. This avoids putting tokens in URLs (which appear in logs) and works naturally with existing session infrastructure.

For mobile apps and SPAs that use token-based authentication, generate a short-lived (30-second) WebSocket connection ticket via an authenticated HTTP endpoint. The client includes this ticket as a query parameter in the WebSocket URL. The server validates and consumes (single-use) the ticket during the handshake. This limits the exposure window for the ticket.

For ongoing authorization during the connection lifetime, implement a token refresh protocol over the WebSocket channel. The server tracks the expiration of the user's access token. Before expiration, the server sends a TOKEN_REFRESH_REQUIRED message. The client obtains a new token (via a separate HTTP call to the token endpoint) and sends it over the WebSocket. The server validates the new token and updates the connection's authorization context.

Handle permission changes during the connection. When a user's permissions change (role revoked, subscription expired, banned from a channel), the authorization service publishes a permission change event. The WebSocket gateway subscribes to these events and takes appropriate action: close the connection (for severe changes like account ban), send an error and unsubscribe from the affected channel (for scope reductions), or update the connection's permission cache (for privilege escalations).

For per-message authorization, validate permissions on every incoming message that performs an action. Just because a user was authorized to join a channel does not mean they are authorized to send messages (they might be in a read-only role). Just because they were authorized a minute ago does not mean they still are. The authorization check should be fast (cached policy evaluation, not a database query) but must happen on every actionable message.

Implement connection-level audit logging: log every authentication event (handshake, token refresh, permission change) and every authorization decision (channel subscription, message sent, admin action) with the connection ID, user ID, timestamp, and decision rationale. This audit trail is essential for incident investigation and compliance. For the relationship between OAuth and real-time authentication, see how OAuth works and explore the learning paths for end-to-end preparation.

Follow-up questions:

• How do you handle a mass permission revocation that affects thousands of active WebSocket connections?
• What is your strategy for authenticating WebSocket connections in a serverless environment?
• How do you test authentication and authorization logic for WebSocket endpoints?

Common Mistakes in OAuth/Authentication Interviews

1. Confusing authentication with authorization. Authentication verifies identity (who are you?). Authorization determines permissions (what can you do?). Conflating these concepts signals a lack of fundamental understanding. OAuth 2.0 is an authorization framework; OpenID Connect adds the authentication layer.

2. Recommending the Implicit flow or storing tokens in localStorage by default. The Implicit flow is deprecated. LocalStorage is vulnerable to XSS. Senior engineers should recommend Authorization Code with PKCE and HttpOnly cookies as defaults, then explain when and why you might deviate.

3. Treating JWT as a session mechanism without understanding the revocation problem. JWTs are stateless and cannot be revoked without additional infrastructure (a blocklist or short expiration with refresh tokens). Candidates who propose JWTs without addressing revocation reveal incomplete understanding.

4. Ignoring the operational aspects of authentication infrastructure. Key rotation, certificate management, token store scaling, monitoring authentication failure rates, and incident response for credential breaches are all critical operational concerns that candidates often skip.

5. Not thinking about the attacker's perspective. Security is adversarial. Candidates who only describe the happy path without discussing attack vectors, abuse scenarios, and defense-in-depth strategies demonstrate a gap in security thinking.

How to Prepare for OAuth/Authentication Interview Questions

Start by reading the OAuth 2.0 specification (RFC 6749) and the OAuth 2.0 Security Best Current Practice (RFC 9700). These are the authoritative sources, and understanding them directly, rather than through blog posts, gives you precise language and deep understanding. Supplement with the OpenID Connect Core specification if you are preparing for identity-focused roles.

Build an OAuth 2.0 authorization server from scratch, even a simplified one. Implementing the Authorization Code flow with PKCE, token issuance, refresh token rotation, and token revocation will solidify your understanding of every detail. Many concepts that seem simple in theory reveal complexity in implementation.

Study real-world authentication breaches and incidents. Analyze what went wrong in each case: the Uber data breach (stolen credentials in a code repository), the Microsoft Exchange vulnerabilities (authentication bypass), and the SolarWinds attack (token forging via stolen signing keys). These case studies provide concrete examples of why authentication best practices matter.

Practice explaining authentication concepts to non-security engineers. The ability to clearly explain why PKCE matters, how refresh token rotation works, or what the risk of storing JWTs in localStorage is demonstrates true understanding. For a structured preparation plan, explore our system design interview guide, the learning paths, and pricing for premium preparation resources.

Related Resources

• How OAuth Works
• How JWT Works
• How SSO Works
• How WebSocket Works
• WebSocket vs SSE Comparison
• CAP Theorem Deep Dive
• System Design Interview Guide
• Learning Paths
• Pricing