Auth-required server advertises discovery metadata
Authored by Stanley Hong · AgentReserve (founder).
When the server requires authentication (HTTP 401/403 to an unauthenticated probe), it also advertises either a `WWW-Authenticate` challenge or a discoverable `.well-known/oauth-protected-resource` document. This is what allows a client to start a standards-compliant authorization flow without out-of-band documentation.
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
An auth-required server with no discovery metadata forces every client integration to be hand-wired. Standards-based discovery is what lets a client safely start the flow on its own — without it, a server is auth-required in name only.
Pass condition
Auth discovery was attempted, the server returned 401/403, and at least one of WWW-Authenticate or protected resource metadata was observed.
Fail condition
Auth discovery was attempted, the server returned 401/403, and neither WWW-Authenticate nor protected resource metadata was discoverable.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"authRequired": true, "wwwAuthenticate": false, "prmDiscovered": false}
Remediation
Return a `WWW-Authenticate` header on 401/403 responses and publish RFC 9728 `.well-known/oauth-protected-resource` metadata pointing at your authorization server.
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.