ToppyMicroServices

RFC 8414 Quiz (EN)

OAuth 2.0 Authorization Server Metadata

ENJA
0 / 0

Primary reference

These questions separate metadata syntax, issuer binding, signer trust, advertised capabilities, and resource authorization. Section numbers refer to RFC 8414.

Q1: What problem does authorization server metadata solve?

Multiple Choice
RFC 8414 Section 2 defines metadata that describes an authorization server's configuration so a client can learn where and how to interact with it. Reading that document neither issues a grant or token nor chooses which issuer a resource should trust. Token validation and the resource's authorization decision therefore remain outside this configuration mechanism.

Q2: Which two defects must the reviewer report?

Multi-Select

A metadata document contains issuer https://as.example?tenant=1 and signed_metadata. It publishes grant_types_supported but omits response_types_supported.

RFC 8414 Section 2 requires an HTTPS `issuer` without query or fragment and a `response_types_supported` JSON array. Signed metadata does not relax the issuer syntax, and another capability field cannot replace a required one. Consumers must distinguish these discovery anchors from optional capability descriptions and field-specific defaults.

Q3: Where is metadata fetched for issuer https://as.example/tenant-a using the default suffix?

Multiple Choice
RFC 8414 Section 3.1 inserts `/.well-known/oauth-authorization-server` between the authority and the issuer path, producing `https://as.example/.well-known/oauth-authorization-server/tenant-a`. Appending the suffix after the tenant path or folding that path into the suffix changes the registered construction. Preserving the issuer path is especially important when one host serves multiple issuers.

Q4: The fetched document returns a different issuer value from the issuer used to build its URL. What should the client do?

Multiple Choice
RFC 8414 Section 3.3 requires the returned `issuer` to be exactly identical to the issuer used to construct the metadata URL and prohibits using a mismatching response. Following a replacement value from inside the document would let that response redirect its own trust target, while registrable-domain similarity is not the specified comparison. The whole metadata response, including endpoint and key-location claims, must be rejected.

Q5: A supported client receives conflicting plain and signed metadata values. Which value has precedence?

Multiple Choice
RFC 8414 Section 2.1 requires processed `signed_metadata` to be signed or MACed, contain `iss`, and take precedence over corresponding plain claims after validation. A consumer that does not support the member may ignore it, but a consumer that chooses to process it cannot merge conflicts into a third value or let TLS replace signature and trust checks. Support, cryptographic validation, signer trust, and precedence are separate steps.

Q6: Which two defaults may the client apply?

Multi-Select

A legacy server omits grant_types_supported, token_endpoint_auth_methods_supported, scopes_supported, and jwks_uri. The client must configure only behavior for which RFC 8414 defines an omission rule.

RFC 8414 Section 2 defines `authorization_code` and `implicit` as the omission default for `grant_types_supported`, and `client_secret_basic` as the default token-endpoint authentication method. By contrast, absence of recommended `scopes_supported` does not mean no scopes are supported, and optional `jwks_uri` does not authorize inventing a location. Only an explicit field definition creates a default; other omitted capabilities remain unknown or need another specified configuration path.

Q7: May this client treat the discovered server as authorized for the A2A resource?

Multiple Choice

A user supplies https://login.attacker.example as an issuer. TLS validation succeeds, the returned issuer matches exactly, and the metadata is syntactically valid. The client has no policy linking that issuer to the requested A2A resource.

RFC 8414 Sections 3.3 and 6.2 protect discovery against substitution relative to the issuer selected as input; they do not establish that this issuer is appropriate for a particular A2A resource. Section 6.4 leaves secure authorization-server-to-resource association out of scope and application dependent. Even complete, valid metadata proves configuration for the chosen issuer, so the client still needs a defined reason to trust that issuer for the target resource.

Q8: How should the client process this signed_metadata object?

Multiple Choice

The metadata contains signed_metadata whose JWS is cryptographically valid and whose iss is unknown to the client. The unsigned JSON claims name a familiar token endpoint, while the signed claims replace it with an unfamiliar host.

RFC 8414 Section 2.1 defines the signed representation and its precedence, but only after the object and its `iss` have been validated. A mathematically valid signature from an unknown key does not authorize that signer to define an issuer's endpoints, and the RFC does not permit synthesizing alternative endpoints when validation fails. The application must establish the signer-to-issuer trust relationship before relying on signed values.

Q9: Which two corrections are required for this multi-tenant discovery flow? Select all that apply.

Multi-Select

For issuer https://as.example/t1, a client fetches https://as.example/t1/.well-known/oauth-authorization-server. It accepts a document whose issuer is https://as.example/t2 because both tenants share a TLS certificate.

RFC 8414 Section 3.1 preserves the tenant path after the well-known suffix, and Section 3.3 separately requires exact equality between the returned issuer and the value used for URL construction. A shared TLS certificate can authenticate the host connection without making `/tenant-a` and `/tenant-b` the same issuer. Both the path-preserving construction and the exact comparison are needed to prevent cross-tenant confusion.

Q10: Which assessment correctly composes discovery, token proof, and backend authorization?

Multiple Choice

RFC 9728 resource metadata lists an authorization server. An A2A client validates that server's RFC 8414 metadata, obtains a grant, and presents a session-bound proof to a gateway. The gateway verifies both and forwards only an unsigned identity header to a backend that owns the resource policy.

RFC 8414 Sections 3.3 and 6.2 authenticate metadata relative to the intended issuer, while Section 6.4 leaves the issuer-to-resource association to the application. Discovery, grant validation, session-bound proof, and backend authorization each have a different verifier and scope; success at one stage does not protect an unsigned internal header or retroactively validate another. The design must preserve the trusted issuer input and protect every derived assertion up to the component that owns the final resource decision.

Q11: Does the received extension name match the registered name?

Multiple Choice

An A2A profile registers the metadata name agent-rôle using precomposed U+00F4. A document contains a visually identical name using U+006F followed by U+0302. The JSON parser has already removed JSON escaping.

A: Section 4 explicitly says Unicode normalization MUST NOT be applied. B: Rendering equivalence is not the specified equality test. C: After removing JSON escaping, compare Unicode code points one for one; these two sequences differ. D: RFC 8414 permits additional metadata parameters and does not create the claimed ASCII-only rule. A profile can constrain its own names, but that would be a separate profile requirement.

Q12: Can the client infer an algorithm for this advertised method?

Multiple Choice

The metadata advertises private_key_jwt in token_endpoint_auth_methods_supported but omits token_endpoint_auth_signing_alg_values_supported. The implementer proposes assuming RS256.

A: Section 2 says servers SHOULD support RS256, but it defines no implicit algorithm when the field is absent. B: When private_key_jwt or client_secret_jwt is advertised, token_endpoint_auth_signing_alg_values_supported MUST be present; the client should not invent an algorithm. C: The authentication-method name does not select one JWS alg value. D: RFC 8414 explicitly supports advertising private_key_jwt; the defect is the missing dependent metadata.