Re: [OAUTH-WG] Confusion on Implicit Grant flow

Hi John
On 09/02/15 22:59, John Bradley wrote:
> The security problem was people only doing host name matching on redirect_uri and attackers finding redirectors to use.   That impacted all public clients not just implicit.
> Implicit took most of the heat because that was what Facebook was using, and they had the largest issue.
>
> Connect has a response_mode that allows the response to be form encoded rather than fragment.
> I read RFC 5849 as only allowing code to be query encoded.   The response_mode was intended for the new response types we defined in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
>
> The spec for response mode is here http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>
> We haven't done anything with it recently.  I don't know if the OAuth WG wants to take it up.
>
What is your opinion on providing a feature 'symmetric' to the one where 
a signed and/or encrypted code request is passed to AS ? The feature 
would return a signed and/or encrypted code in the redirect URI as usual.

I'm not sure it would help the implicit clients though...Unless the 
encryption key can be derived from a combination of the client_id and 
some extra piece of information encoded in the JS script but also known 
to AS (via the registration, etc)

Thanks, Sergey


> John B.
>> On Feb 9, 2015, at 7:32 PM, Bill Burke <bburke@redhat.com> wrote:
>>
>>
>>
>> On 2/9/2015 5:03 PM, John Bradley wrote:
>>> OK, I don't know if the WG has discussed the issue of fragments in browser history.
>>>
>>> So you are trading off several round trips against the possibility of a token leaking in browser history or bookmark?
>>>
>>
>> Yes, bookmarking tokens is a little scary, IMO, as we've already run into users bookmarking URLs with codes in them.
>>
>> Also, wasn't there additional security vulnerabilities surrounding implicit flow?  Maybe these were just the product of incorrect implementations, I don't remember, it was a while ago.
>>
>>> One extension that Connect introduced was a "code id_token" response type that is fragment encoded.  That would let you pass the code directly to the JS saving two legs.
>>>
>>
>> It looks like OIDC added a "response_mode" parameter where you can specify "query" or "fragment".  Thanks for pointing this out!
>>
>>
>> Thanks for all the help.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>