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 token represents scoped authorization to protected resources 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 obtains a token; the token accesses 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: May the authorization server rely on the embedded secret?

Multiple Choice

A JavaScript application runs entirely in a user's browser and contains a fixed client secret in its downloaded code. The server proposes using that value as proof that requests came from the registered client.

A. As a confidential-client credential because the source file is minified B. As extractable; a public client cannot use it as reliable client authentication 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: RFC 6749 Section 2.1 classifies a browser-based application as a public client because its code and credentials are accessible. Section 2.3 says the server MUST NOT rely on public-client authentication for client identification. 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 client uses the authorization code flow through a browser. Its current design accepts any HTTPS callback URI, does not bind the callback to the initiating transaction, and does not bind code redemption to the initiating client instance.

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 Sections 3.1.2.3 and 10.12 cover redirect matching and CSRF protection; RFC 9700 Sections 2.1 and 2.1.1 give the current exact-matching and PKCE guidance.

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. It may be opaque or self-contained and represents a specific scope and duration

**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 9700 Sections 2.1.1, 2.1.2, and 2.4 provide the cited deployment guidance.

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. Treat validity at B's API as proof of every agent identity, runtime property, task parameter, and delegation hop, without any additional profile or local policy B. Apply the authorization server and resource profile's validation and scope rules, then use separate profiled evidence, sender constraining, and local policy for the additional decisions C. Treat TLS channel authentication as authorization for the entire task and disregard the token's scope, resource restrictions, and delegation constraints

**Explanation:** A: OAuth token validity does not automatically prove task semantics, runtime attestation, or a complete delegation chain. B: RFC 6749 Sections 1.4 and 7 leave token format, token attributes, and the resource-server presentation method to companion specifications or a profile. RFC 6749 does not itself require every token to contain issuer and audience fields. An A2A profile must define the applicable validation rules, additional evidence, and acceptance policy; 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: May the authorization server rely on the embedded secret?

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?