OAuth 2.0 vs JWT MCQ 60 Tests With Answers (2026)

Incorrect·B: The expiration time after which the token must not be accepted for processing

The "exp" (expiration time) claim specifies when the JWT becomes invalid. It is represented as a UNIX timestamp (seconds since epoch). The server must reject tokens where the current time exceeds the exp value.

Incorrect·A: Authorization Code Grant

The Authorization Code Grant is the most secure for server-side web applications. It involves a secure backend channel for exchanging authorization codes for tokens, keeping sensitive information (like client secrets) protected.

Incorrect·D: It must make a network request back to the Authorization Server (e.g., an introspection endpoint) to validate the token

Opaque tokens are random strings with no internal structure. To validate them, the Resource Server must contact the Authorization Server's introspection endpoint. JWTs, however, can be validated locally by verifying the signature.

Incorrect·C: The subject of the token, typically the unique identifier for the user

The "sub" (subject) claim identifies the principal entity the token is about, typically the user ID or unique identifier. It is one of the most important registered claims in OAuth/OIDC flows.

Incorrect·A: Resource Owner Password Credentials Grant

The Resource Owner Password Credentials Grant allows the client to directly collect and submit the user's credentials. This flow is discouraged for third-party applications but may be acceptable for first-party apps.

Incorrect·B: It exposes the access token directly in the URL fragment, making it highly vulnerable to interception

The Implicit Grant returns the access token in the URL fragment, exposing it to browsers, JavaScript, and potentially intermediaries. OAuth 2.1 has removed this flow entirely in favor of the Authorization Code with PKCE.

Incorrect·D: It identifies the principal entity that issued the token

The "iss" (issuer) claim identifies who created and signed the token. Typically this is the Authorization Server URL (e.g., "https://auth.example.com"). Clients verify the iss claim matches the expected issuer.

Incorrect·C: Client Credentials Grant

The Client Credentials Grant allows a service to authenticate directly without a user context. It is ideal for server-to-server API calls and backend services that need programmatic access.

Incorrect·A: Changing the payload invalidates the cryptographic signature, causing the server to reject the tampered token

Modifying the payload changes the hash, which invalidates the signature. Without the secret key, an attacker cannot produce a valid signature for the modified payload. This is the core security mechanism of JWTs.

Incorrect·B: It is a temporary, short-lived credential exchanged securely by the backend client for the actual access and refresh tokens

The Authorization Code is a temporary code (typically valid for 10 minutes) returned to the client after user authentication. The client exchanges this code for access and refresh tokens via a secure backend channel.

Incorrect·D: The ID Token

The ID Token is an OIDC-specific token (usually a JWT) that contains identity information about the authenticated user, including claims like "sub" (user ID), "name", "email", etc. OAuth 2.0 alone does not provide this.

Incorrect·C: They are notoriously difficult to instantly revoke before their expiration time (e.g., if a user clicks "log out")

Since JWTs are self-contained and stateless, a server cannot instantly invalidate them. If a user logs out or their permissions change, the token remains valid until expiration. A token blocklist/denylist is required for immediate revocation.

Incorrect·B: To mitigate Cross-Site Request Forgery (CSRF) attacks by maintaining state between the request and callback

The state parameter is a random, opaque value that the client sends in the authorization request and receives back in the redirect. Comparing these values prevents CSRF attacks by ensuring the callback is for the same request.

Incorrect·A: The Authorization Server's Public Key

Asymmetric algorithms like RS256 use public/private key pairs. The Authorization Server signs with its private key; the Resource Server verifies using the public key (fetched from the JWKS endpoint). The public key can be safely distributed.

Incorrect·D: The intended audience (the recipients or APIs) that the token is specifically meant for

The "aud" (audience) claim specifies which service(s) the token is intended for. For example, "https://api.example.com" or ["service-a", "service-b"]. Servers should verify they are in the aud list before accepting the token.

Incorrect·C: It allows a resource server to query the authorization server to determine the active state and metadata of a specific opaque token

The introspection endpoint is defined in RFC 7662. It allows a Resource Server to validate opaque tokens by querying the Authorization Server with the token string and receiving metadata (scope, expiration, user ID, etc.).

Incorrect·D: In the `Authorization` header using the `Bearer` schema

The standard method is the Authorization header with Bearer schema: "Authorization: Bearer <token>". This avoids exposing the token in URLs or cookies where it might be logged or cached.

Incorrect·A: HS256 is a symmetric algorithm using a single shared secret; RS256 is an asymmetric algorithm using a public/private key pair

HS256 (HMAC-SHA256) uses a single shared secret that both parties possess. RS256 (RSA-SHA256) uses asymmetric encryption with a private key for signing and a public key for verification. RS256 is more suitable for multiple Resource Servers.

Incorrect·B: By reading a user code on the restricted device, navigating to a URL on a secondary device (like a smartphone), and authorizing the request there

The Device Flow is designed for IoT and smart TV devices with limited user input. The device displays a code; the user visits a URL on their phone or computer to authorize. This solves the problem of inputting credentials on devices without keyboards.

Incorrect·C: The critical risk of a compromised refresh token being used indefinitely by a malicious attacker

Refresh Token Rotation issues a new refresh token with each token refresh and invalidates the old one. This limits the window of vulnerability if a refresh token is stolen. Combined with proper storage (HttpOnly cookies), it significantly reduces attack surface.

Incorrect·C: To mitigate authorization code interception attacks, particularly for public clients (like SPAs and mobile apps) that cannot safely store a client secret

PKCE (RFC 7636) was designed to protect public clients that cannot securely store a client secret. It uses a code_verifier and code_challenge to prevent authorization code interception attacks.

