Security Issue - Attacker may reuse MS to register new clients
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 theredirect_uri
ofcoolapp://
, 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 uselocalhost:9871
as redirect_uri…
Comments (8)
-
-
I thought I had added another comment but it got lost somewhere.
Anyway, in the signed JSON Web Token there is an
aud
defined. Thataud
MUST be the OP's issuer ID. another check that should be added to the verification of the client registration request.I think this should make it harder for the evil OP to do what Andreas describes.
-
-
assigned issue to
Roland, please add the checks that you're describing in your comment.
-
assigned issue to
-
- changed status to open
-
The software statement should contain a proof of possession. For any sort of auth not involving ;locking down the redirect URI , the client authentication should be asymmetric with the JWKS URI specified or the public key directly provided in the Software statement.
It would be preferable to lock down authentication even if there is a redirect URI specified. -
Client registration can be done in 2 ways.
- Explicit client registration
- Automatic client registration
Which ever one is used they both depends on the OP getting (explicit) or fetching (automatic) a self-signed entity statement that belongs to the client. The OP MUST verify that the entity statement belongs to a client that is part of the federation by checking the trust chain and at the same time check that the entity statement has not been tampered with. Sure an entity could get hold of an entity statement and use it in a client registration but it would not be able to modify the information in the entity statement to make itself a client in the federation.
-
In explicit client registration we can require the
aud
in the stmt to be set to the OP issuer. Right now (draft 12) theaud
is optional:https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.2.1
-
- changed status to resolved
Requiring aud in the entity statement is added in draft 13.
- Log in to comment
As you hinted in Issue1042 one thing we can do is to demand that the complete client request should be self-signed.
The draft specifies OpenID Connect as the basis so client credential flow is out-of-scope.
To deal with not being the real client that registers we may have to add some proof-of-possesion exchange where the client shows that it controls the metadata signing keys.