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 <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
