How would the token endpoint detect login status of the user? Phil
Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Dec 6, 2018, at 12:24 PM, David Waite <da...@alkaline-solutions.com> 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 <phil.h...@oracle.com >> <mailto: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 >> <mailto: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
