Authorization server metadata is parseable
Authored by Stanley Hong · AgentReserve (founder).
When the protected resource metadata advertises one or more authorization servers, at least one of those issuers publishes a parseable RFC 8414 / OpenID Connect Discovery metadata document. This is what tells a client where to send the user, where to fetch tokens, and where to verify signatures.
When this rule runs
Only applies when the server signals that authentication is required (HTTP 401/403). Excluded from the score on public servers.
Why it matters
Naming an authorization server but not publishing its metadata leaves clients unable to discover the authorization, token, or JWKS endpoints. The discovery chain only delivers value end-to-end.
Pass condition
At least one advertised authorization server returned a parseable RFC 8414 or OpenID Connect Discovery document.
Fail condition
An issuer was advertised but no authorization server metadata document parsed successfully.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"issuers": ["https://issuer.example.com"], "parsedAny": false}
Remediation
Publish the authorization server's metadata at `/.well-known/oauth-authorization-server` or `/.well-known/openid-configuration` and make sure it parses as JSON.
Methodology
This rule belongs to the Auth discovery posture dimension. When authorization is required, whether the server cooperates with the standards-based discovery chain — RFC 9728 protected resource metadata, RFC 8414 authorization server metadata, validated issuers, and safe grant types.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.