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

Nat Sakimura sakimura at gmail.com
Mon Nov 2 02:29:11 UTC 2015

perhaps do a f2f adhoc this week?

2015年11月2日月曜日、John Bradley<ve7jtb at ve7jtb.com>さんは書きました:

> The attack is not on the authentication, it is on intercepting the code
> and being able to replay it.
> Using a key the client is given from  registration to authenticate the
> request to the token endpoint won’t help because that can just be man in
> the middled by the attacker as well.
> This is also not specific to dynamic client registration.  It just makes
> it easier.  I could make the client come to a site to register and give it
> bad endpoints as well.
> In Connect if you do a id_token code flow the issuer in the returned token
> would be wrong for the request so that should actually stop the attack on a
> client that is validating id_token correctly in that flow.  (allowing late
> binding per one proposal will make this vulnerable as well I think.
> In the code only flow it is much harder to stop because the attacker can
> register itself and then replay any keys it gets from the real AS.
> If the client provides a public key in registration that would help if we
> used signed requests.
> To stop the attack you really need to send the token endpoint URI in the
> request to the Authorization server, or use a asymmetric pkce challenge
> verifier.
> I haven’t had a chance to organize the options yet.
> John B.
> On Oct 31, 2015, at 5:14 AM, Mike Jones <Michael.Jones at microsoft.com
> <javascript:_e(%7B%7D,'cvml','Michael.Jones at microsoft.com');>> wrote:
> 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
> <javascript:_e(%7B%7D,'cvml','Sascha.Preibisch at ca.com');>
> Sent: ‎10/‎30/‎2015 1:00 PM
> To: openid-specs-ab at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','Openid-specs-ab at lists.openid.net');>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20151102/46bde883/attachment.html>

More information about the Openid-specs-ab mailing list