Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation

[Vittorio Bertocci]

> logout at the authorization server

One important detail here is that if the refresh token has been obtained by 
including the scope "offline_access", then its lifetime should not be tied to 
the lifetime of the session (see 
https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess), hence 
revoking it on logout would be violating the contract thru which it has been 
obtained. Think classic scheduled tweets scenarios, a web app tweeting on my 
behalf at a given time should retain the ability to get tokens for calling the 
twitter API regardless of whether I am signed in the web app at the moment of 
the call.
For many platforms, requesting"'offline_access" is the only way of obtaining a 
refresh token- hence this point is important as it has wide impact in popular 
platforms.
That's also why there was a proposal to introduce an "online_access" scope to 
make this difference explicit, but I haven't followed that effort in a while.


On 5/16/20, 10:50, "OAuth on behalf of Torsten Lodderstedt" 
 
wrote:

Hi Philippe, 

> On 16. May 2020, at 17:08, Philippe De Ryck 
 wrote:
> 
> Hi all,
> 
> I am working on formulating developer guidelines on using Refresh Token 
Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps". 
> 
> The protection offered by RTR kicks in the moment a refresh token is used 
twice, so the assumption is that the attacker has the ability to steal tokens 
from the client. In general, this means the attacker has malicious code running 
in the application (e.g., XSS, remote JS inclusion, ...). 
> 
> Within these constraints, I can think of a couple of malicious payloads 
that sidestep the protection offered by RTR:
> 
> 1. Stealing access tokens in an online XSS attack
> 2. Stealing refresh tokens, but waiting to use the latest until the 
original client is no longer active
> 3. Running a silent authentication flow in an iframe to obtain a new and 
unrelated AT and RT, and use that until it expires
> 
> Scenario 1 is straightforward in most applications, but the attack 
requires the vulnerable application to remain online. Scenario 2 might be 
difficult if the RT is kept out of reach from the main application (e.g. in a 
worker thread). Scenario 3 is most dangerous, but also a bit tricky to 
implement as the payload needs to make sure the application's code does not 
interfere (however, the browser's Same-Origin Policy will not intervene). The 
specifics depend on the concrete implementation, but all three attacks are 
technically feasible.
> 
> With these attacks in mind, it seems that the use of the Authorization 
Code flow with RTR does not really add much improvement for security, if other 
best practices are followed (e.g., using HTTPS). RTR does a lot for usability 
and handling third-party cookie blocking scenarios though.

I also see this as the main advantage of RTs.

I think scenario 3 can be made more difficult for the attacker by requiring 
user interaction. That’s ok since the normal case would be to refresh via RT 
and not via authorization flow, so the legit app shouldn’t be affected. 

> 
> In this context, my advice to developers is to avoid handling tokens in 
the browser in security-sensitive scenarios. A Backend-for-frontend pattern 
gives a server-side component control over tokens, along with the ability to 
implement additional security measures.

I full agree with those advice. Handling security sensitive aspects of the 
app out of reach of the user (which might be an attacker) is a good idea. On 
the functional side, this also gives the app access to authentication and 
sender constrained access tokens via mTLS.

> 
> Additionally, is there any official recommendation to link the validity 
of a refresh token to the lifetime of the user's session with the Authorization 
Server? Having that property gives RTR similar security properties as the 
silent renew scenario. 

Section 4.12.2. of the Security BCP recommends refresh token revocation in 
case of logout. 

best regards,
Torsten. 

> 
> Any feedback on this train of thought is more than welcome.
> 
> Philippe
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation

[Philippe De Ryck]

Hi Torsten,

> On 16 May 2020, at 19:50, Torsten Lodderstedt  wrote:
> 
> Hi Philippe, 
> 
>> On 16. May 2020, at 17:08, Philippe De Ryck 
>>  wrote:
>> 
>> Hi all,
>> 
>> I am working on formulating developer guidelines on using Refresh Token 
>> Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps". 
>> 
>> The protection offered by RTR kicks in the moment a refresh token is used 
>> twice, so the assumption is that the attacker has the ability to steal 
>> tokens from the client. In general, this means the attacker has malicious 
>> code running in the application (e.g., XSS, remote JS inclusion, ...). 
>> 
>> Within these constraints, I can think of a couple of malicious payloads that 
>> sidestep the protection offered by RTR:
>> 
>> 1. Stealing access tokens in an online XSS attack
>> 2. Stealing refresh tokens, but waiting to use the latest until the original 
>> client is no longer active
>> 3. Running a silent authentication flow in an iframe to obtain a new and 
>> unrelated AT and RT, and use that until it expires
>> 
>> Scenario 1 is straightforward in most applications, but the attack requires 
>> the vulnerable application to remain online. Scenario 2 might be difficult 
>> if the RT is kept out of reach from the main application (e.g. in a worker 
>> thread). Scenario 3 is most dangerous, but also a bit tricky to implement as 
>> the payload needs to make sure the application's code does not interfere 
>> (however, the browser's Same-Origin Policy will not intervene). The 
>> specifics depend on the concrete implementation, but all three attacks are 
>> technically feasible.
>> 
>> With these attacks in mind, it seems that the use of the Authorization Code 
>> flow with RTR does not really add much improvement for security, if other 
>> best practices are followed (e.g., using HTTPS). RTR does a lot for 
>> usability and handling third-party cookie blocking scenarios though.
> 
> I also see this as the main advantage of RTs.
> 
> I think scenario 3 can be made more difficult for the attacker by requiring 
> user interaction. That’s ok since the normal case would be to refresh via RT 
> and not via authorization flow, so the legit app shouldn’t be affected. 

Preventing a silent flow from happening would indeed stop this attack vector, 
but it might create usability problems in single page applications.

A typical scenario is an SPA running a silent authentication flow in an iframe 
when it is first started. This allows the app to bootstrap itself with the 
user’s authentication status if a session already exists. This pattern is 
common when tokens are kept in memory, as a simple page reload causes that 
state to be cleared. Since Safari and Brave already block third-party cookies, 
they cannot run a silent flow in an iframe. A workaround would be to run a 
top-level silent redirect-based flow to check if an authenticated session 
exists or not. The impact on the UX for this initial redirect is limited, since 
it is silent anyway. By turning off a silent flow, both use cases would stop 
working. 

I totally get that this is a quite challenging problem to address. Given your 
suggestion, the authorization server could prevent iframe-based flows when RTs 
are used, but still allow top-level navigation flows for the bootstrap phase. 
Right now, I don’t think we can implement such a detection mechanism in a 
reliable way, but hopefully the upcoming Sec-Fetch-Dest header can help here 
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest 
)

> 
>> 
>> In this context, my advice to developers is to avoid handling tokens in the 
>> browser in security-sensitive scenarios. A Backend-for-frontend pattern 
>> gives a server-side component control over tokens, along with the ability to 
>> implement additional security measures.
> 
> I full agree with those advice. Handling security sensitive aspects of the 
> app out of reach of the user (which might be an attacker) is a good idea. On 
> the functional side, this also gives the app access to authentication and 
> sender constrained access tokens via mTLS.

That’s precisely my recommendation as well. 

>> 
>> Additionally, is there any official recommendation to link the validity of a 
>> refresh token to the lifetime of the user's session with the Authorization 
>> Server? Having that property gives RTR similar security properties as the 
>> silent renew scenario. 
> 
> Section 4.12.2. of the Security BCP recommends refresh token revocation in 
> case of logout. 

Right, I should have checked that more closely for the details. I also see it 
recommends the timeout after inactivity, which corresponds somewhat to linking 
it to the session lifetime (which would have similar properties). 

Thanks!

Philippe

> 
> best regards,
> Torsten. 
> 
>> 
>> Any feedback on this train of thought is more than welcome.
>> 
>> Philippe
>> 
>> 
>> ___

Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation

[Torsten Lodderstedt]

Hi Philippe, 

> On 16. May 2020, at 17:08, Philippe De Ryck 
>  wrote:
> 
> Hi all,
> 
> I am working on formulating developer guidelines on using Refresh Token 
> Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps". 
> 
> The protection offered by RTR kicks in the moment a refresh token is used 
> twice, so the assumption is that the attacker has the ability to steal tokens 
> from the client. In general, this means the attacker has malicious code 
> running in the application (e.g., XSS, remote JS inclusion, ...). 
> 
> Within these constraints, I can think of a couple of malicious payloads that 
> sidestep the protection offered by RTR:
> 
> 1. Stealing access tokens in an online XSS attack
> 2. Stealing refresh tokens, but waiting to use the latest until the original 
> client is no longer active
> 3. Running a silent authentication flow in an iframe to obtain a new and 
> unrelated AT and RT, and use that until it expires
> 
> Scenario 1 is straightforward in most applications, but the attack requires 
> the vulnerable application to remain online. Scenario 2 might be difficult if 
> the RT is kept out of reach from the main application (e.g. in a worker 
> thread). Scenario 3 is most dangerous, but also a bit tricky to implement as 
> the payload needs to make sure the application's code does not interfere 
> (however, the browser's Same-Origin Policy will not intervene). The specifics 
> depend on the concrete implementation, but all three attacks are technically 
> feasible.
> 
> With these attacks in mind, it seems that the use of the Authorization Code 
> flow with RTR does not really add much improvement for security, if other 
> best practices are followed (e.g., using HTTPS). RTR does a lot for usability 
> and handling third-party cookie blocking scenarios though.

I also see this as the main advantage of RTs.

I think scenario 3 can be made more difficult for the attacker by requiring 
user interaction. That’s ok since the normal case would be to refresh via RT 
and not via authorization flow, so the legit app shouldn’t be affected. 

> 
> In this context, my advice to developers is to avoid handling tokens in the 
> browser in security-sensitive scenarios. A Backend-for-frontend pattern gives 
> a server-side component control over tokens, along with the ability to 
> implement additional security measures.

I full agree with those advice. Handling security sensitive aspects of the app 
out of reach of the user (which might be an attacker) is a good idea. On the 
functional side, this also gives the app access to authentication and sender 
constrained access tokens via mTLS.

> 
> Additionally, is there any official recommendation to link the validity of a 
> refresh token to the lifetime of the user's session with the Authorization 
> Server? Having that property gives RTR similar security properties as the 
> silent renew scenario. 

Section 4.12.2. of the Security BCP recommends refresh token revocation in case 
of logout. 

best regards,
Torsten. 

> 
> Any feedback on this train of thought is more than welcome.
> 
> Philippe
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation

[Philippe De Ryck]

Hi all,

I am working on formulating developer guidelines on using Refresh Token 
Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps". 

The protection offered by RTR kicks in the moment a refresh token is used 
twice, so the assumption is that the attacker has the ability to steal tokens 
from the client. In general, this means the attacker has malicious code running 
in the application (e.g., XSS, remote JS inclusion, ...). 

Within these constraints, I can think of a couple of malicious payloads that 
sidestep the protection offered by RTR:

1. Stealing access tokens in an online XSS attack
2. Stealing refresh tokens, but waiting to use the latest until the original 
client is no longer active
3. Running a silent authentication flow in an iframe to obtain a new and 
unrelated AT and RT, and use that until it expires

Scenario 1 is straightforward in most applications, but the attack requires the 
vulnerable application to remain online. Scenario 2 might be difficult if the 
RT is kept out of reach from the main application (e.g. in a worker thread). 
Scenario 3 is most dangerous, but also a bit tricky to implement as the payload 
needs to make sure the application's code does not interfere (however, the 
browser's Same-Origin Policy will not intervene). The specifics depend on the 
concrete implementation, but all three attacks are technically feasible.

With these attacks in mind, it seems that the use of the Authorization Code 
flow with RTR does not really add much improvement for security, if other best 
practices are followed (e.g., using HTTPS). RTR does a lot for usability and 
handling third-party cookie blocking scenarios though.

In this context, my advice to developers is to avoid handling tokens in the 
browser in security-sensitive scenarios. A Backend-for-frontend pattern gives a 
server-side component control over tokens, along with the ability to implement 
additional security measures.

Additionally, is there any official recommendation to link the validity of a 
refresh token to the lifetime of the user's session with the Authorization 
Server? Having that property gives RTR similar security properties as the 
silent renew scenario. 

Any feedback on this train of thought is more than welcome.

Philippe


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth