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

[Vittorio Bertocci <[e-mail]>]

I think we are running in circles. I am not talking about what provides
should do in an ideal world, I am describing something that some providers
do today that can impact developers in unintended ways if not take into
account. We can agree that in the ideal world providers would take steps to
fix the situation, and we should encourage to do so; but in the meanwhile
if we don't warn people of those potential issues, some people might end up
having issues. Let me try to rephrase one more time to see if I manage to
explain the issue I am concerned about here.

If you don't issue refresh tokens, the problem I am discussing doesn't
occur hence we can ignore that case.
I think that the point getting lost is: if you issue refresh tokens, per
the longer description in my mail many widely adopted providers will issue
refresh tokens whose validity doesn't end when the auth session from which
they originated is disposed of. I am not debating whether that's the way it
should be or not: it's a reality developers need to deal with today and
that they are powerless to change overnight.
The result is that if SPA apps are instructed to use refresh tokens as a
way of getting new tokens, as opposed to the usual implicit trick, they'll
now have a mean to get new tokens that is NOT tied to the session.
Whereas with implicit every app relying on the auth session with the AS
instantly loses the ability to call APIs, if developers use refresh tokens
that aren't revoked with the session (and as established, with some
providers they might not have a choice) they will have to perform explicit
steps to probe whether the auth session is still ongoing, and dispose of
the RTs themselves when it's not.

I already suggested how I think this could be handled in the document:
either not using RTs in the browser at all (for this potential problem,
plus the lack of support for rotating RTs, plus the discussions about the
difficulties storing them in XSS resistant fashion), or if we advise using
RTs at least giving specific warnings about this scenario (making sure that
the RTs issued by the provider of choice are session bound, and if they
aren't suggest to developers to take measures like deleting RTs explicitly
upon deletion of the auth session w the AS).(*)
This doesn't absolve the providers from aligning their capabilities to the
bar the scenario requires, but at least saves developers from introducing
new issues in their apps as they move away from implicit.


Some specific notes:

>Note that the session cookie is fulfilling the role of the refresh token
in the second case.

Yep. That's what I was suggesting with only retrieving the code in the
hidden browser and prompt=none for background renewals, no strict need for
RTs.
Note that I'd *love* to be able to use RTs in the browser as it would work
around the issues with ITP2; but it seems there are issues to iron out
before they can be adopted mainstream, or at least more guidance is
necessary than the one we've been giving so far.


> 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.

Of course. I am not saying I don't want providers to support revocation, I
am saying today some important ones do not today. The fact that the
mitigation a developer can do when explicitly managing artifacts lifecycle
isn't as good as the one the provider could eventually do doesn't mean it's
worthless, especially when it's the only mitigation available.


>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.

I don't understand this. Put yourself in the shoes of a developer using one
of those providers. For those developers, the feature set of their AS is an
externality- like the weather. They can make feature requests, fill survey,
send angry tweets- but if their entire codebase depend on tokens issued by
the AS and that AS only issues RTs with offline_access semantic, knowing
that the identirati don't agree with that limitation won't help them one
bit to update their app to code flow from implicit. Given that there are
things we can tell them (*) to either sidestep the problem altogether, or
at least handle it, I am not sure I understand the pushback on providing
that level of clarity.


On Sun, Dec 9, 2018 at 12:57 AM David Waite <[e-mail]>
wrote:

>
>
> 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
>