OIDC Discovery Inspector
Enter an issuer to fetch its .well-known/openid-configuration. See every endpoint and supported feature at a glance, catch configuration problems like issuer mismatches and missing PKCE, and check its signing keys — all from your browser.
An issuer (for Keycloak, https://host/realms/your-realm) or a full .well-known/openid-configuration URL.
What is OpenID Connect discovery?
Instead of configuring every endpoint by hand, OpenID Connect clients are given one URL — the issuer — and fetch {issuer}/.well-known/openid-configuration to learn the rest. The discovery document lists the authorization, token, UserInfo, and logout endpoints, the jwks_uri holding the provider's signing keys, and what the provider supports: response types, grant types, scopes, claims, client authentication methods, signing algorithms, and PKCE methods.
Because so much depends on it, a small mistake in the discovery document — the wrong host in the issuer, a missing PKCE method — can break every client at once. This inspector reads it the same way a client library would and points out what to fix.
What this tool checks
- Issuer match — the
issuermust equal the URL you fetched it from, character for character. - Required metadata — authorization and token endpoints,
jwks_uri, and the supported response types, subject types, and ID token algorithms. - https everywhere — every endpoint must use TLS outside local development.
- PKCE —
S256incode_challenge_methods_supported. - Unsafe algorithms —
nonefor ID tokens, or HMAC-only signing. - Lifecycle endpoints — end session (logout), revocation, and introspection.
- Signing keys — the
jwks_uriis fetched and every key is checked, the same as in the JWKS Verifier.
Implicit-flow response types and the password grant are noted rather than failed: advertising them is normal for general-purpose providers, but RFC 9700 recommends authorization code with PKCE. See OAuth security best practice for Keycloak for how to enforce that per client.
Keycloak discovery and the issuer
Each Keycloak realm is its own issuer: https://your-host/realms/{realm}. The discovery document is at /realms/{realm}/.well-known/openid-configuration and the keys at /realms/{realm}/protocol/openid-connect/certs. The tool recognizes Keycloak issuers automatically and adds notes specific to them.
The most common Keycloak discovery problem is an issuer mismatch. Keycloak does not store the issuer; it computes it from its hostname configuration, or, when that is not set, from the request. Behind a load balancer or reverse proxy that means the issuer can come out as an internal hostname or as http unless proxy headers are enabled (proxy-headers). A realm's Frontend URL setting overrides the hostname for that realm only. If the issuer here differs from what your clients are configured with, align the hostname setup first — tokens will carry the same value in their iss claim.
Also check the /auth prefix. Keycloak 17 and later serve from the root by default; older versions, and newer ones configured with http-relative-path=/auth, include it. The prefix is part of the issuer, so moving between the two changes the issuer for every client.
Learn more
- Keycloak client types — public vs. confidential clients and when PKCE applies.
- OAuth security best practice (RFC 9700) for Keycloak — enforce PKCE and disable legacy flows.
- JWT Decoder — decode a token and compare its
issto the issuer here. - Keycloak overview — how Phase Two hosts and runs Keycloak.
Frequently asked questions
What is the OpenID Connect discovery document?
OpenID Connect Discovery 1.0 defines a JSON document, served at {issuer}/.well-known/openid-configuration, that describes a provider: its issuer, endpoints (authorization, token, userinfo, logout, and more), the location of its signing keys (jwks_uri), and the response types, grant types, scopes, claims, and algorithms it supports. Client libraries read it so you only need to configure the issuer URL.
Where is the Keycloak well-known URL?
For a Keycloak realm it is https://your-host/realms/{realm}/.well-known/openid-configuration. Deployments on Keycloak 16 or earlier, or configured with http-relative-path=/auth, use https://your-host/auth/realms/{realm}/.well-known/openid-configuration. Enter the realm URL here and the tool builds the discovery URL for you.
Why must the issuer match exactly?
The issuer in the discovery document must be identical to the URL used to fetch it, and to the iss claim in every ID token. Clients compare them as exact strings — a trailing slash, a different host, or http vs. https is enough for a library to reject the provider or its tokens. This guards against one provider impersonating another.
Why does Keycloak report the wrong issuer?
Keycloak builds the issuer from its hostname configuration. If the hostname option is not set, it uses the host of the incoming request, which behind a reverse proxy may be an internal name unless proxy headers are enabled (proxy-headers=xforwarded or forwarded). A realm Frontend URL overrides the hostname for that realm. When tokens show an unexpected iss, fix those settings rather than the clients.
What is PKCE and why check for S256?
Proof Key for Code Exchange (PKCE, RFC 7636) binds an authorization code to the client that requested it, so a stolen code is useless. Providers advertise support in code_challenge_methods_supported. S256 hashes the verifier and is the method to use; plain sends it as-is and offers little protection. RFC 9700 recommends PKCE for all clients.
Why does fetching the discovery document fail in the browser?
A web page can only read a cross-origin response if the server sends CORS headers. Keycloak sends them for any origin on its discovery and certs endpoints, so a block usually means the realm does not exist (its 404 has no CORS headers), the /auth prefix is wrong, or a proxy or WAF in front of Keycloak interferes. You can always open the URL in a tab and paste the JSON instead.
Is anything sent to Phase Two?
No. Your browser fetches the discovery document and JWKS directly from the issuer you enter, and all linting runs locally in JavaScript. There is no proxy, and nothing is logged or stored.
Does this work with providers other than Keycloak?
Yes. Any OpenID Connect provider that publishes a discovery document works — for example Google, Microsoft Entra ID, Okta, or Auth0, provided the provider allows browser requests. Keycloak issuers get extra notes on realms, hostname configuration, and key management.
Can I share a link to a result?
Yes. After a fetch, use Copy share link. The link looks like /tools/oidc-discovery#url=https%3A%2F%2Fissuer.example.com%2Frealms%2Fdemo and re-runs the check when opened. Only the issuer is included — never a token or pasted JSON — and it sits in the URL fragment (after #), which browsers do not send to the server, so it does not end up in server logs.