according to [1], countermeasure (1) describes to

> configure [the] authorization servers to return an AS identitifier
("iss") and the "client_id" for which a code or token was issued in the
authorization response.

So if an MixUp attack is running, the victim contacts A-AS but is
redirected to to H-AS [2].
The AS adds - according to the countermeasure - two additional
parameters to the authorization response: client_id and issuer. Both
values are set by H-AS, so it returns H-issuer and H-client_id.

But: during the registration of the client on A-AS (rfc7591), it can return:

HTTP/1.1 201 Created

      "client_id": "H-client_id",
      "redirect_uris": [

So if the client receives the client_id in the authorization response,
it is unable to distinguish to which AS the client_id belongs to - they
have the same values.

This does not hold for the issuer parameter in the authorization
response, because it is set by H-AS and independent of and not set
during the Dynamic Client Registration Protocol.

So basically, it is the same problem as with the redirect_uri.


[2]: Step 4 in

On 02.12.19 11:26, Daniel Fett wrote:
> Am 02.12.19 um 10:05 schrieb Christian Mainka:
>> I think this problem is not only restricted to the redirect_uri.
>> Regarding countermeasure (1), also the A-AS can return the same
>> client_id as the client uses on the H-AS.
>> TL;DR: In countermeasure (1), only the issuer prevents MixUp, the
>> client_id parameter can be faked as well during the registration of the
>> client (especially if Dynamic Client Registration is used).
> What would be the issuer identifiers of A-AS and H-AS in this case be,
> as seen by the client?
> -Daniel
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security 
Chair for Network and Data Security 
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347

OAuth mailing list

Reply via email to