RFC 9700 Quiz

Q1: How should an authorization server compare a registered redirect URI with the request value?

Multiple Choice

A. Use exact matching, with the native-app localhost port exception B. Match any URI under the same registrable domain and port C. Prefix-match the registered URI after percent-decoding its path

**Explanation:** A: Exact matching prevents attacker-controlled URI variations from receiving authorization responses. B: Domain-level matching is too broad and can include attacker-controlled hosts or paths. C: Decoding and prefix matching still admits request URIs that were not registered exactly.

Q2: Why is PKCE important for authorization code flows?

Multiple Choice

A. It encrypts access and refresh tokens stored by that client B. It binds code redemption to the instance that sent the challenge C. It replaces exact redirect checks and client authentication

**Explanation:** A: PKCE binds code redemption to a verifier and is not storage encryption. B: An intercepted code is not redeemable without the corresponding code verifier. C: PKCE does not replace exact redirect matching or client authentication where the latter applies.

Q3: What is RFC 9700's position on the Resource Owner Password Credentials grant?

Multiple Choice

A. Use it whenever a client cannot open a browser B. Use it only with long-lived refresh tokens C. It must not be used

**Explanation:** A: Browser constraints do not remove the credential exposure and phishing risks. B: Refresh-token lifetime does not fix collection of the resource owner's password. C: RFC 9700 prohibits this grant because it exposes credentials and is incompatible with stronger authentication.

Q4: Why should clients generally avoid the implicit grant response?

Multiple Choice

A. Access tokens in the authorization response are more exposed to leakage and replay B. Implicit responses always use stronger sender-constrained tokens C. Implicit responses require exact redirect matching while code flows do not

**Explanation:** A: The authorization code flow allows stronger binding and token-endpoint protections. B: The response type does not automatically sender-constrain the token. C: Exact redirect URI checks are important for both flows.

Q5: A client supports multiple authorization servers. Which control helps prevent mix-up attacks?

Multiple Choice

A. Select the server from an untrusted response parameter after token exchange B. Use issuer identification or distinct redirect URIs and validate the binding C. Reuse one state value for all simultaneous authorization requests

**Explanation:** A: A late untrusted choice lets an attacker confuse endpoint and issuer relationships. B: These mechanisms let the client detect a response from the wrong authorization server. C: Reusing correlation values weakens response-to-request binding.

Q6: A public client receives refresh tokens. Which replay defense should the authorization server use?

Multiple Choice

A. Rely only on the client_id value B. Make refresh tokens permanent so replacements are unnecessary C. Use sender-constrained refresh tokens or refresh-token rotation

**Explanation:** A: Client identifiers are not secrets and do not detect refresh-token replay. B: Longer validity increases the harm of token theft. C: These mechanisms prevent or detect replay of stolen refresh tokens.

Q7: What is the purpose of sender-constraining access tokens?

Multiple Choice

A. Limit use of a stolen token to a presenter that proves possession of the bound key B. Allow the token to be sent over plaintext HTTP without server authentication C. Make audience and resource-server validation unnecessary for every token

**Explanation:** A: The additional proof makes a copied token alone insufficient. B: Sender constraining does not replace TLS confidentiality and server authentication. C: A key-bound token can still be presented to the wrong resource if audience checks are omitted.

Q8: Why must clients and authorization servers avoid open redirectors?

Multiple Choice

A. They prevent token endpoints from using TLS and validating their server certificates B. They can forward authorization codes or tokens to an attacker-controlled URI C. They force every OAuth client to become confidential and hold a static secret

**Explanation:** A: Open redirects concern destination control and are not a TLS capability limitation. B: An open redirect can turn an otherwise trusted URI into a redirect trampoline. C: Client type is independent of whether a redirect endpoint is open.

Q9: Which change directly closes the authorization-server mix-up boundary?

Multiple Choice

A client supports two authorization servers through one redirect URI. It validates state but accepts an untrusted as query parameter on the redirect to choose the token endpoint. It does not validate an issuer identifier in the authorization response or use distinct redirect URIs.

A. Keep the redirect logic and rely on the resource server to detect a wrong issuer later B. Increase access-token entropy without changing how the authorization server is selected C. Validate issuer identification or use distinct redirects bound to the initiating server D. Disable TLS certificate checks so either token endpoint can redeem the returned code

**Explanation:** RFC 9700 Section 4.4.2 defines issuer identification in the authorization response or distinct redirect URIs as mix-up countermeasures. C binds the response to the authorization server selected at flow initiation. state alone does not authenticate that server when the endpoint choice comes from attacker-controlled input. A detects the problem too late, B changes no issuer binding, and D removes server authentication.

Q10: Which control set addresses the replay path without overstating TLS?

Multiple Choice

An agent receives a bearer access token restricted to the payment API's audience. It sends the token through a TLS-terminating gateway, which writes the full Authorization field to a central log. Every hop uses TLS, but a log reader can copy the token and call the same payment API before it expires.

A. Keep full logging because audience restriction prevents replay at the intended API B. Keep bearer tokens because independent TLS hops bind them to the original agent C. Prevent token logging and use a sender-constrained access-token profile where warranted D. Remove the audience restriction and depend only on a shorter bearer-token lifetime

**Explanation:** RFC 9700 Sections 2.2.1 and 4.10.1 recommend sender-constrained access tokens, such as mutual-TLS- or DPoP-bound tokens, to reduce misuse of stolen tokens. Audience restriction remains useful but still permits a copied bearer token at that audience. Hop-by-hop TLS protects tokens in transit, not after a gateway logs them. C removes the avoidable disclosure and, when the threat and ecosystem justify it, makes possession of the token alone insufficient. A, B, and D leave the stated replay path open.

Current OAuth threat mitigations and deployment choices

References

Q1: How should an authorization server compare a registered redirect URI with the request value?

Q2: Why is PKCE important for authorization code flows?

Q3: What is RFC 9700's position on the Resource Owner Password Credentials grant?

Q4: Why should clients generally avoid the implicit grant response?

Q5: A client supports multiple authorization servers. Which control helps prevent mix-up attacks?

Q6: A public client receives refresh tokens. Which replay defense should the authorization server use?

Q7: What is the purpose of sender-constraining access tokens?

Q8: Why must clients and authorization servers avoid open redirectors?

Q9: Which change directly closes the authorization-server mix-up boundary?

Q10: Which control set addresses the replay path without overstating TLS?