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

[nov matake]

Ah, my typo.
It’s “authorization endpoint”, not “token endpoint”.

> As Sascha suggested, sending some value to the token endpoint would be the solution.

> On Nov 2, 2015, at 10:59, nov matake <nov at matake.jp> wrote:
> 
> Hi all,
> 
> I also think this issue doesn’t relate to the implicit flow.
> If the attacker can get implicit access_tokens, it’s probably because client redirect_uri is invalid.
> In the attack we are discussing here, all information displayed on the consent screen would be valid for the end-user, so that there are no chance for the user to detect the attack.
> 
> As Sascha suggested, sending some value to the token endpoint would be the solution.
> However, I don’t think sending a secret which is issued in the first discovery response won’t fix the issue.
> In that case, the attacker will simply get the secret from the server and bypass it to the original client.
> 
> Sending a value which is “static" for the IdP seems solve the issue.
> (eg. issuer, token endpoint etc.)
> 
> Regards,
> nov
> 
>> On Oct 31, 2015, at 13:54, Preibisch, Sascha H <Sascha.Preibisch at ca.com <mailto:Sascha.Preibisch at ca.com>> wrote:
>> 
>> Yes Mike,
>> 
>> For the implicit flow there would be no /token endpoint. But if I am not mistaken the discussion was all about the code flow.
>> 
>> I think the main goal should be a solution that stops the flow when a client requests an authorization code and not when exchanging it for the access_token. And a solution should also not depend on a client doing various validations.
>> 
>> Regards,
>> Sascha
>> 
>> From: Torsten Lodderstedt <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>>
>> Date: Friday, October 30, 2015 at 2:36 PM
>> To: Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>>
>> Cc: Sascha Preibisch <sascha.preibisch at ca.com <mailto:sascha.preibisch at ca.com>>, "openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>" <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>>
>> Subject: Re: [Openid-specs-ab] Securing token requests when discovery service is used
>> 
>> 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 <mailto: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 <mailto:Sascha.Preibisch at ca.com>
>>> Sent: ?10/?30/?2015 1:00 PM
>>> To: openid-specs-ab at lists.openid.net <mailto: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 <mailto:Openid-specs-ab at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=CwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=HAtajlQ9KYailZ0S6-Ak9c7gPXdfkuQbjSnW7ZR1PjY&s=_d-STpg0ypM8VMn9WwuHM1zuRMkv-Pk-6wyXP8ax34s&e=>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net <mailto: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/20151102/bbdef081/attachment.html>