OAuth security BCP configuration checker

Use the questionnaire or paste normalized, non-secret settings JSON. Review required changes, recommendations and unknown conditions; this is a static configuration review.

Review non-secret settings locally. No credentials are required, and nothing is uploaded.

How it works

The checker applies selected RFC 9700 rules to declared settings: password grant removal, redirect matching, PKCE, implicit-flow migration, CSRF, mix-up protection and public-client refresh-token protection. It separates required changes from recommendations. Counts are exact; no scoring or rounding is used.

Import uses the normalized format shown in the default example, not a vendor export. Unknown keys are counted as ignored, missing settings remain unknown, and known settings with incorrect types are rejected. Questionnaire answers use the same model. No runtime behavior is verified.

Worked examples

Password grant migration

A public client declaring grant_types=["password"], response_types=[], redirect_uris=[] and refresh_tokens=false has 1 required change: remove the password grant.

Code flow with declared protections

The default public web-client example uses authorization code, S256, confirmed server PKCE support, exact HTTPS redirects, PKCE CSRF protection and refresh-token rotation. It has 0 required changes and 0 recommendations in the implemented checks; runtime enforcement remains untested.

Import format

Supply only these non-secret keys. Omit an unknown value rather than guessing.

  • client_type: public or confidential; application_type: web or native.
  • grant_types, response_types, redirect_uris: arrays of strings.
  • pkce_method: S256, plain or none; redirect_matching: exact, wildcard or prefix.
  • code_injection_protection: oidc_nonce or none. Omit if unknown; used when effective PKCE is not declared. The nonce alternative requires confidential OIDC and all RFC 9700 §4.5.3.2 precautions.
  • csrf_protection: pkce, state, nonce or none.
  • refresh_token_protection: rotation, sender_constrained or none.
  • mixup_defense: issuer, distinct_redirects or none.
  • pkce_server_support, refresh_tokens, multiple_authorization_servers: JSON booleans.

The import limit is 100,000 UTF-8 bytes and 10,000 lines. Each list allows 100 strings of up to 4,096 characters. These are application limits. Do not paste secrets, tokens or private keys.

Frequently asked questions

Does a clean report certify my OAuth deployment?
No. It only reviews declared settings. Token validation, redirect enforcement, CSRF binding, PKCE downgrade prevention, storage and replay detection need runtime testing.
Is PKCE required for confidential clients?
RFC 9700 requires it for public clients using code flow and recommends it for confidential clients. Confidential OIDC clients have a nonce alternative with additional precautions. Code-injection protection remains mandatory independently of CSRF state. Without PKCE, omitted alternative protection is unknown and explicitly absent protection requires a change.
Is the implicit grant completely forbidden?
RFC 9700 says clients should not use access-token authorization responses unless specified injection and leakage mitigations apply. This checker reports a migration recommendation; it cannot establish those mitigations.
Are all HTTP redirect URIs rejected?
Native loopback redirects are an exception. The checker recognizes 127.0.0.1, [::1] and localhost for a declared native client, with a recommendation to use an IP literal instead of localhost.
Can I paste an identity provider configuration export?
Map only the documented non-secret settings into this format. Unknown vendor fields are ignored and reported, so a raw export cannot silently become a clean review.

Sources

Last reviewed 2026-11-14; next review due by 2027-02-12. The method is written out above so you can check our math.