Incorrect·B: The client creates a dynamic `code_verifier` and sends its hashed `code_challenge` in the initial request, then proves possession by sending the raw verifier when exchanging the code for a token

PKCE uses: (1) S256: code_challenge = BASE64URL(SHA256(code_verifier)), (2) The client sends code_challenge in the auth request, (3) Later exchanges the code with the raw code_verifier, (4) Server verifies the math matches. Even if code is intercepted, attacker lacks the verifier.

Incorrect·A: A JSON data structure that represents a set of public keys, used by resource servers to fetch the keys needed to verify JWT signatures dynamically

A JWKS is a JSON document containing multiple JWK (JSON Web Key) objects representing public keys. Resource Servers fetch the JWKS endpoint (e.g., "https://auth.example.com/.well-known/jwks.json") to dynamically retrieve keys for signature verification.

Incorrect·D: An attacker can strip the signature from the token, set the algorithm to "none", and the server will accept the tampered token as perfectly valid

The "alg: none" vulnerability allows attackers to create unsigned tokens. Vulnerable libraries might skip signature verification entirely. Proper implementations must reject "none" and whitelist allowed algorithms.

Incorrect·C: To provide a unique identifier for the token, which can be utilized alongside a blocklist to detect and prevent replay attacks

The "jti" (JWT ID) claim provides a unique identifier for each token instance. It enables token blocklisting (storing jti values of revoked tokens) to prevent token replay attacks and enable instant revocation.

Incorrect·B: Any malicious JavaScript executed on the page (via XSS) can easily read and steal the token from LocalStorage

LocalStorage is accessible to any JavaScript running on the page, including malicious scripts injected via XSS. If an attacker can inject JavaScript, they can steal tokens from LocalStorage. Secure alternatives include HttpOnly, Secure cookies.

Incorrect·D: Cross-Site Request Forgery (CSRF)

HttpOnly cookies are automatically sent by the browser with every request. If an attacker can craft a request from the user's browser (via a malicious website), the cookie is sent automatically. CSRF tokens or SameSite flags mitigate this.

Incorrect·A: A mechanism that cryptographically binds an access token to a specific client instance's private key, preventing an attacker from using a stolen token on a different machine

DPoP (RFC 9449) requires clients to prove possession of a private key when using the token. Even if an attacker steals the token, they cannot use it without the private key. This provides protection against token theft.

Incorrect·D: It fundamentally breaks the "stateless" advantage of JWTs, forcing microservices to query a shared database or cache to validate every token

Token blocklists require storing revoked token identifiers and checking every incoming token against them. This reintroduces server-side state, adding latency and complexity. Redis or similar fast caches are used to minimize performance impact.

Incorrect·C: JWE provides confidentiality by encrypting the payload content so it cannot be read by third parties, whereas JWS only provides integrity and authenticity via a signature

JWS signs the payload (integrity + authenticity). JWE encrypts it (confidentiality). JWTs are JWS by default. To achieve full confidentiality, JWE must be used, creating an encrypted, signed token.

Incorrect·A: Implicit Grant

OAuth 2.1 removes the Implicit Grant entirely, citing its vulnerability to token exposure in URL fragments. PKCE with Authorization Code flow is the recommended replacement for SPAs and native apps.

Incorrect·B: It is a hint indicating which specific key (from a fetched JWKS endpoint) the server should use to verify the signature

The "kid" (Key ID) parameter in the JWT Header points to a specific key in the JWKS. When multiple keys are available (for rotation), the kid tells the server which public key to use for verification.

Incorrect·D: Token replay attacks against the client application

The nonce is a random value the client sends in the authorization request and expects to receive back in the ID Token. Mismatches indicate a replay or confusion attack. It prevents token replay against the client.

Incorrect·C: Because it resides entirely on the secure backend server and is never exposed to the user's browser or the resource owner

The client_secret is a credential known only to the Authorization Server and the backend Client. It never leaves the backend server, making it safe to use for authentication (unlike public clients like SPAs).

Incorrect·A: By utilizing an API Gateway to accept an opaque token from the frontend and exchange it internally for a JWT before passing the request to backend microservices

The Phantom Token pattern gives the frontend an opaque token (protecting it from XSS), while the backend API Gateway introspects it and retrieves the JWT. This provides both frontend protection and backend efficiency.

Incorrect·B: It allows the Resource Owner to review and explicitly grant or deny the specific scopes requested by the Client application

The consent screen presents the requested scopes to the user, ensuring transparency and explicit authorization. Users can grant or deny specific scopes before issuing tokens. This is fundamental to delegated authorization.

Incorrect·C: Every microservice must possess the shared secret key to validate the token; if any single microservice is compromised, the attacker can forge valid tokens for the entire system

With HS256, every service needs the secret to validate tokens. If any service is compromised, attackers can forge tokens trusted by all services. Asymmetric algorithms (RS256) distribute only the public key, limiting damage.

Incorrect·D: It identifies the time before which the JWT must NOT be accepted for processing by the resource server

The "nbf" (Not Before) claim specifies a UNIX timestamp. The server must reject tokens where the current time is before this value. This prevents tokens from being used before their intended activation time.

Incorrect·A: A scenario where an Authorization Server issues an access token with fewer permissions than the client originally requested, often based on the user's consent choices

Scope downgrading occurs when users deny some requested scopes during consent. The Authorization Server issues a token with only the approved scopes. Clients must handle this gracefully.

Incorrect·B: OAuth CSRF (Login CSRF)

Login CSRF (also called "Cross-Site Request Forgery") happens when an attacker tricks a user into authorizing access with the attacker's account. The user ends up logged into the attacker's account. The "state" parameter prevents this.