[Openid-specs-ab] Issue #1040: Security Issue - Attacker may reuse MS to register new clients (openid/connect)

[andreassolberg]

New issue 1040: Security Issue - Attacker may reuse MS to register new clients
https://bitbucket.org/openid/connect/issues/1040/security-issue-attacker-may-reuse-ms-to

andreassolberg:

In the current OpenID Connect Federation spec 5.2 describes the process of using dynamic relying party registration

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.5.2 

The client registration request is not signed, instead it contains a a signed MS. The MS does not contain a client_id, nor is it aimed towards a specific OP. The MS may be used as a kind of bearer token credentials granting access to register new clients - those clients will be restricted with the content of the MS. 

The MS-es could be considered public, usually hosted at non-protected HTTP endpoints (`metadata_statement_uri` etc). The MS is also sent to OPs during registration. 

Attackers that get hold of an MS may use that to register new clients at providers.

This needs to be discussed, but there is no obvious easy way to fix this.

The evil OP can use the public MS to register new clients at other providers. Then it will get a set of `client_id` and `client_secrets` that other OPs thinks it has issed to the real client. But the registration will be locked to the `redirect_uri` of the client, and the OP cannot change that value.

*How is this still bad?*

* An OP may find it useful to provide clients access to perform certain operations with userless tokens, using client credentials flow. Here the redirect_uri is not used. This could be things like modifying the client registration. It can be getting user statitics, and more.
* An OP may not accept the real client registers, because it is already registered. And it may require an registration access token, that is given away to the evil OP.
* An OP may want to protect access tokens from being exposed to end users. The acess token may give far more access than what the end users should have (this is a bad design, but nontheless). The OP may achive this protection by only used authorization code flow, and require `client_id` / `client_secret` pair to obtain the token. An end user using an evil OP to obtain a client / secret pair may then also get its own user token.
* And in certain cases `redirect_uri` could also lack the strict binding to the control of the real client. In examples native mobile applications may register the `redirect_uri` of `coolapp://`, but it could not restrict other apps from registering the same custom scheme with Android or iOS. The same goes for native desktop applications. And CLI tools may use `localhost:9871` as redirect_uri…