OIDC Discovery Tool
Test and validate OpenID Connect discovery endpoints and configurations
/.well-known/openid-configuration
(sometimes called the “well-known” URL). This is not your
app’s redirect URI, login page, or API base URL; it is the
address your library or docs refer to for OIDC discovery.
Discovery Document
LoadedEndpoint Analysis
Configuration Summary
Issuer
-
Supported Scopes
Response Types
Grant Types
Understanding OIDC Discovery
How OpenID Connect Discovery simplifies integration
What is OIDC Discovery?
OIDC Discovery is a mechanism that allows clients to dynamically discover OpenID Connect provider configuration and endpoints through a well-known URL.
Configuration Details
The discovery document contains essential information like authorization endpoints, token endpoints, supported scopes, and cryptographic keys.
Easy Integration
Discovery eliminates manual configuration by automatically providing all necessary endpoints and capabilities, making OIDC integration simpler and more reliable.
What the discovery document tells you
The endpoints
Every OpenID Connect provider publishes metadata at /.well-known/openid-configuration. It names the authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, and usually end_session_endpoint for logout.
Fetching this rather than hardcoding endpoints means your integration survives the provider moving or renaming a path. It also means you can point the same client code at a different provider by changing one issuer URL.
The capability fields
scopes_supported, response_types_supported, and grant_types_supported tell you what the provider will actually accept — useful for confirming that the flow you're planning is available before you build against it.
id_token_signing_alg_values_supported lists the algorithms used for ID tokens, and code_challenge_methods_supported tells you whether S256 PKCE is available. If S256 isn't listed, that provider is one to be wary of.
Validating the issuer
The issuer field in the document must exactly match the iss claim in tokens the provider issues, and must match the URL you fetched it from (minus the well-known path). A mismatch is a red flag and the spec requires you to reject it.
This matters for mix-up attacks, where a client talking to several authorization servers is tricked into sending a code from one to another. Checking that iss matches the issuer you initiated the flow with is the defence.
Frequently asked questions
Every AuthAction tenant ships a discovery document
Standards-compliant .well-known/openid-configuration, JWKS, and rotation from day one — nothing to assemble by hand.
Free, unlimited users. No credit card required.