René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Add `{path}/.well-known/oauth-authorization-server` as a discovery URL fallback","articleBody":"## Problem\n\nWhen discovering OAuth Authorization Server Metadata, the SDK currently tries the following URL patterns (via `build_oauth_authorization_server_metadata_discovery_urls`):\n\n1. `/.well-known/oauth-authorization-server{path}` — RFC 8414 path-aware\n2. `/.well-known/openid-configuration{path}` — RFC 8414 Section 5 OIDC path-aware\n3. `{path}/.well-known/openid-configuration` — OIDC 1.0 discovery\n\nHowever, it does **not** try `{path}/.well-known/oauth-authorization-server`.\n\nSome OAuth providers (notably Azure Databricks) serve their OAuth Authorization Server Metadata at this path. For example:\n\n```\nhttps://\u003cworkspace\u003e.azuredatabricks.net/oidc/.well-known/oauth-authorization-server\n```\n\nThis returns a fully compliant metadata document with `authorization_endpoint`, `token_endpoint`, `scopes_supported`, `code_challenge_methods_supported` (PKCE), etc. — everything needed for a successful OAuth flow. Without discovering this metadata, clients fall back to incorrect default endpoints (e.g. `/authorize` instead of `/oidc/v1/authorize`) and wrong scopes.\n\n## Spec context\n\nTo be clear: `{path}/.well-known/oauth-authorization-server` is **not** the RFC 8414 URL construction. RFC 8414 Section 3 specifies that the well-known URI is inserted between the host and path components, producing `/.well-known/oauth-authorization-server{path}` — which the SDK already supports.\n\nHowever, the SDK already supports the analogous non-RFC-8414 pattern for OIDC: `{path}/.well-known/openid-configuration` (pattern #3 above), which follows the OIDC 1.0 Discovery convention of appending the well-known suffix to the issuer URL. The missing pattern is simply the OAuth equivalent of this — same URL construction approach, different well-known suffix.\n\n## Proposal\n\nAdd `{path}/.well-known/oauth-authorization-server` as a fallback URL in the discovery logic, for consistency with the existing OIDC 1.0 support. The discovery order would become:\n\n1. `/.well-known/oauth-authorization-server{path}` — RFC 8414\n2. `{path}/.well-known/oauth-authorization-server` — OAuth equivalent of OIDC 1.0 pattern **← new**\n3. `/.well-known/openid-configuration{path}` — RFC 8414 Section 5\n4. `{path}/.well-known/openid-configuration` — OIDC 1.0\n\nThis is a low-risk, one-line addition as a fallback URL that maintains consistency with the existing OIDC 1.0 support and unblocks real-world providers that use this convention.","author":{"url":"https://github.com/jerome3o-anthropic","@type":"Person","name":"jerome3o-anthropic"},"datePublished":"2026-01-23T21:49:42.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/1944/python-sdk/issues/1944"}