OIDC Discovery Analyzer

Read an OpenID Connect discovery document and check its endpoints, supported algorithms and capabilities for the weak or contradictory settings that surprise people later.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Discovery document Fetch it with curl and paste it here. Analysed in your browser.

Or drop the JSON file

Up to 4 MB. Read locally.

Why it doesn't fetch the URL for you

Every other tool of this kind takes a URL and fetches it. This one asks you to paste the document, for two reasons worth being straight about.

Fetching an arbitrary URL from our server is a server-side request forgery primitive - point it at an internal address and the server becomes a proxy into a network you cannot reach. The site's other tools that genuinely need to fetch go through an SSRF-safe layer that resolves DNS and refuses private ranges, but a discovery document is one curl away and does not need that machinery. Fetching it from your browser instead fails on CORS for most providers anyway.

So: curl https://your-provider/.well-known/openid-configuration, paste, done.

What it checks

PKCE. Whether S256 is advertised at all, and whether plain is still offered alongside it - a client library that picks plain gets no protection, so offering it weakens every client that does.
none as an ID token algorithm. An unsigned ID token proves nothing about who issued it. Graded critical.
Symmetric ID token signing. HS256 signs with the client secret, which means every client that can verify can also mint - and public clients cannot verify at all, having no secret.
The implicit flow and the password grant. Both were deprecated by the Security Best Current Practice and removed in OAuth 2.1. Implicit puts tokens in the URL fragment, where they reach browser history and referrer headers; the password grant trains users to type credentials into applications.
Plain HTTP and internal endpoints, which usually means a development configuration was published by mistake.
Issuer exactness. A trailing slash that does not match the iss claim makes every validation fail, with error messages that rarely explain why.
Public clients with no PKCE - token_endpoint_auth_method: none combined with no code challenge means an intercepted code is redeemable by anyone holding it.

It reads the document, not the deployment

A discovery document is a statement of intent. Whether the provider genuinely rejects unsigned tokens, actually enforces PKCE, or behaves as advertised at its endpoints cannot be established from JSON - so that limitation is reported as its own finding rather than left implied. Test the real flow once you have configured it.

Frequently asked questions

Where do I find my discovery document?

Almost always at /.well-known/openid-configuration under the issuer URL. Some providers also expose /.well-known/oauth-authorization-server for plain OAuth 2.0, which this page reads too.

My provider supports implicit and I can't change it.

You often cannot change what a provider offers, but you control what your clients use. Configure them for authorization code with PKCE - a provider supporting implicit only matters if something actually requests it.

Is RS256 a problem?

No. It is the most widely deployed JWT algorithm and is not broken. PS256 and ES256 are the modern choices and cost nothing to add alongside it, which is why that finding is graded low rather than high.

Why flag a trailing slash on the issuer?

Because issuer validation is an exact string comparison. If the document says https://idp.example/ and tokens carry https://idp.example, every client fails validation and the errors point nowhere useful.

Is my document uploaded?

No. It is parsed and analysed in your browser.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.