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

[David Waite <[e-mail]>]

For systems with stateful sessions, you could reference that via the refresh token. If the access tokens are opaque to protected resources and meant to be used via introspection, you could also reference the state there as well.

For systems with stateteless sessions (e.g. JWT cookies), you have fewer options. A non-exhaustive list:
1. The refresh token can be modeled after a static user session policy, e.g. refresh will fail in four hours
2. Refresh tokens may have a sliding window within that policy, e.g. this refresh token is good for 30 minutes, but on refresh one will be issued good for another 30 minutes or the end of the four hour window, whichever is sooner
3. You can have a stateful system just for token revocations. This could reference a single session, or all sessions for the user (possibly under a specific client) generated before a particular time. The refresh (and possibly access) tokens would also have the same information in them for lookup. Logout could add an entry to this revocation list.

An aside:

This is kinda/sorta a  similar line of thinking that lead to DTVA ( https://bitbucket.org/openid/connect/raw/f76ffe99c47d4698bc2995c32dc7a402dd6e8c47/distributed-token-validity-api.txt <https://bitbucket.org/openid/connect/raw/f76ffe99c47d4698bc2995c32dc7a402dd6e8c47/distributed-token-validity-api.txt> ). The “Distributed” part was about pushing the ability to validate access and id_tokens close to the protected resources/RPs. The goal was also to build an API that supported this sort of token validation by otherwise stateless apps.

It wasn’t expected that refresh tokens were based on this system - we envisioned most AS/IDP instances to be built for authentication, and therefore already have requirements and business processes that would require more complex / stateful sessions.

-DW

> On Dec 6, 2018, at 1:53 PM, Phil Hunt <[e-mail]> wrote:
> 
> 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] <mailto:[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
>