The id_token is a validatable protocol response - OAuth on its own cannot provide this and i doubt it is worth teaching teaching it new tricks.
I personally have moved on to always add id_token as a response type - together with OIDC discovery, in my mind OIDC is a superset of OAuth and I always use them together - or put differently - I recommend against using OAuth on its own without OIDC (besides client_creds/extension grants scenarios of course). — cheers Dominick Baier On 2 May 2016 at 04:08:25, William Denniss (wdenn...@google.com) wrote: I'm inclined to think that Nat's comment is right: "As I look at it more and more, it started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it." Even if we workaround the current issue with more unbound plain text params, will it solve the next issue? Personally I'm not convinced. I also wonder at what level of risk is the right solution "code id_token", which the researchers note will mitigate the attacks (when implemented correctly). If we absolutely must solve this without "id_token", I know John has a few ideas for lightweight binding of the request & response by hashing the request URL and some config. I wonder if a "lightweight crypto" approach is superior to "more unbound params" as the best non-id_token option. On Sat, Apr 30, 2016 at 10:36 PM, Nat Sakimura <sakim...@gmail.com> wrote: It actually depends on what risk level the transaction is at. For low risk transactions, just having separate redirection endpoint may be adequate. On the other hand, I can easily think of an attack that replaces iss on the authz response making the control invalid posing questions on whether it is worth introducing it. On Sun, May 1, 2016 at 14:21 Justin Richer <jric...@mit.edu> wrote: I agree that we’re getting dangerously close to recommending signed assertions at every step of the process, thereby bypassing HTTP. This was the same mistake that WS-* and SOAP made, let’s not repeat it if we can. — Justin On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: Hi Nat, sure, one could also authenticate and cryptographically protect the redirect response. Leveraging OIDC concepts is an idea worth considering but they should be adopted to the OAuth philosophy. The id token as used in the hybrid flows mixes an identity assertion with elements of transport security measures. A OAuth AS does not provide identity data to clients, so we only need the transport security part. I personally would prefer a OAuth response object (similar to request object you have proposed) over the id token. Such a response object could contain (and directly protect) state, code and other response values. I consider this the more elegant design and it is easier to implement then having detached signatures over hash values of codes or access tokens. Moreover, it would allow to encrypt the response as well. Generally, our threat analysis so far does not have provided justification for cryptographically protected redirect responses. All proposals currently on the table stop mix up and code injection using simpler mechanisms. I think OAuth 2.0 is a huge success due to its balance of versatility, security and _simplicity_. We definitely need to keep it secure, but we should also keep it as simple as possible. kind regards, Torsten. Am 29.04.2016 um 10:08 schrieb Nat Sakimura: As I look at it more and more, it started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it. Any concrete ideas? On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <tors...@lodderstedt.net> wrote: Hi all, discussion about Mix-Up and CnP seems to have stopped after the session in BA - at least in the OAuth WG. There is a discussion about mitigations in OpenId Connect going on at the OpenId Connect mailing list. I'm very much interested to find a solution within the OAuth realm as I'm not interested to either implement two solutions (for OpenId Connect and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens in the front channel). I therefore would like to see progress and propose to continue the discussion regarding mitigations for both threats. https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 proposes reasonable mitigations for both attacks. There are alternatives as well: - mix up: -- AS specific redirect uris -- Meta data/turi (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) - CnP: -- use of the nonce parameter (as a distinct mitigation beside state for counter XSRF) Anyone having an opinion? best regards, Torsten. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
