Summary

  • RFC 9728 lets a protected resource publish metadata about how to interact with it; the document is a discovery input, not a grant to call the resource.
  • A client must validate the exact resource identifier before using returned metadata. Even then, token issuance, token acceptance, application policy and observed effect remain separate decisions.

“The resource told us which authorization server to use” is an easy sentence to over-read. It can mean that a client has found a JSON document, that the document names one or more issuer identifiers, and that a later authorization flow may be worth attempting. It does not mean that the named issuer will issue a token, that the token will be for this resource, that this resource will accept it, or that the requested operation is presently allowed.

RFC 9728 puts useful discipline around that first step. A protected resource can publish metadata at a .well-known location derived from its resource identifier. The document can describe the resource, list authorization servers, disclose supported scopes, identify bearer presentation methods and provide other configuration material. This makes discovery more interoperable. It does not collapse the roles that discovery connects.

The decisive safeguard is exactness. The metadata response carries a required resource value. For ordinary discovery, that value must be identical to the resource identifier used to derive the metadata URL; otherwise the returned data must not be used. When the metadata URL came from a WWW-Authenticate response, the value must instead be identical to the URL the client used to request the resource. The rule does not ask whether two strings feel adjacent, share a host, or describe the same product family. It prevents a metadata document from borrowing authority by resemblance.

That boundary matters especially where one host serves many paths or tenants. RFC 9728 deliberately inserts the well-known suffix before a resource path so that different protected resources can publish different documents. It says that this use of .well-known is not general information about the host. A team that treats host-level discovery as a blanket permission map can therefore point a client toward the wrong policy domain before any token is even requested.

The advertised lists are bounded statements too. authorization_servers is optional, and a resource may decline to advertise some supported authorization servers. scopes_supported is likewise recommended rather than exhaustive. An operator should read those fields as published interoperability information, not as a complete entitlement catalogue. A listed scope still has to be requested, evaluated and embodied in an issued credential; an unlisted server or scope is not automatically impossible. The metadata document does not decide either question.

Signed metadata strengthens one claim without strengthening every later claim. RFC 9728 permits signed metadata as a JWT whose issuer attests to metadata values, subject to validation. That can help a recipient establish who vouched for a bundle of discovery facts. It does not turn the signature into client authentication, user consent, resource-server token validation or an application-level commit. The verifier of metadata, the authorization server that issues a token, the resource server that validates it and the application that performs an irreversible action still have different evidence and different failure modes.

WWW-Authenticate illustrates the same restraint. A protected resource can return a resource_metadata URL in a challenge response. The client can retrieve the document, obtain authorization and return with an access token. The sequence is intentionally useful. Yet the initial challenge is not an admission signal, and metadata retrieval is not the final request. RFC 6750, RFC 8707 and RFC 8414 distribute bearer presentation, resource targeting and authorization-server metadata across different surfaces. RFC 9728 adds a protected-resource discovery surface; it does not make one surface sovereign over the others.

For an operating record, preserve the chain: requested resource URL; derived or challenged metadata URL; fetched document and cache age; exact resource-identifier validation; selected authorization server; authorization result; issued token and audience/scope; resource-server validation; application preconditions; request receipt; and observed effect. These are not duplicate logs. They answer different questions. Treating discovery as a green authorization status erases the very distinction the protocol was built to preserve.

Sources