Subject: [OAUTH-WG] Refresh Token Expiration

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 15 Nov 2018 15:28:32 +0100

Hi all,

I‘m preparing a new section on Refresh Token best practices for the Security BCP. I‘m wondering whether anyone has implemented a binding of the refresh token‘s expiration/revocation with the state of the session the refresh token was issued in/for. So do you revoke refresh tokens when the user logs out from the AS or the session terminated for other reasons?

kinds regards,
Torsten.

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 15 Nov 2018 16:36:10 +0100

Fwiw, this is something I thought about for Ozwillo but never ended up
implementing (though that still could happen): always issuing a refresh
token (vs. only when scope includes offline_access nowadays) but bind its
lifetime to the session when not offline_access. I would then revoke the
refresh token on logout (like I already do for access tokens), on session
timeouts (this would mean, for me, extending the refresh tokens' expiry
whenever I extend the session expiry), or whenever the session is
terminated (e.g. password change).
The reason I was contemplating this is that some clients/RPs find it hard
to integrate their apps with OpenID Connect / OAuth because they need to
redirect the users to "refresh" the access tokens, and this is not
practical when processing a POST request (e.g. form submission).
The reason I haven't done it yet is that it's been a while since I heard
back from clients on that topic ;-) (though most of them actually simply
use OpenID Connect, and don't make calls to protected resources
afterwards). Others might be using Session Management (will have to check
logs, though I doubt it), which means always having a valid access token as
a side-effect.

On Thu, Nov 15, 2018 at 3:28 PM Torsten Lodderstedt <[email-masked]>
wrote:

> Hi all,
>
> I‘m preparing a new section on Refresh Token best practices for the
> Security BCP. I‘m wondering whether anyone has implemented a binding of the
> refresh token‘s expiration/revocation with the state of the session the
> refresh token was issued in/for. So do you revoke refresh tokens when the
> user logs out from the AS or the session terminated for other reasons?
>
> kinds regards,
> Torsten._______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 20 Nov 2018 15:37:57 -0500

Hi Torsten,

This is the module I much prefer. By default all refresh_tokens are 
bound to the user's authenticated session. When the authentication 
session is terminated, the refresh_tokens are invalidated. If a client 
wants to get a refresh_token that is NOT bound to an authentication 
session, then it much explicitly request the "offline_access" scope 
which then provides a consent interaction with the user which allows the 
user to know that this client wants to access their resources even when 
the user isn't logged in (present). This also provides the AS with the 
ability to control which clients are authorized to request 
"offline_access" and hence restrict that capability to know/approved 
clients.

We've implemented this module in two different Authorization Servers.

Thanks,
George

On 11/15/18 9:28 AM, Torsten Lodderstedt wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 20 Nov 2018 12:56:13 -0800

Hi George,

Reading this description, am I understanding correctly that you *always*
return a refresh token to every client? Are there any situations in which a
refresh token would not be returned? Specifically I'm wondering about how
this applies to browser-based apps using the authorization code flow and
refresh tokens.

----
Aaron Parecki
aaronparecki.com

On Tue, Nov 20, 2018 at 12:38 PM George Fletcher <gffletch=
[email-masked]> wrote:

> Hi Torsten,
>
> This is the module I much prefer. By default all refresh_tokens are bound
> to the user's authenticated session. When the authentication session is
> terminated, the refresh_tokens are invalidated. If a client wants to get a
> refresh_token that is NOT bound to an authentication session, then it much
> explicitly request the "offline_access" scope which then provides a consent
> interaction with the user which allows the user to know that this client
> wants to access their resources even when the user isn't logged in
> (present). This also provides the AS with the ability to control which
> clients are authorized to request "offline_access" and hence restrict that
> capability to know/approved clients.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 20 Nov 2018 16:15:25 -0500

Hi Aaron,

We don't issue refresh_tokens for any implicit flow. So if a browser 
based app were to use the code flow, we would issue a refresh_token. 
Restricting which clients can receive refresh_tokens (or based on some 
other policy) is not a significant addition. However, for most browser 
apps, we have a module the relying party can deploy that handles all the 
code flow semantics on the server side and then the SPA can just request 
a new access_token from the server side module. The module also handles 
sessions management.

Personally, I'm not crazy about refresh_tokens being present in 
browsers. Browsers should just re-authorize if they can't use a 
server-side component for tokens management. OIDC provides a 
"prompt=none" mechanism that allows the browser app to request a new 
token in a hidden iframe. OAuth2 doesn't describe this flow. Note that 
full authentications of users should NOT happen in iframes due to 
click-jacking attacks.

Thanks,
George

