OAuth Authorization Server Metadata Client ID Parameter

4.1. Parameter Definition

client_id

OPTIONAL. The client identifier as described in Section 2.2 of [RFC6749].¶

4.2. Authorization Server Behavior

When the client_id parameter is present, an authorization server MAY customize the metadata response (including response headers like Cache-Control) based on the specific client. For example, an authorization server could:¶

• Return new endpoints or supported scopes only to clients that are participating in a beta testing program.¶

• Continue serving legacy authentication methods to backwards-incompatible clients while newer clients receive an updated configuration.¶

• Gradually shift traffic to a new signing key or token endpoint URL for specific clients over time.¶

If the authorization server does not recognize the client_id or chooses not to provide customized metadata, it MUST ignore the parameter and return the standard, global authorization server metadata. This ensures full backward compatibility.¶

4.3. Client Behavior

[RFC8414] does not specify authorization server behavior when query parameters are present, so it's possible that some authorization servers that don't adopt this specification will return an error when given a client_id parameter. Clients SHOULD gracefully handle HTTP 400 errors and retry their request without the client_id parameter.¶

4.4. Open Question: Indicate support for this specification?

Should the authorization server indicate its support for this specification?¶

1. No.¶

   • It's unclear what a client would do with this information other than make bad assumptions. Knowing whether AS metadata was specifically tailored shouldn't change a client's behavior.¶

2. Add a global boolean flag per_client_as_metadata_supported.¶

   • This only seems useful if there are many AS Metadata deployments today that will reject requests with query parameters. But also there's not much difference between (a) calling AS metadata without a client_id, seeing per_client_as_metadata_supported, and retrying with client_id and (b) following [Client Behavior] above. If anything I'd expect (b) to be better in practice because most AS aren't going to fail when given an unrecognized URL param.¶

3. Echo the client_id back as a field in the AS Metadata response.¶

   • It's unclear what benefits this provides over Option 2, but it has the additional downside of preventing the AS from serving a static file for non-customized clients.¶

5.1. Unauthenticated Requests vs. Client Authentication

The Authorization Server Metadata endpoint defined in [RFC8414] is typically accessed via unauthenticated HTTP GET requests over TLS. Accepting a bare client_id query parameter without any form of client authentication carries certain tradeoffs:¶

1. Ease of Deployment: The primary advantage of accepting a bare client_id is simplicity and compatibility with existing HTTP GET metadata retrieval patterns. Clients can fetch metadata early in their lifecycle, even before holding or presenting any credentials.¶

2. Information Disclosure: Because the request is unauthenticated, an attacker or unauthorized third party could query the metadata endpoint with arbitrary client identifiers. This could allow the attacker to learn specific client configurations, such as which clients have access to beta features or legacy authentication methods. In most environments, metadata is considered public information, but care SHOULD be taken if specific metadata values reveal sensitive business logic or proprietary features.¶

Authorization servers that require strong assurance of the requesting client's identity before revealing sensitive metadata could alternatively require client authentication on the metadata request. However, doing so deviates from the standard unauthenticated discovery pattern and might require dedicated credentials or signed assertions, significantly increasing client implementation complexity.¶