On 2/10/2015 8:15 AM, John Bradley wrote:
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
Excellent. Thanks.
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.
Why would you need the nonce if the IDP guarantees that the code can only be used once? The code, state, and redirect-uri are all validated by the IDP with the access token request.
Bill -- 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
