Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

["Brock Allen" <[e-mail]>]

> Helps to prevent leakage, not injection in the authorization response.

So then wording and its motivation could get updated to correctly reflect that.

>> "OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client."
>> 
>> Sure, but OIDC does provide a mitigation for this (even with implicit).
>
>This is about token replay detection at the RS. What mitigation does OIDC provide here? 

The wording doesn't go with that, then. My point about OIDC is that with the at_hash in the id_token provides a mitigation so the client can verify that the access token was issued to it.

> The implicit grant was not equipped with the ability to issue refresh tokens simply because the working group didn’t want them to end up in the browser history, leak through open redirectors etc. This is different with code since tokens travel directly through a TLS protected connection.

Well, if limiting the access token renewal to the user's session lifetime wasn't a conscious design goal, it's a very interesting side effect which does limit the potential of an attacker.

> First of all the AS decides whether it issues refresh tokens or not. Having the ability does not mean the AS must do it. If you feel it’s safer to not do it. Fine. 

Sure, and this should be mentioned then somewhere (either in the threats doc or in this proposed best practice doc). Not all end developers using these protocols fully understand the ramifications. 

> It’s still possible to refresh your access tokens the way you mentioned above by sending another authorization request to the AS. 


This also could be added as a proposal for an alternative to renewing tokens. It provides more awareness to folks, and aids in a potential best practice depending on the requirements of the consuming app.

> But let’s assume for a moment the AS, based on its risk assessment, decides to issue refresh tokens. Can you please explain how an attacker will get access to this tokens? Especially what the expected strength of the attacker would need to be?

I don't have a profile of an attack. But I'm assuming it's no different than anything in the past we've been trying to defend against when we considered the potential for an access token to be exfiltrated. So my point is that an access token will expire so an attacker would then have to go back and re-attack the app to get a new access token to continue to have access to the user's resource. But now with refresh tokens in the picture, the attacker would have both and then not need to go back to the app to continue to have access to the user's resource. 

> I would also like to understand how a refresh token is any different from a long living cookie in the browser and what you think is the big difference to mobile apps when it comes to refresh token handling. 

To use the cookie, the app must be active, and the attacker must be attacking the app itself.

Maybe a different way to say it is that an attacker must only compromise the app once to have long lived access, whereas without refresh tokens the attacker can attack the app once, but the once the comprised access token is expired they would have to re-attack the app to get another access token. Refresh tokens means they only have to get in once to the app, then they no longer have to go back to the source. Maybe there's a better way to convey what I'm trying to say...

Also, I guess my question/comment about providing guidance for existing implicit flow clients is not up for discussion? Again, my reasoning is that it's a hard sell to always say there's exactly one right way to do something. And since so many clients have been built based on implicit flow that might not be able to change quickly to a new flow, perhaps there are "baby steps" that can be suggested to help them improve their security.

-Brock