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

nov matake nov at matake.jp
Mon Nov 2 01:59:21 UTC 2015


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> 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
> 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/7ef20cd2/attachment.html>


More information about the Openid-specs-ab mailing list