What is the OpenID Connect discovery document?

It is a JSON file at the issuer URL plus /.well-known/openid-configuration that lists the provider endpoints, the signing keys location (jwks_uri), and the flows, scopes and algorithms it supports. Client libraries read it to configure themselves, so a wrong value there misconfigures every client.

Why does the checker say the fetch failed because of CORS?

The request runs from your browser, so the provider has to send an Access-Control-Allow-Origin header that lets this page read the response. Some providers do not, which says nothing about whether the document is correct. Open the well-known URL in a new tab, copy the JSON and use Paste JSON mode.

Does this tool send my issuer URL to Start with Identity?

No. The fetch goes straight from your browser to the URL you enter, without cookies or a referrer, and the checks run locally. Nothing is sent to our server and nothing is stored.

What does issuer mismatch mean?

OIDC Discovery requires the issuer value in the document to be identical to the issuer URL the client used to find it, and the iss claim in ID tokens must equal that same string. A trailing slash difference is enough for strict clients to reject every token.

Should I disable the implicit flow?

Yes, unless a legacy client still needs it. RFC 9700, the OAuth 2.0 Security Best Current Practice published in January 2025, says clients should not use the implicit grant and should use the authorization code flow with PKCE instead.

Free tool · OpenID Connect · OAuth 2.0

OIDC Discovery Checker

Enter an issuer URL to fetch its /.well-known/openid-configuration and check it against OpenID Connect Discovery 1.0, RFC 8414 and the RFC 9700 security best practice. Background: OpenID Connect explained.

How it works and what to check

The checker builds the well-known URL from the issuer (OIDC appends /.well-known/openid-configuration to the issuer; RFC 8414 inserts /.well-known/oauth-authorization-server between the host and any path), fetches it with fetch() in your browser, and optionally fetches the jwks_uri it names. Every check maps to a requirement or recommendation in a published spec, linked from the result.

What it checks

Required fields. OIDC Discovery requires issuer, authorization_endpoint, token_endpoint (unless only the implicit flow is used), jwks_uri, response_types_supported, subject_types_supported and id_token_signing_alg_values_supported, which must include RS256.
Issuer match and https. The issuer must be identical to the URL you used, and be an https URL with no query or fragment. Every endpoint should be https.
PKCE. RFC 9700 says authorization servers must support PKCE and recommends publishing code_challenge_methods_supported. S256 is the method to use; plain alone fails.
Implicit and password grants. Response types that return tokens from the authorization endpoint without a code are flagged, because RFC 9700 says clients should not use implicit. An advertised password grant fails: RFC 9700 says it must not be used.
Client authentication. A server that offers only client_secret_post is flagged. RFC 9700 recommends asymmetric methods: private_key_jwt or mutual TLS.
ID token algorithms. alg none and HS256 are flagged: unsigned tokens should never reach a client, and HS* tokens are signed with the client secret, which public clients do not have.
Sender-constrained tokens and PAR. RFC 9700 says servers should sender-constrain access tokens. The checker looks for DPoP (dpop_signing_alg_values_supported) or mTLS-bound tokens, pushed authorization requests, and the RFC 9207 iss response parameter used as a mix-up defense.
JWKS. The key set must be reachable and contain only public keys. Private fields (d, p, q) or symmetric oct keys fail; RSA keys under 2048 bits fail; several keys without kid values get a warning.

What it cannot tell you

Metadata is a claim, not proof. A server can advertise S256 and still accept requests without PKCE, or list DPoP and not enforce it for your client. Missing fields often mean "not published" rather than "not supported". Confirm the behaviour with a test client, and validate tokens the way the JWT validation recipe describes.

OpenID Connect standard guide
OAuth 2.1 and OAuth 2.0
Recipe: authorization code flow with PKCE
JWT decoder for the ID tokens this provider issues
OAuth consent phishing

Frequently asked questions

What is the OpenID Connect discovery document?: It is a JSON file at the issuer URL plus /.well-known/openid-configuration that lists the provider endpoints, the signing keys location (jwks_uri), and the flows, scopes and algorithms it supports. Client libraries read it to configure themselves, so a wrong value there misconfigures every client.
Why does the checker say the fetch failed because of CORS?: The request runs from your browser, so the provider has to send an Access-Control-Allow-Origin header that lets this page read the response. Some providers do not, which says nothing about whether the document is correct. Open the well-known URL in a new tab, copy the JSON and use Paste JSON mode.
Does this tool send my issuer URL to Start with Identity?: No. The fetch goes straight from your browser to the URL you enter, without cookies or a referrer, and the checks run locally. Nothing is sent to our server and nothing is stored.
What does issuer mismatch mean?: OIDC Discovery requires the issuer value in the document to be identical to the issuer URL the client used to find it, and the iss claim in ID tokens must equal that same string. A trailing slash difference is enough for strict clients to reject every token.
Should I disable the implicit flow?: Yes, unless a legacy client still needs it. RFC 9700, the OAuth 2.0 Security Best Current Practice published in January 2025, says clients should not use the implicit grant and should use the authorization code flow with PKCE instead.