What Is .well-known/openid-configuration?
/.well-known/openid-configuration is a standardized URL path that every OpenID Connect provider publishes to describe its configuration. Append it to any OIDC issuer's base URL and you get a JSON document listing all of the provider's endpoints, supported features, and cryptographic capabilities.
For example:
- Google:
https://accounts.google.com/.well-known/openid-configuration - Microsoft:
https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration - Authgear:
https://your-project.authgear.cloud/.well-known/openid-configuration
This document is the foundation of OIDC auto-discovery. Instead of hardcoding authorization endpoint URLs, token endpoints, and signing keys into your application, you fetch this document once and read everything you need from it.
💡 Try it now: Use the Authgear OIDC Discovery Endpoint Explorer to fetch and inspect any provider's
.well-known/openid-configuration— no curl, no command line. Enter an issuer URL and see the full document with a structured field summary.
Where the "well-known" Convention Comes From
The /.well-known/ path prefix is defined by RFC 8615 as a reserved URI space for well-known locations. It's a convention that says: "if you want to find something standardized about this host, look here." Other well-known paths include /.well-known/security.txt (security contact info) and /.well-known/acme-challenge/ (used by Let's Encrypt for certificate issuance).
The openid-configuration document itself is defined by the OpenID Connect Discovery 1.0 specification and extended by RFC 8414 (OAuth 2.0 Authorization Server Metadata). Every compliant OIDC provider must publish it at exactly this path.
What's Inside the Document
The discovery document is a flat JSON object. Some fields are required by the spec; others are optional but widely used. Here are the ones you'll encounter most often:
Required fields
| Field | What It Contains |
|---|---|
issuer |
The canonical issuer URL. Must exactly match the iss claim in tokens issued by this provider. |
authorization_endpoint |
The URL where users are sent to log in and authorize access. |
token_endpoint |
The URL used to exchange authorization codes for access tokens and ID tokens. |
jwks_uri |
The URL of the JSON Web Key Set — the public keys used to verify token signatures. |
response_types_supported |
The OAuth response types this provider accepts (e.g. code, token, id_token). |
subject_types_supported |
How the provider identifies users. Almost always public (same sub for all clients) or pairwise (different sub per client). |
id_token_signing_alg_values_supported |
Signing algorithms supported for ID tokens. Typically includes RS256. |
Commonly used optional fields
| Field | What It Contains |
|---|---|
userinfo_endpoint |
URL to retrieve claims about the authenticated user. Called with a valid access token. |
end_session_endpoint |
URL to log the user out and end the SSO session (RP-Initiated Logout). |
scopes_supported |
List of OAuth scopes the provider supports (e.g. openid, profile, email). |
claims_supported |
User claims the provider can return (e.g. sub, name, email, phone_number). |
grant_types_supported |
OAuth grant types supported (e.g. authorization_code, refresh_token, client_credentials). |
token_endpoint_auth_methods_supported |
How clients authenticate to the token endpoint (e.g. client_secret_basic, private_key_jwt). |
code_challenge_methods_supported |
PKCE methods supported. Look for S256 — required for public clients. |
revocation_endpoint |
URL to revoke access or refresh tokens. |
introspection_endpoint |
URL to check whether a token is currently active (token introspection). |
A Real Example: What Google's Document Looks Like
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"scopes_supported": ["openid", "email", "profile"],
"response_types_supported": ["code", "token", "id_token"],
"subject_types_supported": ["public"],
"id_token_signing_alg_values_supported": ["RS256"],
"claims_supported": ["sub", "iss", "aud", "iat", "exp", "email", "name"]
}
The full document has about 25 fields. Use the OIDC Discovery Endpoint Explorer to see the full JSON for any provider — including Google, Okta, Azure, Keycloak, or your own Authgear project.
Discovery URL Formats by Provider
The path /.well-known/openid-configuration is always the same, but the base issuer URL varies. Some providers (notably Azure and Keycloak) include a tenant or realm segment in the URL:
| Provider | Discovery URL Format |
|---|---|
https://accounts.google.com/.well-known/openid-configuration |
|
| Microsoft (Azure AD) | https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration |
| Okta | https://{yourOktaDomain}/.well-known/openid-configuration |
| Auth0 | https://{yourDomain}/.well-known/openid-configuration |
| Keycloak | https://{host}/realms/{realm}/.well-known/openid-configuration |
| Authgear | https://{your-project}.authgear.cloud/.well-known/openid-configuration |
How to Fetch the Document
In the browser (no setup)
Use the Authgear OIDC Discovery Endpoint Explorer. Enter any issuer URL and click Fetch. You'll get the full JSON document with a structured summary of the key endpoints.
With curl
# Fetch and pretty-print the discovery document
curl -s https://accounts.google.com/.well-known/openid-configuration | python3 -m json.tool
# Extract just the authorization endpoint
curl -s https://accounts.google.com/.well-known/openid-configuration | jq '.authorization_endpoint'
# Extract the JWKS URI
curl -s https://accounts.google.com/.well-known/openid-configuration | jq '.jwks_uri'
In application code (Node.js)
// Fetch the discovery document and extract endpoints
async function getOIDCConfig(issuerUrl) {
const discoveryUrl = `${issuerUrl}/.well-known/openid-configuration`;
const response = await fetch(discoveryUrl);
if (!response.ok) {
throw new Error(`Failed to fetch discovery document: ${response.status}`);
}
const config = await response.json();
return {
authorizationEndpoint: config.authorization_endpoint,
tokenEndpoint: config.token_endpoint,
jwksUri: config.jwks_uri,
userinfoEndpoint: config.userinfo_endpoint,
endSessionEndpoint: config.end_session_endpoint,
};
}
// Usage
const config = await getOIDCConfig('https://your-project.authgear.cloud');
console.log(config.authorizationEndpoint);
In application code (Python)
import requests
def get_oidc_config(issuer_url):
discovery_url = f"{issuer_url.rstrip('/')}/.well-known/openid-configuration"
response = requests.get(discovery_url)
response.raise_for_status()
return response.json()
config = get_oidc_config('https://your-project.authgear.cloud')
print(config['authorization_endpoint'])
print(config['jwks_uri'])
Why Auto-Discovery Matters
Without auto-discovery, integrating with an OIDC provider involves hardcoding a list of endpoint URLs into your application. This creates real problems:
- Provider changes break your app. If the provider changes an endpoint URL, your app breaks silently until someone notices.
- Multi-tenant apps need different config per tenant. Azure AD has a different URL per tenant. Without discovery, managing this is a hardcoded map. With discovery, you construct the URL dynamically from the tenant ID.
- JWKS rotation breaks token verification. Providers rotate signing keys. If you've hardcoded the public key, your token verification breaks after rotation. Fetching from
jwks_uri— found in the discovery document — handles this automatically.
Discovery makes your OIDC integration resilient and self-configuring. Most mature OAuth/OIDC libraries (Passport.js, python-social-auth, Spring Security, etc.) accept an issuer URL and handle the rest automatically by fetching the discovery document.
What Happens If Discovery Fails
If a fetch to /.well-known/openid-configuration fails, common causes are:
- The provider doesn't support OIDC Discovery — some older or custom identity systems don't publish a discovery document. You'll need to configure endpoints manually.
- Wrong issuer URL — the discovery URL is constructed from the issuer, so a wrong base URL means a 404. Check the provider's documentation for the exact issuer format (especially for Azure AD and Keycloak, which include tenant/realm segments).
- CORS restrictions — some providers restrict cross-origin access to the discovery endpoint. Browser-based fetches may fail even if curl works.
- Private or internal provider — the provider is not reachable from the public internet. This is expected for internal deployments.
The Discovery Document and the JWKS URI
The jwks_uri field in the discovery document is one of the most important. It points to the JSON Web Key Set — the public keys your application needs to verify JWT signatures. Every time your app receives an ID token or access token, it should verify the signature against the keys at this URI.
To learn more about how the JWKS URI works and how to use it in token verification code, see What Is a JWKS URI? JWT Key Sets Explained for Developers.
Using .well-known/openid-configuration with Authgear
Every Authgear project publishes a discovery document at https://your-project.authgear.cloud/.well-known/openid-configuration. It includes all required OIDC fields plus Authgear-specific extensions. When you integrate your app with Authgear using any standard OIDC library, you just provide the issuer URL — the library fetches the discovery document and configures itself automatically.
Next Steps
- Inspect any provider's discovery document with the free OIDC Discovery Endpoint Explorer
- Learn about JWKS in What Is a JWKS URI? JWT Key Sets Explained for Developers



