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

[David Waite <[e-mail]>]

> On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci <Vittorio=[e-mail]> wrote:
> 
> > Can you give a concrete example? To me it feels like you are explaining scenarios where OAuth is used for login.  
> 
> That's one of the scenarios of interest here. We can debate on whether that's proper or not, but the practical consequence is that if I have two (or N) apps that can call APIs via tokens obtained with the implicit flow, eliminating AS the session cookie will prevent them from getting new tokens automatically, without the developer having to write any code for "signout".
> The moment in which apps switch to code and hold on to RTs, the sheer fact that the AS session cookie is gone will NOT stop individual apps from being able to get new access tokens and call API.
> That would be an unintended consequence of the switch to code, and regardless of whether it's a consequence of people abusing the protocol or not, I think this scenario should be documented and people should be warned against it.

The AS is ultimately responsible for the security policy, though - if the AS policy isn’t supposed to allow my application access after the user hits log out, it should either:
1. Tie my application refresh tokens to be revoked at the logout event
2. Not give out refresh tokens to my application

Note that the session cookie is fulfilling the role of the refresh token in the second case. Also note that telling a browser to discard the cookie is not as good as supporting revoking it - if there is no revocation mechanism, a third party who gets the cookie/refresh token can use it for as long as policy allows.

I don’t expect application developers to use libraries that locally enforce more restrictive policy just because the operators of the AS aren’t doing their job setting appropriate policy for their clients. So this is really more of something that the AS needs to understand about their own policy.

-DW