What Is .well-known/openid-configuration? A Developer's Guide

Learn what .well-known/openid-configuration is, what every field in the discovery document means, and how to fetch it for Google, Okta, Azure, Keycloak, or your own OIDC provider.

 min. read
March 6, 2026
Star us on GitHub and stay updated

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
Google 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

Preferences

Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website.

Accept all cookies

These items are required to enable basic website functionality.

Always active

These items are used to deliver advertising that is more relevant to you and your interests.

These items allow the website to remember choices you make (such as your user name, language, or the region you are in) and provide enhanced, more personal features.

These items help the website operator understand how its website performs, how visitors interact with the site, and whether there may be technical issues.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.