Identity & Access Management Quiz

Authentication, authorization, and the identity concepts behind controlling who can access what.

This category currently has 100 questions in the SERVBG quiz bank. Below are a few sample questions — the full interactive quiz shuffles through the whole set with instant scoring.

Sample questions

In the OAuth 2.0 Authorization Code flow with PKCE, what is the purpose of the `code_verifier`?

It is the Base64-encoded client ID used instead of client_secret for public clients.
It is a PKCE-specific client certificate fingerprint sent in the Authorization header during token exchange.
It is a one-time nonce embedded in the JWT access token to prevent replay attacks.
It is a cryptographically random string whose hashed form (code_challenge) is sent at authorization time, then sent in plaintext at token exchange to prove the same client initiated both steps.
It is a shared secret between the client and authorization server used to sign the authorization request.

Which statement about OAuth 2.1 (IETF draft) accurately reflects its current status and a key change from OAuth 2.0?

OAuth 2.1 is still an IETF draft (not a published RFC as of 2025) and mandates PKCE for all authorization code flows, including confidential clients.
OAuth 2.1 mandates mTLS for all grant types and was ratified as RFC 9450 in 2024.
OAuth 2.1 was published as RFC 9700 in 2023 and removed the client credentials grant.
OAuth 2.1 is an approved IETF standard that replaces the implicit grant with device authorization.
OAuth 2.1 is a finalized OASIS standard that deprecates JWT access tokens in favor of opaque tokens.

A public mobile app uses the authorization code flow. Why must it use PKCE even though it also registers a redirect URI?

PKCE is mandatory only when the token endpoint is exposed over HTTP rather than HTTPS.
PKCE replaces the redirect URI entirely for native apps and is not used alongside it.
PKCE is only required when redirect URIs use custom URI schemes; HTTPS redirect URIs are already secure.
PKCE is a server-side mechanism that prevents CSRF and does not protect the client-side code exchange.
A redirect URI alone cannot prevent authorization code interception by a malicious app registered on the same device; PKCE binds the code to the originating client instance via the code_verifier.

What does DPoP (Demonstrating Proof of Possession) add to OAuth 2.0 token usage?

DPoP encrypts the access token payload using the resource server's public key so only that RS can decode it.
DPoP replaces OAuth scopes with capability tokens that are cryptographically signed per resource path.
DPoP binds an access token to a client-held asymmetric key pair; each request includes a signed DPoP proof JWT, making stolen bearer tokens unusable without the private key.
DPoP is a PKCE extension that adds key-pair proof to the authorization code exchange but not to resource requests.
DPoP is a FIDO2 extension used to bind browser sessions to hardware authenticators during token issuance.

An authorization server returns `token_type: Bearer` with an opaque access token. A resource server needs to validate it. What is the standard mechanism?

The resource server contacts the OIDC /userinfo endpoint using the opaque token to retrieve claims.
The resource server verifies the token's HMAC using a shared secret pre-configured at deployment time.
The resource server decodes the token as a JWT and validates the signature using the AS public JWKS URI.
The resource server caches the token locally after first use and revalidates on a 24-hour TTL.
Token introspection (RFC 7662): the resource server sends a POST to the AS introspection endpoint with the token and receives a JSON response indicating active status and metadata.

Start the full quiz ›