Consider requiring that the client_uri is a prefix of the client_id

[aaronpk]

The client_uri value is meant to point to a web page about the client. The client_id is the JSON metadata. So it would be reasonable for someone to implement this with values such as:

{
  "client_id": "https://example.com/metadata.json",
  "client_uri": "https://example.com/"
}

Requiring that the client_uri is a prefix means we can recommend displaying that whole value to the user, rather than only the hostname (more risky in shared domain situations) or the full client_id (more noisy with the potential for long strings that might scare the user)

[ThisIsMissEm]

This would complicate something like a development client_id metadata document provider, which would hinder developer experience getting started with using client_id metadata documents. See also #12

[matthieusieben]

Regarding #12, if we did have a "metadata as a service", think it would be reasonable to enforce that the client_uri be on the same origin/prefix. We don't want to hinder DX too much, but enforcing a prefix would push devs to publish their own metadata, which is desirable.

[ThisIsMissEm]

@matthieusieben I think it could only be a "SHOULD" and not a "MUST" at best. So:

client_uri SHOULD be a prefix of client_id

Unless the "client metadata document as a service" server has some way of generating a page for client_uri? Or we make it a MUST but allow for omission of the client_uri?

[ThisIsMissEm]

There's also language in the dynamic client registration RFC about client_uri, tos_uri, policy_uri and logo_uri:

In a situation where the authorization server is supporting open client registration, it must be extremely careful with any URL provided by the client that will be displayed to the user (e.g., "logo_uri", "tos_uri", "client_uri", and "policy_uri"). For instance, a rogue client could specify a registration request with a reference to a drive-by download in the "policy_uri", enticing the user to click on it during the authorization. The authorization server SHOULD check to see if the "logo_uri", "tos_uri", "client_uri", and "policy_uri" have the same host and scheme as the those defined in the array of "redirect_uris" and that all of these URIs resolve to valid web pages. Since these URI values that are intended to be displayed to the user at the authorization page, the authorization server SHOULD protect the user from malicious content hosted at the URLs where possible. For instance, before presenting the URLs to the user at the authorization page, the authorization server could download the content hosted at the URLs, check the content against a malware scanner and blacklist filter, determine whether or not there is mixed secure and non-secure content at the URL, and other possible server-side mitigations. Note that the content in these URLs can change at any time and the authorization server cannot provide complete confidence in the safety of the URLs, but these practices could help. To further mitigate this kind of threat, the authorization server can also warn the user that the URL links have been provided by a third party, should be treated with caution, and are not hosted by the authorization server itself. For instance, instead of providing the links directly in an HTML anchor, the authorization server can direct the user to an interstitial warning page before allowing the user to continue to the target URL.

As client metadata document support is effectively open client registration, perhaps we need a reminder of this under the security considerations?

[matthieusieben]

Since the user comes from the client origin (can be checked through the referer header), and will navigate back to that same origin (redirect uri, tos, policy, etc), the oauth provider does not put the user in a position of risk, even if it does not scan the various uris against potential attacks, by simply enforcing a same origin policy on all the uris. Enforcing a same prefix policy allows to better yet protect users against different clients that would be hosted on some shared CDN (think Google buckets).

In our implementation, we do enforce a same prefix policy for that reason.

In the case of "loopback clients" (clients that do not host their own metadata document, we might need to come up with a name for those), we do not allow, or show, any uri, logo or name (besides 127.0.0.1 redirect uris). Even with clients that do expose their own metadata document, we keep an allowlist to determine if the logo can be shown.

I strongly believe that:

• the spec should require (MUST) that the various uris be on the same origin.
• the spec should suggest (SHOULD) that the various uris be on the same prefix
• the spec should require (MUST) not to display the logo without manual approval
• the spec should suggest (SHOULD) display a warning in case of non allow listed clients ("This client pretends to be X, but make sure that the <client_origin> is indeed owned by X before you continue")
• the spec should suggest (SHOULD) to add additional security measures for non allow listed clients (no SSO, refresh tokens limited to short period, etc)
• any "metadata document as a service" should not allow using arbitrary/unverified origins in client uris. In particular it should not (MUST NOT) bypass the same origin policy by redirecting the user to an arbitrary uri (this should be more easy to enforce by the auth server than performing a malware scan)
• "loopback clients" (client uri using http://localhost, or any other non HTTPS uri) offer a great way for authorization servers to detect clients marking themselves as potentially vulnerable to attacks (e.g. two apps running on the same computer, the second trying to impersonate the first by using the same metadata document)
• "loopback clients" also allow each auth server to provide their own default in the metadata document (though this might be problematic for interoperability)

For all these reasons, I think that a same prefix policy, and an indentifiable "loopback client" uri scheme should really be specced.