> 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"
<oauth-boun...@ietf.org on behalf of torsten=40lodderstedt....@dmarc.ietf.org>
wrote:
Hi Philippe,
> On 16. May 2020, at 17:08, Philippe De Ryck
<phili...@pragmaticwebsecurity.com> 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
