Skip to content
tezvyn:

Top 30 Authentication Interview Questions and Answers

30 multiple-choice questions on Authentication, drawn from 30 bites out of the 78 tagged Authentication on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

  1. Question 1 of 30

    When an app running on Vercel requests a provider token through Vercel Connect at runtime, how does it prove its identity?

    Show the answer

    Answer: d · By using the OIDC identity that every Vercel deployment automatically receives

    Vercel Connect uses the deployment's built-in OIDC identity to exchange for short-lived provider tokens, eliminating persistent secrets. Static env vars (C) are the legacy approach, and while per-user consent flows (A) may come later, they are not the current runtime mechanism.

    Read the full bite: Vercel Connect replaces env tokens with runtime OIDC

  2. Question 2 of 30

    Why is conditionally rendering separate auth and app stacks preferred over calling navigation.navigate after login?

    Show the answer

    Answer: c · State drives which screens exist, so the old stack is unmounted and unreachable

    Declarative conditional rendering ties screen existence to auth state, automatically unmounting unreachable stacks. The navigate approach leaves the login screen on the back stack, which is exactly the bug to avoid.

    Read the full bite: Structuring an auth flow in React Navigation

  3. Question 3 of 30

    For an auth API availability SLI, why should legitimate 401 responses for wrong passwords be excluded from the failure count?

    Show the answer

    Answer: a · Because they represent the system working correctly, not an outage, so counting them penalizes correct behavior

    A 401 for a wrong password is the auth system doing its job, so treating it as downtime would distort the SLI and punish correct behavior. Server-side 5xx and timeouts are the real availability failures to count.

    Read the full bite: Proposing availability and latency SLIs for an auth API

  4. Question 4 of 30

    In FastAPI, which approach best implements a reusable current-user check that preserves OpenAPI docs integration and keeps endpoints testable?

    Show the answer

    Answer: a · Define a get_current_user dependency that uses OAuth2PasswordBearer, validates the token, returns a User model, and inject it into routes with Depends.

    A dedicated get_current_user dependency keeps auth explicit in the signature, auto-documents security in OpenAPI, and enables test overrides via app.dependency_overrides. Middleware hides the dependency from the docs and complicates testing.

    Read the full bite: How do you create a reusable current-user dependency in FastAPI?

  5. Question 5 of 30

    A Python daemon runs nightly without user interaction to pull API data on its own behalf. Which OAuth 2.0 approach should it use to obtain an access token?

    Show the answer

    Answer: b · Use the client credentials grant, authenticating directly to the token endpoint with its client_id and client_secret.

    A daemon acting on its own behalf should use the client credentials grant and authenticate directly to the token endpoint with its client_id and client_secret. The authorization code flow with a stored refresh token is designed for scripts acting on behalf of a user, not for non-interactive service-to-service calls.

    Read the full bite: Implement OAuth 2.0 flow to get an access token for API requests

  6. Question 6 of 30

    Why would an application use a presigned URL instead of proxying a private file download through its own server?

    Show the answer

    Answer: d · To reduce server load and improve efficiency by offloading file transfer.

    The card states that proxying large files through the server is "inefficient and costly" and that presigned URLs allow the browser to download "directly from cloud storage," meaning the server doesn't handle the file stream, thus reducing server load. Option C is incorrect because the client doesn't authenticate with the cloud provider; the presigned URL itself contains the necessary authentication for that specific request.

    Read the full bite: Presigned URLs: Temporary Access to Private Files

  7. Question 7 of 30

    Which scenario best illustrates the appropriate use case for OAuth 2.0 authentication compared to a simple API key?

    Show the answer

    Answer: a · A mobile application requesting access to a user's social media profile on a third-party platform.

    OAuth 2.0 is designed for delegated authorization, allowing third-party applications to access a user's resources with their consent, without sharing the user's credentials. Simple API keys are better suited for trusted server-to-server communication or basic access control where user consent and granular permissions are not required.

    Read the full bite: API Authentication: Who Goes There?

  8. Question 8 of 30

    What is the primary security concern when using docker login with a username and password directly in CI/CD pipelines?

    Show the answer

    Answer: a · The credentials may be exposed in build logs or stored unencrypted.

    Option A is correct because the card explicitly warns that using docker login directly in CI/CD "can expose credentials in build logs" and notes that credentials are often stored unencrypted. Option C is a plausible inconvenience, but the card emphasizes the security risk of credential exposure, not just the lack of automation.

    Read the full bite: Docker Login: Authenticating to a Container Registry

  9. Question 9 of 30

    How should a ProtectedRoute wrapper preserve the original destination when redirecting an unauthenticated user from /dashboard to login?

    Show the answer

    Answer: d · Pass the current location via the state prop on the Navigate component

    The card recommends passing the current location in Navigate's state so the login flow can return the user to /dashboard after authentication. The replace prop only prevents an extra history entry; it does not store the intended destination, making D a common misconception.

    Read the full bite: Implement a protected /dashboard route in React Router

  10. Question 10 of 30

    Why must auth middleware return after sending res.status(401) when the key is invalid?

    Show the answer

    Answer: b · To stop execution so it does not also call next and trigger a double response

    Without returning, the function would continue and could call next, sending a second response and causing a headers-already-sent error. The return simply halts the handler; it does not free memory or reset status.

    Read the full bite: Custom API key auth middleware

  11. Question 11 of 30

    What is the main advantage of using conditional navigators for authentication in React Native?

    Show the answer

    Answer: a · It ensures a clear separation of navigation history, preventing authenticated users from returning to login screens.

    The card states that conditional navigators are crucial because "A logged-in user should never be able to use the hardware back button to return to the login screen," which is achieved by completely swapping navigation graphs. Option C is a common misconception, as the card explicitly advises against using this pattern for conditional UI within an authenticated part of the app.

    Read the full bite: React Native Auth Flows: Conditional Navigators

  12. Question 12 of 30

    Your JWT middleware sends a 401 for bad tokens but crashes with 'Cannot set headers after they are sent'. What is the bug?

    Show the answer

    Answer: b · It calls next() after sending the 401 response

    After responding you must return without calling next(), or the chain continues and a later handler tries to send again. verify (not decode) is exactly what you want for security.

    Read the full bite: Write a JWT authentication middleware

  13. Question 13 of 30

    What bug occurs if a request interceptor injects a header but forgets to return the config object?

    Show the answer

    Answer: a · Axios sends the request with an undefined config, likely throwing or losing all options

    A request interceptor must return the config; omitting the return passes undefined down the chain, breaking the request. Axios does not skip the interceptor or auto-compensate, so the other options are incorrect.

    Read the full bite: Axios interceptors for auth headers

  14. Question 14 of 30

    A SaaS team is building a revenue dashboard in Next.js App Router. They need to ensure unauthenticated users never receive sensitive HTML or data, while avoiding unnecessary edge latency. Which approach aligns with best practices?

    Show the answer

    Answer: c · Use lightweight middleware to catch requests without a session cookie, then validate the token in a server component before fetching data.

    The card emphasizes that the server must gate HTML and data before it ships, and specifically warns against heavy database lookups in edge middleware due to cold-start latency. Option C matches the canonical pattern where lightweight middleware intercepts direct requests and the server component validates the session before any sensitive payload is rendered.

    Read the full bite: Protected Routes: Server Gates, Not Hidden Links

  15. Question 15 of 30

    Why is storing an authentication token in UserDefaults considered insecure even though apps are sandboxed?

    Show the answer

    Answer: d · UserDefaults writes to an unencrypted plist that appears in backups and is readable on jailbroken devices

    UserDefaults persists plain-text to a plist captured in backups and readable on compromised devices, so the sandbox does not protect secrets. It is not shared across apps and the issue is encryption, not size or foreground state.

    Read the full bite: Why store auth tokens in Keychain, not UserDefaults?

  16. Question 16 of 30

    Which approach best secures draft previews on a production frontend while preserving realistic content rendering?

    Show the answer

    Answer: d · Verify the editor via edge middleware, then request the draft through a scoped preview API at request time

    Edge middleware with per-request scoped preview APIs ensures authentication while keeping tokens out of client bundles. Unguessable URLs are a tempting but unsafe shortcut because they rely on secrecy rather than identity verification and leak once shared.

    Read the full bite: Architect a secure draft preview system for a headless CMS

  17. Question 17 of 30

    What is the primary security advantage of Multi-Factor Authentication (MFA) compared to relying solely on a strong password?

    Show the answer

    Answer: b · It ensures that even if a password is compromised, an attacker still needs an additional, different type of credential to gain access.

    The card explains that MFA's purpose is to add a second layer of security, assuming a password will eventually be compromised, thus requiring another factor even if the password is stolen. Option D is incorrect because MFA does not prevent password compromise; it provides protection after it.

    Read the full bite: Multi-Factor Authentication (MFA): Defense in Depth for Logins

  18. Question 18 of 30

    Which pattern best solves the secret zero problem for an app retrieving secrets from Vault in a Kubernetes cluster?

    Show the answer

    Answer: a · Use a projected service account token to authenticate to Vault via the Kubernetes auth method, obtaining a short-lived token through an init container or sidecar

    Projected service account tokens let Vault verify identity through the Kubernetes API, yielding short-lived tokens without hardcoded credentials. Storing a root token in a Kubernetes Secret and mounting it as an environment variable merely shifts the secret zero problem one layer deeper and lacks platform attestation.

    Read the full bite: How does your app authenticate with secrets management and solve secret zero?

  19. Question 19 of 30

    What is the primary function of the Identity Provider (IdP) within a Single Sign-On (SSO) architecture?

    Show the answer

    Answer: c · To authenticate the user once and then issue a cryptographically signed assertion that Service Providers trust.

    The card states the IdP verifies identity and issues an authentication token or cryptographically signed assertion that Service Providers trust. Option A is a tempting distractor, but the IdP's role is authentication and assertion, not acting as a network proxy for routing requests.

    Read the full bite: Single Sign-On (SSO): One Login, Many Apps

  20. Question 20 of 30

    When deploying DMARC, which statement accurately describes how it interacts with SPF and DKIM during validation?

    Show the answer

    Answer: c · DMARC requires at least one aligned pass from SPF or DKIM, linking the result to the From header domain.

    DMARC requires at least one aligned pass from SPF or DKIM against the From header domain to enforce policy, not both simultaneously. The claim that DMARC replaces SPF and DKIM is wrong because DMARC relies on their underlying results rather than performing its own IP or signature validation.

    Read the full bite: Explain SPF, DKIM, and DMARC roles and implementation tasks

  21. Question 21 of 30

    What is the primary way Identity Federation enables a single login for multiple services?

    Show the answer

    Answer: b · It allows services to delegate user authentication to a trusted central provider.

    Identity federation works by allowing Service Providers (applications) to delegate the task of authenticating a user to a trusted Identity Provider. The IdP verifies the user and sends a signed assertion back to the SP, which then grants access. Option A describes user directory synchronization, which federation aims to avoid by not replicating credentials to each service.

    Read the full bite: Identity Federation: One Login for Many Services

  22. Question 22 of 30

    A user logs in successfully, then requests an admin-only endpoint and is rejected. Which HTTP status best fits, and why?

    Show the answer

    Answer: d · 403 Forbidden, because they are authenticated but lack permission

    The user proved their identity (authentication succeeded) but lacks the required role, which is an authorization failure mapped to 403. 401 would imply missing or invalid credentials.

    Read the full bite: Authentication versus authorization in Express

  23. Question 23 of 30

    An attacker decodes a JWT, edits the role claim to admin, and re-encodes it without the secret. What happens at verification?

    Show the answer

    Answer: d · Verification fails because the signature no longer matches the altered payload

    The signature is a keyed hash over header and payload; altering the payload without the secret makes the recomputed signature mismatch, so verification fails. Base64url is just encoding, not protection, and the payload is not encrypted.

    Read the full bite: JWT structure and how the signature works

  24. Question 24 of 30

    When three parallel Dio requests return 401 due to an expired access token, how should an interceptor handle refresh and retries?

    Show the answer

    Answer: d · Lock the queue, perform one async refresh, then let all queued requests resume with the new token

    Locking the queue ensures only one async refresh runs and all queued requests automatically retry with the updated token. Letting each 401 trigger its own refresh causes a thundering herd, while synchronous onRequest checks block the thread and ignore network latency.

    Read the full bite: Explain Dio interceptors and automatic token refresh

  25. Question 25 of 30

    Across five stateless Express instances behind a load balancer, what is the main operational cost of choosing session-based auth over JWTs?

    Show the answer

    Answer: a · You need a shared session store so any instance can resolve the session

    Session state must be reachable by whichever instance handles a request, so a shared store like Redis is required. JWTs avoid that by being self-contained and locally verifiable; sessions absolutely can scale, just with shared storage.

    Read the full bite: Session-based versus token-based authentication

  26. Question 26 of 30

    In a Passport local strategy verify callback, what is the correct way to signal a successful authentication?

    Show the answer

    Answer: d · return done(null, user)

    done(null, user) means no error and supplies the authenticated user, which Passport attaches to req.user. done(null, true) passes a boolean instead of the user object, so the session would lack a usable identity.

    Read the full bite: Securing Express with Passport local strategy

  27. Question 27 of 30

    What does FastAPI automatically do when you inject an OAuth2PasswordBearer instance into an endpoint using Depends?

    Show the answer

    Answer: c · Expect a Bearer token in the Authorization header, return 401 if absent, and add security metadata to OpenAPI docs

    Injecting OAuth2PasswordBearer via Depends tells FastAPI to require an Authorization: Bearer header, automatically return 401 if it is missing, and document the requirement in OpenAPI. Option D is tempting but wrong because the scheme itself does not query a database or return a user object; that requires a separate custom dependency.

    Read the full bite: How do you protect a FastAPI endpoint using Depends and OAuth2PasswordBearer?

  28. Question 28 of 30

    In a secure magic link flow, what must the server do immediately after validating the token?

    Show the answer

    Answer: b · Immediately mark the token consumed and invalidate it before establishing the session

    The token must be treated as a single-use bootstrap, consumed immediately to prevent replay. A reuse window is dangerous because email security scanners may pre-fetch the link, burning the token before the legitimate user clicks.

    Read the full bite: Walk me through a magic link login system and its security considerations

  29. Question 29 of 30

    Which statement accurately describes the structure and security properties of a typical signed JWT's three dot-separated parts?

    Show the answer

    Answer: d · The header specifies the algorithm and token type, the payload carries visible claims such as exp, and the signature provides integrity but not confidentiality.

    The header contains metadata like alg and typ, the payload carries claims such as exp that anyone can read by Base64Url-decoding, and the signature ensures integrity without confidentiality. The most tempting distractor confuses encoding with encryption or swaps the roles of the header and payload, which are exactly the misconceptions the card flags as red flags.

    Read the full bite: What are the three components of a JWT?

  30. Question 30 of 30

    Which storage and verification approach best protects passwords during a total database breach?

    Show the answer

    Answer: b · Hashing with bcrypt using a unique salt per password and constant-time comparison on login

    bcrypt is intentionally slow and one-way, making offline brute force impractical, while unique salts defeat rainbow tables and constant-time comparison prevents timing leaks. SHA-256 with a unique salt is tempting because salting is correct, but the algorithm remains too fast to resist brute-force attacks.

    Read the full bite: How should you store user passwords in a database?

Could you explain these out loud?

That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon