feat: clarify server metadata discovery mechanisim

Author: xiaoyijun

docs/specification/draft/basic/authorization.mdx

@@ -94,6 +94,23 @@ as described in [RFC9728 Section 5.1 "WWW-Authenticate Response"](https://datatr
 
 MCP clients **MUST** be able to parse `WWW-Authenticate` headers and respond appropriately to `HTTP 401 Unauthorized` responses from the MCP server.
 
+#### Server Metadata Discovery
+
+To handle different issuer URL formats and ensure interoperability with both OAuth 2.0 Authorization Server Metadata and OpenID Connect Discovery 1.0 specifications, MCP clients **MUST** attempt multiple well-known endpoints when discovering authorization server metadata.
+
+The discovery approach is based on [RFC8414 Section 3.1 "Authorization Server Metadata Request"](https://datatracker.ietf.org/doc/html/rfc8414#section-3.1) for OAuth 2.0 Authorization Server Metadata discovery and [RFC8414 Section 5 "Compatibility Notes"](https://datatracker.ietf.org/doc/html/rfc8414#section-5) for OpenID Connect Discovery interoperability.
+
+For issuer URLs with path components (e.g., `https://auth.example.com/tenant1`), clients **MUST** try endpoints in the following priority order:
+
+1. OAuth 2.0 Authorization Server Metadata with path insertion: `https://auth.example.com/.well-known/oauth-authorization-server/tenant1`
+2. OpenID Connect Discovery with path insertion: `https://auth.example.com/.well-known/openid-configuration/tenant1`
+3. OpenID Connect Discovery 1.0 legacy path appending: `https://auth.example.com/tenant1/.well-known/openid-configuration`
+
+For issuer URLs without path components (e.g., `https://auth.example.com`), clients **MUST** try:
+
+1. OAuth 2.0 Authorization Server Metadata: `https://auth.example.com/.well-known/oauth-authorization-server`
+2. OpenID Connect Discovery: `https://auth.example.com/.well-known/openid-configuration`
+
 #### Sequence Diagram
 
 The following diagram outlines an example flow:
@@ -112,11 +129,8 @@ sequenceDiagram
     M-->>C: Resource metadata with authorization server URL
     Note over C: Validate RS metadata,<br />build AS metadata URL
 
-    alt OAuth 2.0 Authorization Server Metadata
-        C->>A: GET /.well-known/oauth-authorization-server
-    else OpenID Connect Discovery
-        C->>A: GET /.well-known/openid-configuration
-    end
+    C->>A: GET Authorization server metadata endpoint
+    Note over C,A: Try OAuth 2.0 and OpenID Connect<br/>discovery endpoints in priority order
     A-->>C: Authorization server metadata
 
     Note over C,A: OAuth 2.1 authorization flow happens here
@@ -172,12 +186,9 @@ sequenceDiagram
 
     Note over C: Parse metadata and extract authorization server(s)<br/>Client determines AS to use
 
-    alt OAuth 2.0 Authorization Server Metadata
-        C->>A: GET /.well-known/oauth-authorization-server
-    else OpenID Connect Discovery
-        C->>A: GET /.well-known/openid-configuration
-    end
-    A->>C: Authorization server metadata response
+    C->>A: GET Authorization server metadata endpoint
+    Note over C,A: Try OAuth 2.0 and OpenID Connect<br/>discovery endpoints in priority order
+    A-->>C: Authorization server metadata
 
     alt Dynamic client registration
         C->>A: POST /register