Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Vittorio Bertocci <[e-mail]>]

> There are indeed several ASs which, possibly because of an interpretation
of OIDC, assume refresh tokens mean offline access and are mutually
exclusive with public clients.
AFAIK both Microsoft and Google do support RTs with public clients, but
their lifecycle is independent from the session with the AS (which is
represented by an artifact that is only indirectly accessible from
traditions public clients such as mobile and desktop apps).

As you say, the hidden iframe for retrieving a code via prompt=none remain
viable - and if at this time that is the only approach universally
available (forgetting ITP2 for a moment) that should be emphasized
accordingly in the document.

On Thu, Dec 6, 2018 at 12:24 PM David Waite <[e-mail]>
wrote:

> One benefit of moving to code flow is that the refresh token can be used
> to check the validity of the user session (or rather, it allows the AS
> another avenue to force authentication events if the AS considers the user
> session to be expired (or has a drop in confidence).
>
> There are indeed several ASs which, possibly because of an interpretation
> of OIDC, assume refresh tokens mean offline access and are mutually
> exclusive with public clients.
>
> The ability to have refresh tokens track a user session is an AS
> implementation detail, and something that these ASs could choose to change
> to over time. In the meantime, there shouldn’t be anything preventing a
> client from doing the iframe and prompt=none step that they are doing today
> with implicit. Even if the AS is implemented in terms of stateless
> sessions, such functionality can be implemented by encoding user session
> information into the “code token".
>
> -DW
>
> On Dec 6, 2018, at 11:51 AM, Phil Hunt <[e-mail]> wrote:
>
> While I generally agree with justin that moving everything to the back
> channel is good, I worry that checking user login state may be more
> important.
>
> What if upon refresh of a javascript client the AS would like to check the
> validity of the current user session?
>
> Many implementers solve the user experience issue by using prompt none in
> the oidc authentication case. I seem to remember some oauth providers never
> implemented refresh and they were able to create a good experience.
>
> Phil
>
>
> On Dec 6, 2018, at 7:47 AM, Justin Richer <[e-mail]> wrote:
>
> I support the move away from the implicit flow toward using the
> authorization code flow (with PKCE and CORS)  for JavaScript applications.
> The limitations and assumptions that surrounded the design of the implicit
> flow back when we started no longer apply today. It was an optimization for
> a different time. Technology and platforms have moved forward, and our
> advice should move them forward as well. Furthermore, the ease of using the
> implicit flow incorrectly, and the damage that doing so can cause, has
> driven me to telling people to stop using it.
>
> There are a number of hacks that can patch the implicit flow to be
> slightly better in various ways — if you tack on the “hybrid” flow from
> OIDC or JARM plus post messages and a bunch of other stuff, then it can be
> better. But if you’re doing all of that, I think you really need to ask
> yourself: why? What do you gain from jumping through all of those hoops
> when a viable alternative sits there? Is it pride? I don’t see why we cling
> to it. To me, it’s like saying “hey sure my leg gets cut off when I do
> this, but I can stitch it back on!”, when you could simply avoid cutting
> your leg off in the first place. The best cure is prevention, and what’s
> being argued here is prevention.
>
> So many of OAuth’s problems in the wild come from over-use of the front
> channel, and any place we can move away from that is a good move.
>
> — Justin
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>