[Openid-specs-ab] Securing token requests when discovery service is used
sakimura at gmail.com
Mon Nov 2 09:54:12 UTC 2015
What about 5pm and before the social?
2015-11-02 18:40 GMT+09:00 nov matake <nov at matake.jp>:
> Does the f2f happen tomorrow in Yokohama?
> Then I can join :)
> On Nov 2, 2015, at 11:29, Nat Sakimura <sakimura at gmail.com> wrote:
> 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
>> 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>
>> 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?
>> -- 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
>> 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
>> 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
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab