Auth0 vs Okta vs AWS Cognito: OIDC Discovery Endpoint Differences Every Developer Should Know
Auth0, Okta, AWS Cognito, Keycloak, and Azure AD each expose their OpenID Connect discovery document at different paths, with different subdomain conventions, grant type defaults, and PKCE requirements that affect how your app fetches tokens and JWKS keys.
Every OpenID Connect provider exposes a discovery document, but the path and subdomain conventions differ enough to cause integration errors when switching providers. Auth0 serves the document at https://<your-tenant>.auth0.com/.well-known/openid-configuration and uses a single tenant domain — PKCE is required for all public clients, RS256 is the default signing algorithm, and custom domains move the discovery path to https://<your-custom-domain>/.well-known/openid-configuration. Okta separates authorization servers: the org-level server lives at https://<tenant>.okta.com/oauth2/.well-known/openid-configuration, while custom authorization servers use https://<tenant>.okta.com/oauth2/<auth-server-id>/.well-known/openid-configuration — and each server has independent scope and claim configurations. AWS Cognito paths include the User Pool ID: https://cognito-idp.<region>.amazonaws.com/<user-pool-id>/.well-known/openid-configuration. Keycloak uses realm-scoped URLs: https://<host>/realms/<realm>/.well-known/openid-configuration. Azure AD (Entra ID) follows https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration and exposes a tenant-agnostic /common/ endpoint that requires extra client-side validation. The JWKS URI, supported scopes, and code_challenge_methods_supported all vary per provider and per configuration — reading the raw discovery document rather than relying on SDK defaults is the only reliable way to catch mismatches before they hit production.
The OIDC Inspector automates this: enter any domain and it scans the primary host plus 11 auth subdomains (auth., login., sso., id., accounts., oauth., oidc., as., access., connect., identity.) in parallel, fetches every reachable discovery document, and surfaces the authorization endpoint, token endpoint, JWKS URI, grant types, and PKCE support in a single view — with an Authorization Code Flow sequence diagram generated from the live configuration.
Follow Trango Compute on LinkedIn
We post updates on new tools, context engineering patterns, and LLM cost research.