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 <phil.h...@oracle.com> 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 <jric...@mit.edu> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