On 11/20/18 3:56 PM, Aaron Parecki wrote:
> Hi George,
>
> Reading this description, am I understanding correctly that you 
> *always* return a refresh token to every client? Are there any 
> situations in which a refresh token would not be returned? 
> Specifically I'm wondering about how this applies to browser-based 
> apps using the authorization code flow and refresh tokens.
>
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com>
>
>
>
> On Tue, Nov 20, 2018 at 12:38 PM George Fletcher 
> <gffletch=[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hi Torsten,
>
>     This is the model I much prefer. By default all refresh_tokens are
>     session is terminated, the refresh_tokens are invalidated. If a
>     client wants to get a refresh_token that is NOT bound to an
>     authentication session, then it much explicitly request the
>     "offline_access" scope which then provides a consent interaction
>     with the user which allows the user to know that this client wants
>     to access their resources even when the user isn't logged in
>     (present). This also provides the AS with the ability to control
>     which clients are authorized to request "offline_access" and hence
>     restrict that capability to know/approved clients.
>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 22 Nov 2018 05:49:22 +0100

Hi George,

> Am 20.11.2018 um 22:15 schrieb George Fletcher <[email-masked]>:
> 
> OIDC provides a "prompt=none" mechanism that allows the browser app to request a new token in a hidden iframe. OAuth2 doesn't describe this flow. Note that full authentications of users should NOT happen in iframes due to click-jacking attacks.

Does this still work reliably given the limitations imposed by the browser‘s 3rd party cookie policies?

kind regards,
Torsten.

---

From: Thomas Broyer <[email-masked]>
Date: Thu, 22 Nov 2018 16:47:55 +0100

On Thu, Nov 22, 2018 at 5:50 AM Torsten Lodderstedt <[email-masked]>
wrote:

> > OIDC provides a "prompt=none" mechanism that allows the browser app to
> request a new token in a hidden iframe. OAuth2 doesn't describe this flow.
> Note that full authentications of users should NOT happen in iframes due to
> click-jacking attacks.
>

Fwiw, I haven't had any problem (yet) with my OpenID Connect Session
Management implementation.

---

From: George Fletcher <[email-masked]>
Date: Thu, 22 Nov 2018 14:08:47 -0500

My understanding is that cookies are not blocked on redirects 
(IPT2/Safari) but I haven't done extensive testing. So from a full-page 
redirect perspective there should be no issues, from a hidden iframe I'm 
not sure... but I believe it will work.

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 23 Nov 2018 14:34:28 +0100

Just tested my OpenID Connect Session Management implementation with Safari
12.0.1 and it works like a charm.

On Thu, Nov 22, 2018 at 8:09 PM George Fletcher <gffletch=
[email-masked]> wrote:

> Am 20.11.2018 um 22:15 schrieb George Fletcher <[email-masked]> <[email-masked]>:
>

---

From: Reman Child <[email-masked]>
Date: Fri, 23 Nov 2018 09:16:40 -0800

Thomas, did you test with ITP Debug Mode? If you haven't seen it, this is
how to set it up:
https://webkit.org/blog/8387/itp-debug-mode-in-safari-technology-preview-62/

When I tested a couple months ago, the iframe flows were the ones that were
most affected by ITP2 - the hidden iframe token refresh didn't work, and it
seemed like the session management flows would also break (although didn't
test them explicitly). If the domain is marked as a tracker and it's loaded
in an iframe, it will not have access to its first party cookies. This
differs from ITP 1.1, where there was a 1-day window where it would work
before the cookies were purged. Safari did add some new storage methods to
get access to these cookies, but they don't really help with these
non-interactive flows because by design they require user interaction.

On Fri, Nov 23, 2018 at 5:35 AM Thomas Broyer <[email-masked]> wrote:

> Just tested my OpenID Connect Session Management implementation with
> Safari 12.0.1 and it works like a charm.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 28 Nov 2018 11:20:00 +0100

with the default cookie policy? 

> Am 23.11.2018 um 14:34 schrieb Thomas Broyer <[email-masked]>:
> 
> Just tested my OpenID Connect Session Management implementation with Safari 12.0.1 and it works like a charm.
> 
> On Thu, Nov 22, 2018 at 8:09 PM George Fletcher <gffletch=[email-masked]> wrote:
> My understanding is that cookies are not blocked on redirects (IPT2/Safari) but I haven't done extensive testing. So from a full-page redirect perspective there should be no issues, from a hidden iframe I'm not sure... but I believe it will work.
> 
>

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 28 Nov 2018 11:59:52 +0100

Yes, that was with the default cookie policy (on a coworker's macbook, and
he doesn't use safari as his main browser)

---

From: Reman Child <[email-masked]>
Date: Wed, 28 Nov 2018 04:22:09 -0800

ITP cookie blocking doesn't kick in until a site is classified as a tracker
- if it's a fresh browser, everything will work. That's why you need to
test with the ITP debug tools to set your site as prevalent.

On Wed, Nov 28, 2018 at 3:00 AM Thomas Broyer <[email-masked]> wrote:

>> [email-masked]..org <[email-masked]>> wrote:
>> >>> OIDC provides a "prompt=none" mechanism that allows the browser app
>> to request a new token in a hidden iframe. OAuth2 doesn't describe this
>> flow. Note that full authentications of users should NOT happen in iframes
>> due to click-jacking attacks.
>> >>>