1001Ferramentas
🆔Dev

OIDC Discovery URL Builder

Paste an OpenID Connect issuer URL to get the discovery endpoint, with trailing slashes trimmed and /.well-known/openid-configuration appended for you.

Discovery URL

The OpenID Connect discovery URL

Every identity provider speaking OpenID Connect publishes a discovery document with the endpoint addresses, the public keys, the scopes and the supported algorithms. Knowing the issuer, a client assembles that URL, fetches the document and configures itself — which saves pasting half a dozen addresses by hand into every application.

Enter the issuer and the page assembles the URL. The rule is fixed: the discovery path is appended to the issuer, with no doubled slash. It is worth paying attention because the issuer sometimes already carries a path — with providers hosting multiple logical domains, the issuer may end in something like an organisation identifier, and the discovery path goes after it, not at the domain root.

One detail causes a failure that is hard to diagnose: the issuer value inside the returned document must match exactly the issuer you used to build the URL, including the presence or absence of a trailing slash. The specification requires that check, and serious libraries perform it — the symptom of a mismatch is an invalid-issuer error right after the document downloaded successfully.

Frequently asked questions

Is the path always the same?
For OpenID Connect, yes. For plain OAuth 2.0 there is a different authorisation server metadata path, defined in another specification. Several providers publish both documents, with similar but not identical content.
Can I cache the document?
You should, and libraries do. The caution is the public keys, which live at another address named in the document and are rotated periodically — caching them too long causes token validation failures when rotation happens. The standard approach is refetching on encountering an unknown key identifier.
What is most useful in the document?
The authorisation, token and userinfo endpoints, the key set address, the supported scopes and response types, and the accepted signing algorithms. It is where you find out, for instance, whether the provider supports the authorisation code protection extension.

Related Tools