OIDC Discovery Tool

Test and validate OpenID Connect discovery endpoints and configurations

Enter the full HTTPS URL of your OpenID Provider’s discovery (metadata) document. the JSON served at /.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.
Please enter a valid URL.

Discovery Document

Loaded

Endpoint 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

At the issuer URL plus /.well-known/openid-configuration. If the issuer is https://auth.example.com, the document is at https://auth.example.com/.well-known/openid-configuration. Note that the path is appended to the full issuer including any path component.

They are near-identical documents from different specs. OIDC Discovery came first; RFC 8414 later defined OAuth 2.0 Authorization Server Metadata at /.well-known/oauth-authorization-server. Many providers serve both, with overlapping fields.

Some providers don't send permissive CORS headers on the discovery endpoint, which blocks a browser-based fetch. That's a provider configuration choice, not a fault in the document. Server-side clients are unaffected; you can also fetch it with curl to inspect it.

It points at the JSON Web Key Set containing the public keys for verifying signed tokens. Your verifier fetches it, matches the token's kid header against a key, and verifies with that key. Cache it, but respect Cache-Control and refetch on an unknown kid so key rotation doesn't break you.

No. Fetch it at startup and cache it, refreshing periodically. It changes rarely. The jwks_uri contents change more often than the document itself, so cache the key set separately with a shorter lifetime.

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.