Hi @klasen
Welcome to the Auth0 Community!
You are reporting that when attempting to automatically download a public key from a JWT, the discovery mechanism should implement RFC 8414-compliant fallback behavior. Specifically, when an issuer URL contains a path component, the client should first attempt to retrieve the OpenID Connect metadata using the RFC 8414 transformation, and only if that fails should it fall back to the OpenID Connect Discovery 1.0 transformation.
This is a valid RFC 8414 compliance issue. Auth0 should implement (or clarify whether it implements) the backwards-compatible fallback behavior described in RFC 8414 Section 5 for issuer identifiers containing path components. If Auth0 does not currently implement this fallback, this should be reported as a feature request or bug to Auth0 Support, as it affects interoperability with legacy OpenID Connect deployments.
Root Cause:
The issue you're describing relates to how OpenID Connect Discovery handles issuer URLs with path components:
- RFC 8414 (OAuth 2.0 Authorization Server Metadata) — Defines the standard transformation for discovering authorization server metadata
- OpenID Connect Discovery 1.0 (legacy) — Defines an older transformation method
- Backwards compatibility requirement — RFC 8414 explicitly requires that implementations support both transformations during a transition period
- Path component handling — When an issuer contains a path component (e.g.,
https://example.com/oauth), the two specifications produce different discovery URLs
How the Two Transformations Differ:
RFC 8414 Transformation (Primary):
Issuer: https://example.com/oauth
Discovery URL: https://example.com/oauth/.well-known/openid-configuration
OpenID Connect Discovery 1.0 Transformation (Legacy Fallback):
Issuer: https://example.com/oauth
Discovery URL: https://example.com/.well-known/openid-configuration
The Problem:
If a client library or Auth0 implementation only tries the RFC 8414 transformation and fails, it should fall back to the OpenID Connect Discovery 1.0 transformation. If it does not implement this fallback, it will fail to discover metadata for issuers with path components in legacy environments.
What Should Happen (RFC 8414 Compliant):
1. Client receives issuer: https://example.com/oauth
2. First attempt (RFC 8414):
GET https://example.com/oauth/.well-known/openid-configuration
3. If step 2 fails (404, 500, timeout, etc.):
Second attempt (OpenID Connect Discovery 1.0 fallback):
GET https://example.com/.well-known/openid-configuration
4. If step 3 succeeds, use the metadata
5. If step 3 also fails, return error
Recommended Actions:
Option 1: Verify Auth0's Current Behavior
- Contact Auth0 Support — Ask whether Auth0 implements RFC 8414 Section 5 fallback behavior
- Provide details:
- Your issuer URL (with path component)
- The client library or SDK you're using
- Whether you're experiencing discovery failures
- The exact error messages
- Ask specifically:
- Does Auth0 implement the RFC 8414 fallback for issuers with path components?
- Is this a known limitation or planned feature?
- What is the recommended workaround?
Option 2: File a Feature Request or Bug Report
If Auth0 does not implement this fallback:
- Go to Auth0 Community
- Create a new topic with:
- Title: "RFC 8414 Compliance: Implement Fallback Discovery for Issuers with Path Components"
- Description:
- Reference RFC 8414 Section 5
- Explain the use case (legacy OpenID Connect environments)
- Describe the expected behavior
- Provide your issuer URL and discovery failure details
- Or submit through your Auth0 Support dashboard if you have a paid plan
Option 3: Implement Client-Side Fallback (Workaround)
If you're using a client library that doesn't implement this fallback, you can implement it yourself:
// Pseudocode for RFC 8414-compliant discovery with fallback
async function discoverOpenIDConfiguration(issuer) {
// Parse issuer URL
const issuerUrl = new URL(issuer);
// Step 1: Try RFC 8414 transformation (primary)
const rfc8414Url = new URL(issuer);
rfc8414Url.pathname = rfc8414Url.pathname + '/.well-known/openid-configuration';
try {
console.log(`Attempting RFC 8414 discovery: ${rfc8414Url.toString()}`);
const response = await fetch(rfc8414Url.toString());
if (response.ok) {
return await response.json();
}
} catch (error) {
console.log(`RFC 8414 discovery failed: ${error.message}`);
}
// Step 2: Fall back to OpenID Connect Discovery 1.0 transformation
const legacyUrl = new URL(issuer);
legacyUrl.pathname = '/.well-known/openid-configuration';
try {
console.log(`Attempting OpenID Connect Discovery 1.0 fallback: ${legacyUrl.toString()}`);
const response = await fetch(legacyUrl.toString());
if (response.ok) {
return await response.json();
}
} catch (error) {
console.log(`OpenID Connect Discovery 1.0 fallback failed: ${error.message}`);
}
// Both attempts failed
throw new Error(
`Failed to discover OpenID configuration for issuer: ${issuer}. ` +
`Tried: ${rfc8414Url.toString()} and ${legacyUrl.toString()}`
);
}
// Usage
const config = await discoverOpenIDConfiguration('https://example.com/oauth');
const jwksUrl = config.jwks_uri;
Option 4: Check Your Auth0 Issuer Configuration
- Go to Auth0 Dashboard → Settings → General
- Check your issuer URL:
- Does it contain a path component?
- Is it in the format
https://your-domain.auth0.com (no path) or https://your-domain.auth0.com/path?
- If your issuer has a path component:
- Verify that both discovery URLs work:
https://your-domain.auth0.com/path/.well-known/openid-configuration (RFC 8414)https://your-domain.auth0.com/.well-known/openid-configuration (Legacy)
- Test both URLs manually using
curl or Postman
Example Testing:
# Test RFC 8414 transformation
curl -i https://your-domain.auth0.com/path/.well-known/openid-configuration
# Test OpenID Connect Discovery 1.0 transformation
curl -i https://your-domain.auth0.com/.well-known/openid-configuration
# Both should return 200 OK with valid metadata
RFC 8414 Reference:
The relevant section from RFC 8414 states:
"However, when deployed in legacy environments in which the OpenID Connect Discovery 1.0 transformation is already used, it may be necessary during a transition period to publish metadata for issuer identifiers containing a path component at both locations. During this transition period, applications should first apply the transformation defined in this specification and attempt to retrieve the authorization server metadata from the resulting location; only if the retrieval from that location fails should they fall back to attempting to retrieve it from the alternate location obtained using the transformation defined by OpenID Connect Discovery 1.0."
This explicitly requires that clients implement the fallback behavior you're describing.
What This Means for Auth0:
- If Auth0 is the issuer — Auth0 should ensure that both discovery URLs work for issuers with path components
- If you're using a client library — The library should implement the RFC 8414 fallback
- If you're integrating with Auth0 — You may need to implement the fallback yourself if your client library doesn't support it
This is a valid RFC 8414 compliance concern. Contact Auth0 Support to confirm whether Auth0 implements this fallback behavior, and file a feature request if it does not.