[Openid-specs-ab] Hybrid Flow use cases and client confidentiality requirements
sakimura at gmail.com
Thu Mar 10 16:35:20 UTC 2016
It so happens that the hybrid flow is the most secure way.
The the front channel through the user agent is an untrusted transport.
Adversary can tamper the response and do bad things.
To prevent it, you need a signature on the response to detect it.
ID Token works as the detached signature so if you use the hybrid flow, you
will be able to tell if the front channel payload has been tampered with or
replaced by adversary.
2016-03-08 22:34 GMT+09:00 Sergey Beryozkin <sberyozkin at gmail.com>:
> Hi All
> I'm not understanding clearly enough why OIDC hybrid flows will be used. I
> can imagine a situation where a complex 'client' which is probably a
> server client this implicit client is linked is used.
> But it will help myself and other implementers to understand better what
> are use cases (even a single use case) here ?
> What confuses me is what are the real client confidentiality requirements
> For example, a public client may be restricted to request a token via the
> implicit flow but not the code. Likewise a confidential client may be
> prevented from requesting a token via the implicit flow but only allowed to
> request a code. But with the hybrid flow - it is everything that one can
> possibly get from OAuth2 server supporting the redirection based flows.
> Can it make sense to introduce a 'hybrid' client term ?
> Thanks, Sergey
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab