[Openid-specs-ab] Securing token requests when discovery service is used

Torsten Lodderstedt torsten at lodderstedt.net
Fri Oct 30 21:36:30 UTC 2015


Hi Mike,

is the attack applicable for the implicit grant? I think it would require the attacker to proxy the legitimate OP's authz endpoint, which results in a different URL being displayed in the user agent.

kind regards,
Torsten.

> Am 30.10.2015 um 21:14 schrieb Mike Jones <Michael.Jones at microsoft.com>:
> 
> The other thing that can't be faked by an attacker is the OP's keys. If the ID token isn't signed by the right keys, then the RP knows that there's a problem.  This points to a possible solution involving authenticating the jwks_uri value.
> 
> Remember also that the Implicit flows don't use a token endpoint. So solutions that involve authenticating the token endpoint won't work for deployments using only Implicit flows.
> 
> John, Justin, and Nov, when you send in your IIW session notes, can you also please send them here?
> 
> Thanks,
> -- Mike
> From: Preibisch, Sascha H
> Sent: ‎10/‎30/‎2015 1:00 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Securing token requests when discovery service is used
> 
> Hi!
> 
> Now that IIW is over I would like to bring up my thoughts regarding the
> session we had with John regarding the discovery service issue.
> 
> If I am the 'bad' discovery service provider I can fake all values within
> the discovery response. Except for the /token endpoint. That has to point
> to my system in order for me to receive the authorization_code and client
> credentials.
> 
> Therefore I believe there are two solutions:
> 
> * the discovery response to the client has to include a secret which has to be included
> in the initial /authorize request. The authorization server validates the
> value and fails the request if it is invalid. This of course has the
> drawback that the authorization server has to keep state. As a server guy
> I would not like to support this flow
> 
> * The better solution I see, and as I mentioned during the discussion, is
> that the client should include the target /token endpoint as an additional
> request parameter for the initial /authorize request. The authorization
> server does a simple string comparison and fails if the /token endpoint is
> not the one as expected
> 
> Regards,
> Sascha
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20151030/1d792bca/attachment-0001.html>


More information about the Openid-specs-ab mailing list