The nonce allows the client to insert a unique value into the id_token to associate it with a particular browser session(Think SAML RequstID). That is useful for web server based clients. It may or may not be useful in the JS case, as the client is the browser.
While code can only be used once, that doesn't stop someone from intercepting a code/id_token from one session and replaying it in a different one to the same client. In the JS client case that would require a man in the middle between the browser and the AS, so is much harder for an attacker than the case where the client is a web server. Using the PKCE code_challenge also lets the client detect if some substitution of the code has happened. John B. > On Feb 10, 2015, at 11:27 AM, Bill Burke <bbu...@redhat.com> wrote: > > > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
