An integration can fail before sign-in even begins if the client has the wrong authorization or token endpoint. Discovery metadata gives the server a machine-readable place to publish those locations and describe its supported capabilities.
The document helps a client configure the next request. It does not register the client or grant access. Keeping configuration separate from authorization makes it easier to identify which part of an integration needs attention.
RFC 8414 is configuration metadata
RFC 8414 defines OAuth 2.0 authorization-server metadata as a JSON document retrieved from a well-known location. The document "declares its endpoint locations and authorization server capabilities" (Internet Engineering Task Force, "RFC 8414").
The required and conditional fields reinforce the boundary. RFC 8414 requires an HTTPS issuer value without query or fragment components. It describes fields such as authorization_endpoint and token_endpoint, with requirements that depend on supported grant types (Internet Engineering Task Force, "RFC 8414"). A scanner that checks only issuer shape has not validated every semantic rule in the standard.
Even a fuller metadata document would still stop short of access. It can tell a client where to begin. It cannot prove that the client is registered, that the requested redirect URI is accepted, that the user or authorization step succeeds, that a token is returned, or that a protected resource accepts the token for a particular request.
Match OIDC configuration to its issuer
OpenID Connect Discovery uses the related /.well-known/openid-configuration path for OpenID Providers that support discovery. The returned issuer value must match the issuer URL used to form the request (OpenID Foundation).
That issuer consistency rule is important. It helps a relying party bind the configuration document to the issuer it meant to inspect. It still does not prove that any relying party can complete sign-in. A working OIDC integration also needs client configuration, redirect handling, authentication, consent or policy results, token handling, and whatever application checks happen after the identity response.
Protected-resource metadata is a different document
RFC 9728 defines OAuth protected-resource metadata. The protected-resource document is resource-centered: resource is required, while authorization_servers is optional (Internet Engineering Task Force, "RFC 9728").
In the RFC's example flow, a client discovers resource metadata, obtains authorization-server metadata, completes an authorization exchange, receives an access token, and later repeats the protected-resource request with that token (Internet Engineering Task Force, "RFC 9728"). Each step can fail independently; finding the first document does not test the later requests.
That means a resource metadata file is not the same artifact as authorization-server metadata. Neither file, by itself, proves bearer-token acceptance. If the claim is access, the evidence has to include the authorization and resource-request steps, not just discovery.
What MachineRead checks
MachineRead keeps those document classes separate in the target-audit probe list. It checks /.well-known/oauth-authorization-server and /.well-known/openid-configuration for OAuth/OIDC discovery metadata. It checks /.well-known/oauth-protected-resource as a separate protected-resource metadata surface.
MachineRead performs a minimum-shape check. For authorization metadata, MachineRead's bounded validator accepts a JSON object only when issuer is an HTTPS URI without query or fragment. Optional fields are outside this minimum check.
For protected-resource metadata, the validator requires an HTTPS resource URI and permits authorization_servers to be absent. When authorization_servers is present, it must be a nonempty list of HTTPS issuer URIs.
Those checks are useful audit signals. They can say the target returned a document that cleared a minimum discovery-shape screen. They cannot say the target passed full RFC 8414, OIDC Discovery, or RFC 9728 conformance. They also cannot say a token flow or protected-resource call worked.
How to read an OAuth discovery finding
Start with the issuer you intended to inspect. Compare it with the returned issuer, then examine the authorization and token endpoints. A configuration copied from a staging environment may be well-formed JSON while directing a production client to the wrong service.
Next, review the fields required by the relevant specification and the flows you actually support. MachineRead's minimum document screen cannot replace that review. Only after configuration is consistent should an authorized integration test proceed through registration, redirect handling, token issuance, and a protected request.
Keep credentials out of discovery documents and test logs. The purpose of public metadata is to explain how to reach and configure the authorization system, not to distribute access to it.
Works Cited
Internet Engineering Task Force. "OAuth 2.0 Authorization Server Metadata." RFC 8414, June 2018, RFC Editor, https://www.rfc-editor.org/rfc/rfc8414.html. Accessed 9 Sept. 2026.
Internet Engineering Task Force. "OAuth 2.0 Protected Resource Metadata." RFC 9728, RFC Editor, https://www.rfc-editor.org/rfc/rfc9728.html. Accessed 9 Sept. 2026.
OpenID Foundation. "OpenID Connect Discovery 1.0 Incorporating Errata Set 2." OpenID, Dec. 2023, https://openid.net/specs/openid-connect-discovery-1_0.html. Accessed 9 Sept. 2026.
See also
- Methodology reference - separates discovery observations from runtime guarantees
- What an A2A agent card is for - another metadata-versus-runtime boundary
- A WebMCP manifest is not a working tool - a parallel discovery-versus-execution distinction