The issue is maintaining key material in the browser. Web Crypto will help with that , but is not deployed widely in browsers at the moment.
Thinking about it a bit someone could make a more secure flow for JS clients using code and some Connect extensions now. If I were concerned about logging the AT, then I would have the JS make a CORS call to the authorization endpoint with: response_type=code+id_token [http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html] code_challenge=(challenge value) [ https://tools.ietf.org/html/draft-ietf-oauth-spop-02] code_challenge_method=S256 The response is fragment encoded, and the id_token contains a detached sig of code for the JS to verify along with the client as the "aud" signed with RSA key of the AS as the default. The JS would be the callback URI and extract the code and id_tokens The JS then makes a CORS call to the token_endpoint sending code_verifier=(verifier value) Code could be logged but wouldn't be usable without knowing the code_verifier. This effectively turns the JS into a semi confidential client. We have been looking at PKCE/SPOP for native apps, but nothing would stop it from working with JS clients. In Connect the JS client crates a nonce value and sends that with the request. That value comes back in the signed_id token allowing the JS to know that the code and id_token are in reply to it's request and not replayed from another session. I think using token binding to associate the JS clients TLS key to the AT so that it cannot be replayed from a different browser is the best option over the longer term. That provides the best protection from plugins and scripts extracting the AT from the running JS. John B. > On Feb 10, 2015, at 7:16 AM, Sergey Beryozkin <[email protected]> wrote: > > 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
