No insecure grant types advertised
Authored by Stanley Hong · AgentReserve (founder).
The advertised authorization server metadata does not advertise the resource owner password credentials grant or the implicit grant. Both are flagged as insecure by RFC 9700 and by OAuth 2.1, and should not appear on a modern authorization server.
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
RFC 9700 (OAuth 2.0 Security BCP) explicitly forbids implicit and password grants. Advertising them either invites their use or signals that the operator is not following current OAuth security guidance.
Pass condition
No authorization server metadata document advertises `password` or `implicit` in `grant_types_supported`.
Fail condition
At least one authorization server advertises `password` or `implicit` as a supported grant type.
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"insecureGrantTypes": ["implicit"]}
Remediation
Remove `password` and `implicit` from `grant_types_supported`. Use `authorization_code` with PKCE, plus `refresh_token`, for interactive clients.
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.