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

[Phil Hunt <[e-mail]>]

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/>[e-mail] <mailto:[e-mail]>

> On 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] <mailto:[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] <mailto:[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