RFC 6749 (OAuth 2.0) Quiz | ToppyMicroServices

Q1: Which are the four roles defined by RFC 6749? Select all that apply.

Multi-Select

A. Resource owner B. Client C. Authorization server D. Resource server E. Mandatory network broker

**Explanation:** A: The resource owner is the entity capable of granting access to a protected resource. B: The client requests protected resources on the resource owner's behalf and with its authorization. C: The authorization server issues access tokens after obtaining authorization. D: The resource server hosts protected resources and accepts valid access tokens. E: OAuth does not require a network broker role.

Q2: A client receives an OAuth access token for a photo API. What can be concluded from RFC 6749 alone?

Multiple Choice

A. The client has obtained a standardized end-user identity assertion for login B. The client has a credential representing authorization to access protected resources within its granted scope C. Every resource server must interpret the token as the user's password

**Explanation:** A: OAuth 2.0 is an authorization framework; an authentication layer such as OpenID Connect adds standardized login identity semantics. B: an access token represents authorization with particular scope and duration. C: the abstraction replaces direct password sharing, and token format may be opaque to the client.

Q3: What is the difference between an authorization grant and an access token?

Multiple Choice

A. They are two names for the same credential at every protocol step B. The access token is used to obtain the grant from the resource server C. The grant represents authorization used to obtain an access token; the access token is used at protected resources

**Explanation:** A: they serve different protocol boundaries. B: the direction is reversed and the resource server does not issue the grant in the abstract flow. C: the client presents a grant to the authorization server, then presents the resulting access token to the resource server.

Q4: What is a key security property of the authorization code flow?

Multiple Choice

A. The resource owner authenticates to the authorization server, so credentials need not be shared with the client B. The access token is deliberately placed in the browser redirect before client validation C. The client may exchange any authorization code regardless of which client and redirect URI it was issued to

**Explanation:** A: the authorization server mediates resource-owner authentication and returns a code, keeping the owner's credentials away from the client. B: that describes the exposure risk of the implicit flow, not the code flow. C: codes are bound to the client identifier and redirect URI and are short-lived and single-use.

Q5: A JavaScript application runs entirely in a user's browser and contains a fixed client secret in its downloaded code. How should that secret be treated?

Multiple Choice

A. As a confidential-client credential because the source file is minified B. As extractable; this is a public client and the fixed value cannot securely identify the client C. As the resource owner's password because both values appear in a user agent

**Explanation:** A: obfuscation or minification does not preserve credential confidentiality. B: browser-based and native applications generally cannot keep a shared secret, so the authorization server must not rely on it to identify a public client. C: client credentials and resource-owner credentials are distinct.

Q6: Which controls protect an authorization-code redirect flow? Select all that apply.

Multi-Select

A. Match the redirect URI against a pre-registered URI; current RFC 9700 guidance requires exact string matching except its stated native-app exception B. Accept an arbitrary redirect URI supplied by the browser if it is syntactically valid HTTPS C. Bind the callback to the initiating user-agent transaction using an approved CSRF defense D. Use PKCE as required or recommended by current client-specific guidance

**Explanation:** A: Exact matching against registered redirect URIs prevents an attacker from selecting a credential-receiving endpoint. B: A syntactically valid attacker URI can still exfiltrate a code. C: Binding the callback to the initiating user-agent transaction detects forged or displaced callbacks. D: PKCE makes the code redeemable only with the verifier held by the initiating client instance. RFC 6749 describes `state`-based CSRF protection; RFC 9700 also defines when supported PKCE or OpenID Connect `nonce` can provide that protection.

Q7: Which statement about access tokens is accurate?

Multiple Choice

A. RFC 6749 requires every access token to be a JWT understood by the client B. Every access token is sender-constrained by RFC 6749 itself C. The token may be opaque or self-contained and represents particular scope and duration; presentation methods are defined separately

**Explanation:** A: the token is usually opaque to the client and need not be a JWT. B: RFC 6749 does not automatically bind every token to a sender; bearer use is specified by RFC 6750 and sender constraining needs additional mechanisms. C: RFC 6749 defines the authorization abstraction while companion specifications define use at resource servers.

Q8: Where should a refresh token be sent?

Multiple Choice

A. To the authorization server's token endpoint to request a new access token B. To every resource server on each protected API request C. In the browser redirect URI so intermediaries can renew access

**Explanation:** A: refresh tokens are credentials for obtaining access tokens and are intended only for authorization servers. B: RFC 6749 says they are never sent to resource servers. C: exposing a refresh token in a redirect creates credential leakage; renewal happens at the token endpoint.

Q9: Which statements reflect current OAuth 2.0 security guidance in RFC 9700? Select all that apply.

Multi-Select

A. The resource owner password credentials grant MUST NOT be used B. New clients should prefer the implicit grant because returning a token through the browser removes leakage risk C. Clients SHOULD NOT use the implicit grant unless the stated injection and leakage risks are prevented D. Public clients using the authorization code grant MUST use PKCE; PKCE is also recommended for confidential clients

**Explanation:** A: The password grant exposes resource-owner credentials to the client and is prohibited by RFC 9700. B: Returning an access token in the authorization response introduces leakage and replay risks rather than removing them. C: RFC 9700 says clients should not use implicit unless its stated injection and leakage risks are prevented. D: PKCE is mandatory for public code-flow clients and recommended for confidential clients. RFC 6749 remains the framework baseline, but its historical grant descriptions are not all current deployment recommendations.

Q10: Agent B receives an OAuth access token from Agent A and needs to decide whether to execute a high-impact task. What is the sound conclusion?

Multiple Choice

The token is valid for B's resource API. The design also needs to know which runtime may present it, which task was approved, and whether onward delegation is allowed.

A. Token validity alone proves every agent identity, runtime property, task parameter, and delegation hop B. Enforce the token's issuer, audience, scope, and lifetime, then use separate profiled claims, sender constraining, and local policy for the additional decisions C. Ignore token scope because TLS has already authorized the task

**Explanation:** A: OAuth token validity does not automatically prove task semantics, runtime attestation, or a complete delegation chain. B: OAuth supplies an authorization-token framework; an A2A profile must define the additional claims and acceptance policy, and mechanisms such as mTLS or DPoP can sender-constrain tokens. C: TLS protects a channel but does not replace resource authorization or scope enforcement.

RFC 6749 Quiz

OAuth roles, grants, and token boundaries

References (URLs)

Q1: Which are the four roles defined by RFC 6749? Select all that apply.

Q2: A client receives an OAuth access token for a photo API. What can be concluded from RFC 6749 alone?

Q3: What is the difference between an authorization grant and an access token?

Q4: What is a key security property of the authorization code flow?

Q5: A JavaScript application runs entirely in a user's browser and contains a fixed client secret in its downloaded code. How should that secret be treated?

Q6: Which controls protect an authorization-code redirect flow? Select all that apply.

Q7: Which statement about access tokens is accurate?

Q8: Where should a refresh token be sent?

Q9: Which statements reflect current OAuth 2.0 security guidance in RFC 9700? Select all that apply.

Q10: Agent B receives an OAuth access token from Agent A and needs to decide whether to execute a high-impact task. What is the sound conclusion?