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 <da...@alkaline-solutions.com> wrote: > > > On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci < > Vittorio=40auth0....@dmarc.ietf.org> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
