Subject: [OAUTH-WG] Refresh tokens

From: Leo Tohill <[email-masked]>
Date: Mon, 8 Jul 2019 22:10:15 -0400

Ok, I'm creating a new posting for this feedback. :)

Here's where I probably just need some enlightenment, so please help me
out.

Re 8. Refresh Tokens

   "For public clients, the risk of a leaked refresh token is much
   greater than leaked access tokens, since an attacker can potentially
   continue using the stolen refresh token to obtain new access without
   being detectable by the authorization server.  "

(first, note the typo "stoken".)

Is it always "higher risk"?  I could even argue that leakage of a refresh
token is lower risk. As a bearer document, a leaked access token allows
access to resources until it expires.  A leaked refresh token, to be
useful,  requires an exchange with the AS, and the AS would have the
opportunity to check whether the refresh token is still valid (has not been
revoked).  (of course revocation might NOT have happened, but then again,
it might have.)

Furthermore, since the access token is transmitted to other servers, the
risk of exposure is greater, due to possible vulnerabilities in those
called systems (e.g., logs).  Isn't this the reason that we have refresh
tokens? Don't refresh tokens exist because access tokens should have short
TTL, because they are widely distributed?

"Additionally, browser-based applications provide many attack vectors by
which a refresh token can be leaked."

The risks of leaking a refresh token from the browser are identical to the
risks of leaking an access token, right?  This sentence could be changed to
"... by which *a token* can be leaked."

A refresh token is "higher risk" because its TTL is usually greater than
the access token's TTL.  But if our advice here leads to people using
longer-lived access tokens (because of the problems with getting a new
access token without involving the user), then the advice will be counter
productive.   The longer life gives more time for the usefulness of a
browser-side theft, and more time for the usefulness of a server-side
theft.

Which scenario is safer?

A) using an access token with a 10 minute TTL, accompanied by a refresh
token with a 1 hour TTL
B) using an access token with a 1 hour TTL, and no refresh token.

I'd say that A is safer. (Unless, when the refresh token is used, a new
refresh token is issued, the NEW refresh token gets another 1 hour.  If
this is the case, one could maintain refresh tokens infinitely. Is this
point addressed somewhere?)

---

From: David Waite <[email-masked]>
Date: Mon, 8 Jul 2019 20:17:39 -0700

> On Jul 8, 2019, at 7:10 PM, Leo Tohill <[email-masked]> wrote:
> Re 8. Refresh Tokens
> 
> Is it always "higher risk"?  I could even argue that leakage of a refresh token is lower risk. As a bearer document, a leaked access token allows access to resources until it expires.  A leaked refresh token, to be useful,  requires an exchange with the AS, and the AS would have the opportunity to check whether the refresh token is still valid (has not been revoked).  (of course revocation might NOT have happened, but then again, it might have.) 

I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (by policy) to an authentication session lifetime. It is far easier to picture refresh tokens which are not attached to an authentication session (sometimes called ‘offline’ access) being inappropriate for a browser-based app, which is nearly always a client that the resource owner is interacting with.

Variants that may want offline tokens are less easy to imagine - perhaps browser extensions?

I believe the language currently there is due to AS implementations predominantly treating refresh tokens as being for offline access, and access token lifetime being short enough to not outlast an authentication session.

> Furthermore, since the access token is transmitted to other servers, the risk of exposure is greater, due to possible vulnerabilities in those called systems (e.g., logs).  Isn't this the reason that we have refresh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely distributed?

Yes. Once you acknowledge the existence of ‘online’ refresh tokens, they become a strong security component:

- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to invalidate access without needing to resort to token introspection/revocation
- Token refresh can theoretically be used to represent other policy changes by both the client (creating tokens targeting a new resource server or with reduced scopes) and server (changing entitlements and attributes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security BCP. A exfiltrated refresh token will result in either the attacker or the user losing access on the next refresh, and a double refresh is a detectable security event by the AS.

> "Additionally, browser-based applications provide many attack vectors by which a refresh token can be leaked."
> 
> The risks of leaking a refresh token from the browser are identical to the risks of leaking an access token, right?  This sentence could be changed to "... by which a token can be leaked."
> 
> A refresh token is "higher risk" because its TTL is usually greater than the access token's TTL.  But if our advice here leads to people using longer-lived access tokens (because of the problems with getting a new access token without involving the user), then the advice will be counter productive.   The longer life gives more time for the usefulness of a browser-side theft, and more time for the usefulness of a server-side theft.  
> 
> Which scenario is safer?
> A) using an access token with a 10 minute TTL, accompanied by a refresh token with a 1 hour TTL

Given tokens that track authentication lifetime, it is hard to make a case that refresh tokens which last for the authentication session are a greater security risk than opaque access tokens (requiring token introspection) that will last the same time. 

Typically an AS (or OP) would issue a structured access token with a lifetime expected to expire before the authentication session, with new tokens issued via requests made in an embedded, iframe (hidden, prompt=none). There may be benefits here of user cookies (or perhaps managed-device information) against an authorization endpoint being used to make decisions that could not be made by a refresh against the token endpoint. 

I’d be interested in hearing how strong of an implementation issue this might be for deployments - I could see a non-security argument that the BCP should only have one recommended approach here, and that there are deployments needing the iframe approach.

-DW

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 8 Jul 2019 20:39:53 -0700

These are all very good points! I think the challenge here is figuring out
where this kind of guidance is most appropriate.

It does seem like some of these issues are unique to a browser environment
(particularly where the browser itself is managing the access and refresh
tokens), so maybe it makes the most sense to include this guidance in the
browser based app BCP?

If there are situations in which this advice is applicable in other
scenarios in addition to browser apps, then I think it would make more
sense to include it in the general OAuth security BCP.

The Security BCP already has some language around refresh tokens, but I
haven't reviewed it in a while to see if all of these points might be
already covered there.

If folks think the Browser BCP is the best place for this kind of thing I
am definitely open to it, and I can work with David on the specific
language to add.

- Aaron

On Mon, Jul 8, 2019 at 8:18 PM David Waite <[email-masked]>
wrote:

> Access tokens and refresh tokens may or may not be attached (by policy) to
> an authentication session lifetime. It is far easier to picture refresh
> tokens which are not attached to an authentication session (sometimes
> called ‘offline’ access) being inappropriate for a browser-based app, which
> is nearly always a client that the resource owner is interacting with.
>
> I believe the language currently there is due to AS implementations
> predominantly treating refresh tokens as being for offline access, and
> access token lifetime being short enough to not outlast an authentication
> session.
>
> - A shorter access token lifetime lets you have centralized policy to
> invalidate access without needing to resort to token
> introspection/revocation
> - Token refresh can theoretically be used to represent other policy
> changes by both the client (creating tokens targeting a new resource server
> or with reduced scopes) and server (changing entitlements and
> attributes/claims embedded within a structured token)
> - Refresh tokens can be one-time-use, as recommenced by the security BCP.
> A exfiltrated refresh token will result in either the attacker or the user
> losing access on the next refresh, and a double refresh is a detectable
> security event by the AS.
>
> Given tokens that track authentication lifetime, it is hard to make a case
> that refresh tokens which last for the authentication session are a greater
> security risk than opaque access tokens (requiring token introspection)
> that will last the same time.
>
> Typically an AS (or OP) would issue a structured access token with a
> lifetime expected to expire before the authentication session, with new
> tokens issued via requests made in an embedded, iframe (hidden,
> prompt=none). There may be benefits here of user cookies (or perhaps
> managed-device information) against an authorization endpoint being used to
> make decisions that could not be made by a refresh against the token
> endpoint.
>
> I’d be interested in hearing how strong of an implementation issue this
> might be for deployments - I could see a non-security argument that the BCP
> should only have one recommended approach here, and that there are
> deployments needing the iframe approach.
>
> -DW
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: David Waite <[email-masked]>
Date: Mon, 8 Jul 2019 23:08:24 -0700

> On Jul 8, 2019, at 8:39 PM, Aaron Parecki <[email-masked]> wrote:
> 
> These are all very good points! I think the challenge here is figuring out where this kind of guidance is most appropriate.
> 
> It does seem like some of these issues are unique to a browser environment (particularly where the browser itself is managing the access and refresh tokens), so maybe it makes the most sense to include this guidance in the browser based app BCP?

Yes, the location is a challenge - the “offline” distinction is defined (arguably under-defined) by OpenID Connect. OAuth (on the other hand) does not take a stand on user authentication sessions, since the tokens are for delegated access.

For confidential clients, both online and offline options make sense. For native apps, the push is usually for long-term access or for a session separate from the external user agent. But for browser apps, you typically want to mirror user authentication.
 
> If there are situations in which this advice is applicable in other scenarios in addition to browser apps, then I think it would make more sense to include it in the general OAuth security BCP.
> 
> The Security BCP already has some language around refresh tokens, but I haven't reviewed it in a while to see if all of these points might be already covered there.
> 
> If folks think the Browser BCP is the best place for this kind of thing I am definitely open to it, and I can work with David on the specific language to add.
> 
> - Aaron

-DW

---

From: George Fletcher <[email-masked]>
Date: Tue, 9 Jul 2019 12:15:32 -0400

I'll just add a couple more thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" 
scenario and should be used there.

2. To use a refresh token at the /token endpoint, client authentication 
is required. This is where it gets difficult for default SPAs because 
they are public clients and the only mechanism to authenticate them is 
the client_id which is itself public. For me, this is the real risk of 
exposing the refresh_token in the browser.

3. If the AS supports rotation of refresh_tokens and an attacker steals 
one and uses it, then the SPA will get an error on it's next attempt 
because it's refresh_token will now be invalid. If the refresh_tokens 
are bound to the user's authentication session, then the user can logout 
to lockout the attacker. However, that is a lot of "ifs" and still 
provides the attacker with time to leverage access via the compromised 
refresh_token.

In principle, I agree with the recommendation that SPAs shouldn't have 
refresh_tokens in the browser. If it's not possible to easily refresh 
the access token via a hidden iframe (becoming more difficult with all 
the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to 
use a simple server component such that the backend for the SPA can use 
authorization_code flow and protect a client_secret.

Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:
>
>> On Jul 8, 2019, at 7:10 PM, Leo Tohill <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> Re 8. Refresh Tokens
>>
>> ???? "For public clients, the risk of a leaked refresh token is much
>> ?? ??greater than leaked access tokens, since an attacker can potentially
>> ?? ??continue using the stolen refresh token to obtain new access without
>> ?? ??being detectable by the authorization server.?? "
>>
>> Is it always "higher risk"??? I could even argue that leakage of a 
>> refresh token is lower risk. As a bearer document, a leaked access 
>> token allows access to resources until it expires.?? A leaked refresh 
>> token, to be useful,?? requires an exchange with the AS, and the AS 
>> would have the opportunity to check whether the refresh token is 
>> still valid (has not been revoked). (of course revocation might NOT 
>> have happened, but then again, it might have.)
>
> Access tokens and refresh tokens may or may not be attached (by 
> policy) to an authentication session lifetime. It is far easier to 
> picture refresh tokens which are not attached to an authentication 
> session (sometimes called ???offline??? access) being inappropriate for a 
> browser-based app, which is nearly always a client that the resource 
> owner is interacting with.
>
> access token lifetime being short enough to not outlast an 
> authentication session.
>
>> Furthermore, since the access token is transmitted to other servers, 
>> the risk of exposure is greater, due to possible vulnerabilities in 
>> those called systems (e.g., logs).?? Isn't this the reason that we 
>> have refresh tokens? Don't refresh tokens exist because access tokens 
>> should have short TTL, because they are widely distributed?
>
> Yes. Once you acknowledge the existence of ???online??? refresh tokens, 
> they become a strong security component:
>
> changes by both the client (creating tokens targeting a new resource 
> server or with reduced scopes) and server (changing entitlements and 
> - Refresh tokens can be one-time-use, as recommenced by the security 
> BCP. A exfiltrated refresh token will result in either the attacker or 
> the user losing access on the next refresh, and a double refresh is a 
> detectable security event by the AS.
>
>> The risks of leaking a refresh token from the browser are identical 
>> to the risks of leaking an access token, right??? This sentence could 
>> be changed to "... by which /a token/ can be leaked."
>>
>> A refresh token is "higher risk" because its TTL is usually greater 
>> than the access token's TTL.?? But if our advice here leads to people 
>> using longer-lived access tokens (because of the problems with 
>> getting a new access token without involving the user), then the 
>> advice will be counter productive.???? The longer life gives more time 
>> for the usefulness of a browser-side theft, and more time for the 
>> usefulness of a server-side theft.
>>
>> Which scenario is safer?
> Given tokens that track authentication lifetime, it is hard to make a 
> case that refresh tokens which last for the authentication session are 
> a greater security risk than opaque access tokens (requiring token 
> introspection) that will last the same time.
>
> lifetime expected to expire before the authentication session, with 
> new tokens issued via requests made in an embedded, iframe (hidden, 
> managed-device information) against an authorization endpoint being 
> used to make decisions that could not be made by a refresh against the 
> token endpoint.
>
> I???d be interested in hearing how strong of an implementation issue 
> this might be for deployments - I could see a non-security argument 
> that the BCP should only have one recommended approach here, and that 
> there are deployments needing the iframe approach.
>
> -DW
>
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 9 Jul 2019 12:22:19 -0400

For historical references only... the Google model around refresh tokens 
and the AOL model around refresh tokens were slightly different. So I 
proposed a bunch of the OIDC text around refresh tokens and offline 
access to allow for both models.

At AOL, the model was that refresh_tokens were bound to the 
authentication session by default. The only way to get an "unbound" 
refresh_token was to request the 'offline_access' scope. We restricted 
which clients could request the 'offline_access' scope and limited it 
mostly to native apps.

I'm happy to recommend errata text (as long as it's just explanatory) to 
the OIDC spec should someone have a recommendation they'd like to make:)

On 7/9/19 2:08 AM, David Waite wrote:
>
>
>> On Jul 8, 2019, at 8:39 PM, Aaron Parecki <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> These are all very good points! I think the challenge here is 
>> figuring out where this kind of guidance is most appropriate.
>>
>> It does seem like some of these issues are unique to a browser 
>> environment (particularly where the browser itself is managing the 
>> access and refresh tokens), so maybe it makes the most sense to 
>> include this guidance in the browser based app BCP?
>
> Yes, the location is a challenge - the ???offline??? distinction is 
> defined (arguably under-defined) by OpenID Connect. OAuth (on the 
> other hand) does not take a stand on user authentication sessions, 
> since the tokens are for delegated access.
>
> For confidential clients, both online and offline options make sense. 
> For native apps, the push is usually for long-term access or for a 
> session separate from the external user agent. But for browser apps, 
> you typically want to mirror user authentication.
>
>> scenarios in addition to browser apps, then I think it would make 
>> more sense to include it in the general OAuth security BCP.
>>
>> The Security BCP already has some language around refresh tokens, but 
>> I haven't reviewed it in a while to see if all of these points might 
>> be already covered there.
>>
>> If folks think the Browser BCP is the best place for this kind of 
>> thing I am definitely open to it, and I can work with David on the 
>> specific language to add.
>>
>> - Aaron
>
> -DW
>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 10 Jul 2019 16:56:01 -0700

>
> 2. To use a refresh token at the /token endpoint, client authentication is
> required. This is where it gets difficult for default SPAs because they are
> public clients and the only mechanism to authenticate them is the client_id
> which is itself public. For me, this is the real risk of exposing the
> refresh_token in the browser.

RFC6749 says "If the client type is confidential or the client was issued
client credentials, the client MUST authenticate..." which I take to mean
that refresh tokens could be used without a client_secret, both for native
an javascript apps.

This discussion of offline vs online refresh tokens is interesting, but I
worry that we may be narrowing our focus here too much.

There's a use where JavaScript apps may be able to take advantage of
offline access, which is around Service Workers. This allows a website to
install some code from a website which can continue to run in the
background, though sometimes only while triggered from external events. One
useful example of this is a syncing daemon, where a push notification can
be sent from a web server to a Service Worker, which could cause that code
in the browser to need to make a request to an API, which then may need to
be able to get a new access token, which is effectively offline access.

----
Aaron Parecki
aaronparecki.com

On Tue, Jul 9, 2019 at 9:16 AM George Fletcher <gffletch=
[email-masked]> wrote:

> 2. To use a refresh token at the /token endpoint, client authentication is
> required. This is where it gets difficult for default SPAs because they are
> public clients and the only mechanism to authenticate them is the client_id
> which is itself public. For me, this is the real risk of exposing the
> refresh_token in the browser.
>
> because it's refresh_token will now be invalid. If the refresh_tokens are
> bound to the user's authentication session, then the user can logout to
> lockout the attacker. However, that is a lot of "ifs" and still provides
> the attacker with time to leverage access via the compromised refresh_token.
>
> refresh_tokens in the browser. If it's not possible to easily refresh the
> access token via a hidden iframe (becoming more difficult with all the
> browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a
> simple server component such that the backend for the SPA can use
> Is it always "higher risk"??? I could even argue that leakage of a refresh
> access to resources until it expires.?? A leaked refresh token, to be
> useful,?? requires an exchange with the AS, and the AS would have the
> revoked).?? (of course revocation might NOT have happened, but then again,
> it might have.)
>
>
> called ???offline??? access) being inappropriate for a browser-based app,
> which is nearly always a client that the resource owner is interacting with.
>
> called systems (e.g., logs).?? Isn't this the reason that we have refresh
> risks of leaking an access token, right??? This sentence could be changed
> to "... by which *a token* can be leaked."
>
> the access token's TTL.?? But if our advice here leads to people using
> productive.???? The longer life gives more time for the usefulness of a
> theft.??
> B) using an access token with a 1 hour TTL, and no refresh token.??
>
>
>
> that will last the same time.??
>
> endpoint.??
> I???d be interested in hearing how strong of an implementation issue this
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 11 Jul 2019 15:51:57 -0400

You are correct that client authentication is not required for public 
clients (which doesn't preclude the use of refresh_tokens) but from my 
perspective it weakens the security because anyone with the 
refresh_token is able to get new access_tokens without any additional proof.

Now if the SPA performs some sort of Dynamic Client Registration or DPoP 
then I think it's a completely different scenario and it doesn't bother 
me as much for their to be refresh_tokens in the browser. This of course 
is just my perspective:)

On 7/10/19 7:56 PM, Aaron Parecki wrote:
>
>     2. To use a refresh token at the /token endpoint, client
>     authentication is required. This is where it gets difficult for
>     default SPAs because they are public clients and the only
>     mechanism to authenticate them is the client_id which is itself
>     public. For me, this is the real risk of exposing the
> RFC6749 says "If the client type is confidential or??the client was 
> issued client credentials,??the client MUST authenticate..." which I 
> take to mean that refresh tokens could be used without a 
> client_secret, both for native an javascript apps.
>
> This discussion of offline vs online refresh tokens is interesting, 
> but I worry that we may be narrowing our focus here too much.
>
> offline access, which is around Service Workers. This allows a website 
> to install some code from a website which can continue to run in the 
> background, though sometimes only while triggered from external 
> events. One useful example of this is a syncing daemon, where a push 
> notification can be sent from a web server to a Service Worker, which 
> could cause that code in the browser to need to make a request to an 
> API, which then may need to be able to get a new access token, which 
> is effectively offline access.
>
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com>
> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher 
> <gffletch=[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     1. I agree with David that refresh_tokens are valuable in an
>     "online" scenario and should be used there.
>
>     2. To use a refresh token at the /token endpoint, client
>     authentication is required. This is where it gets difficult for
>     default SPAs because they are public clients and the only
>     mechanism to authenticate them is the client_id which is itself
>     public. For me, this is the real risk of exposing the
>     3. If the AS supports rotation of refresh_tokens and an attacker
>     steals one and uses it, then the SPA will get an error on it's
>     next attempt because it's refresh_token will now be invalid. If
>     the refresh_tokens are bound to the user's authentication session,
>     then the user can logout to lockout the attacker. However, that is
>     a lot of "ifs" and still provides the attacker with time to
>     leverage access via the compromised refresh_token.
>
>     In principle, I agree with the recommendation that SPAs shouldn't
>     have refresh_tokens in the browser. If it's not possible to easily
>     refresh the access token via a hidden iframe (becoming more
>     difficult with all the browser/privacy cookie changes. e.g.
>     ITP2.X) then I'd recommend to use a simple server component such
>     that the backend for the SPA can use authorization_code flow and
>     protect a client_secret.
>
>     Thanks,
>     George
>
>>>     Is it always "higher risk"??? I could even argue that leakage of
>>>     a refresh token is lower risk. As a bearer document, a leaked
>>>     access token allows access to resources until it expires.?? A
>>>     leaked refresh token, to be useful,?? requires an exchange with
>>>     the AS, and the AS would have the opportunity to check whether
>>>     the refresh token is still valid (has not been revoked).?? (of
>>>     course revocation might NOT have happened, but then again, it
>>>     might have.)
>>
>>     policy) to an authentication session lifetime. It is far easier
>>     to picture refresh tokens which are not attached to an
>>     authentication session (sometimes called ???offline??? access)
>>     being inappropriate for a browser-based app, which is nearly
>>     always a client that the resource owner is interacting with.
>>
>>     I believe the language currently there is due to AS
>>     implementations predominantly treating refresh tokens as being
>>     for offline access, and access token lifetime being short enough
>>     to not outlast an authentication session.
>>
>>>     Furthermore, since the access token is transmitted to other
>>>     servers, the risk of exposure is greater, due to possible
>>>     vulnerabilities in those called systems (e.g., logs).?? Isn't
>>>     this the reason that we have refresh tokens? Don't refresh
>>>     tokens exist because access tokens should have short TTL,
>>>     because they are widely distributed?
>>
>>     Yes. Once you acknowledge the existence of ???online??? refresh
>>     tokens, they become a strong security component:
>>
>>     - A shorter access token lifetime lets you have centralized
>>     policy to invalidate access without needing to resort to token
>>     introspection/revocation
>>     - Token refresh can theoretically be used to represent other
>>     policy changes by both the client (creating tokens targeting a
>>     new resource server or with reduced scopes) and server (changing
>>     entitlements and attributes/claims embedded within a structured
>>     token)
>>     - Refresh tokens can be one-time-use, as recommenced by the
>>     security BCP. A exfiltrated refresh token will result in either
>>     the attacker or the user losing access on the next refresh, and a
>>     double refresh is a detectable security event by the AS.
>>
>>>     "Additionally, browser-based applications provide many attack
>>>     vectors by which a refresh token can be leaked."
>>>
>>>     The risks of leaking a refresh token from the browser are
>>>     identical to the risks of leaking an access token, right??? This
>>>     sentence could be changed to "... by which /a token/ can be leaked."
>>>
>>>     A refresh token is "higher risk" because its TTL is usually
>>>     greater than the access token's TTL.?? But if our advice here
>>>     leads to people using longer-lived access tokens (because of the
>>>     problems with getting a new access token without involving the
>>>     user), then the advice will be counter productive.???? The
>>>     longer life gives more time for the usefulness of a browser-side
>>>     theft, and more time for the usefulness of a server-side theft.??
>>>
>>>     Which scenario is safer?
>>     Given tokens that track authentication lifetime, it is hard to
>>     make a case that refresh tokens which last for the authentication
>>     session are a greater security risk than opaque access tokens
>>     (requiring token introspection) that will last the same time.??
>>
>>     Typically an AS (or OP) would issue a structured access token
>>     with a lifetime expected to expire before the authentication
>>     session, with new tokens issued via requests made in an embedded,
>>     iframe (hidden, prompt=none). There may be benefits here of user
>>     cookies (or perhaps managed-device information) against an
>>     authorization endpoint being used to make decisions that could
>>     not be made by a refresh against the token endpoint.??
>>
>>     I???d be interested in hearing how strong of an implementation
>>     issue this might be for deployments - I could see a non-security
>>     argument that the BCP should only have one recommended approach
>>     here, and that there are deployments needing the iframe approach.
>>
>>     -DW
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf..org/mailman/listinfo/oauth  <https://www.ietf.org/mailman/listinfo/oauth>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 19 Jul 2019 18:49:38 -0500

So what I'm hearing in this thread is essentially that:

1) depending on how it's implemented, using a refresh token in a SPA can
provide security benefits over using only access tokens
2) it is still "dangerous" to allow refresh tokens to be used without
client authentication
3) if there is a way to do some sort of dynamic client registration or
proof of possession, then using a refresh token would in fact be more secure

Since these points are in conflict with each other, and depend on things
currently in flux, it seems like the best thing to do at this time is to
remove the guidance on refresh tokens in browser-based apps. Maybe leaving
the mention of rotating the refresh token on every use, but I'm inclined to
remove the "SHOULD NOT issue refresh tokens" statement in order to leave
room for DPoP or similar in the future.

Sound reasonable?

----
Aaron Parecki
aaronparecki.com

On Thu, Jul 11, 2019 at 2:52 PM George Fletcher <[email-masked]> wrote:

> perspective it weakens the security because anyone with the refresh_token
> is able to get new access_tokens without any additional proof.
>
> then I think it's a completely different scenario and it doesn't bother me
> as much for their to be refresh_tokens in the browser. This of course is
> just my perspective:)
>
>> refresh_token in the browser.??
>
>
> RFC6749 says "If the client type is confidential or??the client was issued
> client credentials,??the client MUST authenticate..." which I take to mean
>> is required. This is where it gets difficult for default SPAs because they
>> are public clients and the only mechanism to authenticate them is the
>> client_id which is itself public. For me, this is the real risk of exposing
>> the refresh_token in the browser.
>>
>> refresh token is lower risk. As a bearer document, a leaked access token
>> allows access to resources until it expires.?? A leaked refresh token, to
>> be useful,?? requires an exchange with the AS, and the AS would have the
>> Access tokens and refresh tokens may or may not be attached (by policy)
>> to an authentication session lifetime. It is far easier to picture refresh
>> The risks of leaking a refresh token from the browser are identical to
>> the risks of leaking an access token, right??? This sentence could be
>> changed to "... by which *a token* can be leaked."
>>
>> case that refresh tokens which last for the authentication session are a
>> greater security risk than opaque access tokens (requiring token
>> introspection) that will last the same time.??
>>
>> OAuth mailing [email-masked]://www.ietf..org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>

---

From: David Waite <[email-masked]>
Date: Fri, 19 Jul 2019 18:33:08 -0600

I believe that access tokens and any refresh token policy should be guided by the user authentication process and session lifetime policy of the AS.

There’s a case to be made that whether someone gets access to my access token directly or a refresh token that allows someone to grant a new access token, they have still gotten access to protected resources.

The case could be made that refresh tokens however are made more powerful by dynamic features:
- requesting an access token with additional scopes
- requesting an access token targeting a new audience/resource (via either scopes-as-resources, or directly with resource indicators)

However, the client has already been granted these scopes or resource access in this theoretical case, so I could just as easily attempt to gather such an access token through the authorization endpoint and code exchange.

So as general points of guidance, how about:
- Refresh tokens serve the same purpose as in general OAuth
- For applications which represent access as part of a user session, access and refresh tokens lifetimes and policy should mirror that session.
- Specifically, an AS should not grant “offline” refresh tokens meant to provide access for an unfixed/extended period of time, as the resource owner may expect other users of the browser would not get access to protected resources
- It is recommended that an AS requires refresh tokens grants to be authenticated to a client instance, be it via a unique client identity through DCR, or ephemerally through a proof-of-possession mechanism (token binding, mtls, dpop)
- Other security BCP stuff should apply.

-DW

> On Jul 19, 2019, at 5:49 PM, Aaron Parecki <[email-masked]> wrote:
> 
> 1) depending on how it's implemented, using a refresh token in a SPA can provide security benefits over using only access tokens
> 2) it is still "dangerous" to allow refresh tokens to be used without client authentication
> 3) if there is a way to do some sort of dynamic client registration or proof of possession, then using a refresh token would in fact be more secure
> 
> Since these points are in conflict with each other, and depend on things currently in flux, it seems like the best thing to do at this time is to remove the guidance on refresh tokens in browser-based apps. Maybe leaving the mention of rotating the refresh token on every use, but I'm inclined to remove the "SHOULD NOT issue refresh tokens" statement in order to leave room for DPoP or similar in the future.
> 
> Sound reasonable?
> 
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com/>
> On Thu, Jul 11, 2019 at 2:52 PM George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
> You are correct that client authentication is not required for public clients (which doesn't preclude the use of refresh_tokens) but from my perspective it weakens the security because anyone with the refresh_token is able to get new access_tokens without any additional proof.
> 
> Now if the SPA performs some sort of Dynamic Client Registration or DPoP then I think it's a completely different scenario and it doesn't bother me as much for their to be refresh_tokens in the browser. This of course is just my perspective:)
> 
>> 2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser.??
>> 
>> RFC6749 says "If the client type is confidential or??the client was issued client credentials,??the client MUST authenticate..." which I take to mean that refresh tokens could be used without a client_secret, both for native an javascript apps.
>> 
>> This discussion of offline vs online refresh tokens is interesting, but I worry that we may be narrowing our focus here too much.
>> 
>> There's a use where JavaScript apps may be able to take advantage of offline access, which is around Service Workers. This allows a website to install some code from a website which can continue to run in the background, though sometimes only while triggered from external events. One useful example of this is a syncing daemon, where a push notification can be sent from a web server to a Service Worker, which could cause that code in the browser to need to make a request to an API, which then may need to be able to get a new access token, which is effectively offline access.
>> 
>> ----
>> Aaron Parecki
>> aaronparecki.com <http://aaronparecki.com/>
>> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher <gffletch=[email-masked] <mailto:[email-masked]>> wrote:
>> 1. I agree with David that refresh_tokens are valuable in an "online" scenario and should be used there.
>> 
>> 2. To use a refresh token at the /token endpoint, client authentication is required. This is where it gets difficult for default SPAs because they are public clients and the only mechanism to authenticate them is the client_id which is itself public. For me, this is the real risk of exposing the refresh_token in the browser. 
>> 
>> 3. If the AS supports rotation of refresh_tokens and an attacker steals one and uses it, then the SPA will get an error on it's next attempt because it's refresh_token will now be invalid. If the refresh_tokens are bound to the user's authentication session, then the user can logout to lockout the attacker. However, that is a lot of "ifs" and still provides the attacker with time to leverage access via the compromised refresh_token.
>> 
>> In principle, I agree with the recommendation that SPAs shouldn't have refresh_tokens in the browser. If it's not possible to easily refresh the access token via a hidden iframe (becoming more difficult with all the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to use a simple server component such that the backend for the SPA can use authorization_code flow and protect a client_secret.
>> 
>> Thanks,
>> George
>> 
>>>> On Jul 8, 2019, at 7:10 PM, Leo Tohill <[email-masked] <mailto:[email-masked]>> wrote:
>>>> Re 8. Refresh Tokens
>>>> 
>>>> Is it always "higher risk"??? I could even argue that leakage of a refresh token is lower risk. As a bearer document, a leaked access token allows access to resources until it expires.?? A leaked refresh token, to be useful,?? requires an exchange with the AS, and the AS would have the opportunity to check whether the refresh token is still valid (has not been revoked).?? (of course revocation might NOT have happened, but then again, it might have.) 
>>> 
>>> Access tokens and refresh tokens may or may not be attached (by policy) to an authentication session lifetime. It is far easier to picture refresh tokens which are not attached to an authentication session (sometimes called ???offline??? access) being inappropriate for a browser-based app, which is nearly always a client that the resource owner is interacting with.
>>> 
>>>> Furthermore, since the access token is transmitted to other servers, the risk of exposure is greater, due to possible vulnerabilities in those called systems (e.g., logs).?? Isn't this the reason that we have refresh tokens? Don't refresh tokens exist because access tokens should have short TTL, because they are widely distributed?
>>> 
>>> Yes. Once you acknowledge the existence of ???online??? refresh tokens, they become a strong security component:
>>> 
>>>> The risks of leaking a refresh token from the browser are identical to the risks of leaking an access token, right??? This sentence could be changed to "... by which a token can be leaked."
>>>> 
>>>> A refresh token is "higher risk" because its TTL is usually greater than the access token's TTL.?? But if our advice here leads to people using longer-lived access tokens (because of the problems with getting a new access token without involving the user), then the advice will be counter productive.???? The longer life gives more time for the usefulness of a browser-side theft, and more time for the usefulness of a server-side theft.?? 
>>>> 
>>>> Which scenario is safer?
>>> Given tokens that track authentication lifetime, it is hard to make a case that refresh tokens which last for the authentication session are a greater security risk than opaque access tokens (requiring token introspection) that will last the same time.??
>>> 
>>> Typically an AS (or OP) would issue a structured access token with a lifetime expected to expire before the authentication session, with new tokens issued via requests made in an embedded, iframe (hidden, prompt=none). There may be benefits here of user cookies (or perhaps managed-device information) against an authorization endpoint being used to make decisions that could not be made by a refresh against the token endpoint.??
>>> 
>>> I???d be interested in hearing how strong of an implementation issue this might be for deployments - I could see a non-security argument that the BCP should only have one recommended approach here, and that there are deployments needing the iframe approach.
>>> 
>>> -DW
>>> 
>>> 
>>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>>

---

From: Justin Richer <[email-masked]>
Date: Sat, 20 Jul 2019 02:57:52 +0000

I think it can be as simple as:

SHOULD NOT use refresh tokens without client authentication or key proof of some kind.

In other words, no bearer refresh tokens.

— Justin

On Jul 19, 2019, at 7:49 PM, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:

Sound reasonable?

----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com/>
@aaronpk<http://twitter.com/aaronpk>

On Thu, Jul 11, 2019 at 2:52 PM George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:
You are correct that client authentication is not required for public clients (which doesn't preclude the use of refresh_tokens) but from my perspective it weakens the security because anyone with the refresh_token is able to get new access_tokens without any additional proof.

----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com/>
@aaronpk<http://twitter.com/aaronpk>

On Tue, Jul 9, 2019 at 9:16 AM George Fletcher <gffletch=[email-masked]<mailto:[email-masked]>> wrote:
I'll just add a couple more thoughts around refresh_tokens.

Thanks,
George

On Jul 8, 2019, at 7:10 PM, Leo Tohill <[email-masked]<mailto:[email-masked]>> wrote:
Re 8. Refresh Tokens

Which scenario is safer?

-DW

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf..org/mailman/listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf..org/mailman/listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Neil Madden <[email-masked]>
Date: Sat, 20 Jul 2019 07:09:36 +0100

Can somebody spell out why refresh tokens require more protection than access tokens? What threat are we worried about?

The security benefits and risks of refresh tokens seem to be consistently emphasised, yet nobody seems to ever spell out exactly what they are. 

The main benefit is allowing timely revocation without the RS having to call a token introspection endpoint. That’s primarily an architectural decision rather than a security one. 

— Neil

> On 20 Jul 2019, at 03:57, Justin Richer <[email-masked]> wrote:
> 
>> On Jul 19, 2019, at 7:49 PM, Aaron Parecki <[email-masked]> wrote:
>> 
>> @aaronpk
>>>> @aaronpk
>>>>> On Tue, Jul 9, 2019 at 9:16 AM George Fletcher <gffletch=[email-masked]> wrote:
>>>>>> https://www.ietf..org/mailman/listinfo/oauth
>>>>> 
>>>> https://www.ietf..org/mailman/listinfo/oauth
>>>

---

From: Leo Tohill <[email-masked]>
Date: Sat, 20 Jul 2019 14:38:30 -0400

Access tokens and refresh tokens, stored browser-side, are equally
vulnerable to theft, because the storage options are identical.

We are more concerned about the theft of the refresh token, because it
(commonly) has a longer usable lifetime than the access token.

Still , its a matter of degree. Since we accept the risk of access token
theft,  why can't we accept the risk of refresh token theft?  We ameliorate
the access token risk by using short lifetimes, but there is no standard
for that value: it is situational.  Why doesn't the same reasoning apply to
refresh tokens?

This reasoning assumes that refresh tokens also have a limited lifetime.  I
am unsure that this is always the case.  When one uses a refresh token to
acquire a new access token, AND that operation issues a new refresh token,
does the new refresh token get a new lifetime?  If so, then a refresh token
can be used to retain access infinitely (or until it is revoked
server-side).  In this scenario, the risks associated with browser-side
storage of refresh token are much higher.

In summary, I'd say that IF the lifetime of a refresh token can be limited,
then refresh tokens pose identical risk as access tokens, and so the same
considerations apply.

without providing specific values.  Why can't we do the same for refresh
tokens?

On Sat, Jul 20, 2019 at 2:10 AM Neil Madden <[email-masked]>
wrote:

> Can somebody spell out why refresh tokens require more protection than
> access tokens? What threat are we worried about?
>
> The security benefits and risks of refresh tokens seem to be consistently
> emphasised, yet nobody seems to ever spell out exactly what they are.
>
> The main benefit is allowing timely revocation without the RS having to
> call a token introspection endpoint. That’s primarily an architectural
> decision rather than a security one.
>
> — Neil
>
>>> the refresh_token in the browser.??
>>
>>
>> issued client credentials,??the client MUST authenticate..." which I take
>> to mean that refresh tokens could be used without a client_secret, both for
>> native an javascript apps.
>>
>>> BCP. A exfiltrated refresh token will result in either the attacker or the
>>> user losing access on the next refresh, and a double refresh is a
>>> this might be for deployments - I could see a non-security argument that
>>> the BCP should only have one recommended approach here, and that there are

---

From: David Waite <[email-masked]>
Date: Sat, 20 Jul 2019 12:54:17 -0600

> On Jul 20, 2019, at 12:38 PM, Leo Tohill <[email-masked]> wrote:
> 
> Access tokens and refresh tokens, stored browser-side, are equally vulnerable to theft, because the storage options are identical. 
> 
> We are more concerned about the theft of the refresh token, because it (commonly) has a longer usable lifetime than the access token. 
> 
> Still , its a matter of degree. Since we accept the risk of access token theft,  why can't we accept the risk of refresh token theft?  We ameliorate the access token risk by using short lifetimes, but there is no standard for that value: it is situational.  Why doesn't the same reasoning apply to refresh tokens? 
> 
> This reasoning assumes that refresh tokens also have a limited lifetime.  I am unsure that this is always the case.  When one uses a refresh token to acquire a new access token, AND that operation issues a new refresh token, does the new refresh token get a new lifetime?  If so, then a refresh token can be used to retain access infinitely (or until it is revoked server-side).  In this scenario, the risks associated with browser-side storage of refresh token are much higher. 
> 
> In summary, I'd say that IF the lifetime of a refresh token can be limited, then refresh tokens pose identical risk as access tokens, and so the same considerations apply. 

Agreed

I think there is an unwritten framework for evaluating the security of all tokens, regardless of type. For example: access tokens are shared with resources, so their security protections in the Security BCP including limiting replay against other resources, and optionally against new requests against the same resource.

Because it is complex and unwritten, it is hard to do a true evaluation. My impression was always that refresh tokens were more ‘risky’ for public clients because “offline” refresh tokens may be good for an indeterminate period of time, and because lack of credentials means theft of the token is sufficient.

In addition, a public client which does not use its refresh token in an “offline” manner may have theft go unnoticed for a considerable period of time, and the operational model of public clients usually puts detection of local token theft in the hand of the end user and client software, not an administrator or organizational security staff.

But those concerns are mostly mitigated if the OP can set policy to control refresh token usage in concert with the authentication session.

-DW

---

From: Leo Tohill <[email-masked]>
Date: Sat, 20 Jul 2019 15:45:20 -0400

I did some looking around regarding the lifetime of refresh tokens in
various OP services.

Auth0 <https://auth0.com/docs/tokens/refresh-token/current>,and google
<https://developers.google.com/identity/protocols/OpenIDConnect#refresh-tokens>
do not appear to support a limited lifetime on refresh tokens.
AWS
<https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html>supports
a lifetime, but with day granularity (minimum 1 day).  It does not issue a
new refresh token when one is redeemed.
IdentityServer
<http://docs.identityserver.io/en/latest/topics/refresh_tokens.html>allows
a choice of behavior on refresh token expiration time.  It can have a
absolute expiration time, or use a sliding window.

I couldn't find anything in oauth or openid specs regarding refresh token
lifetime.

I'm thinking that our language might say that "if the OP supports refresh
token (absolute) lifetime, refresh tokens may be used (in the browser), but
should (must?) specify a expiration time."

On Sat, Jul 20, 2019 at 2:54 PM David Waite <[email-masked]>
wrote:

> > This reasoning assumes that refresh tokens also have a limited
> lifetime.  I am unsure that this is always the case.  When one uses a
> refresh token to acquire a new access token, AND that operation issues a
> new refresh token, does the new refresh token get a new lifetime?  If so,
> then a refresh token can be used to retain access infinitely (or until it
> is revoked server-side).  In this scenario, the risks associated with
> browser-side storage of refresh token are much higher.
> >
> > In summary, I'd say that IF the lifetime of a refresh token can be
> limited, then refresh tokens pose identical risk as access tokens, and so
> the same considerations apply.
>
> Agreed
>
> I think there is an unwritten framework for evaluating the security of all
> tokens, regardless of type. For example: access tokens are shared with
> resources, so their security protections in the Security BCP including
> limiting replay against other resources, and optionally against new
> requests against the same resource.
>
> Because it is complex and unwritten, it is hard to do a true evaluation.
> My impression was always that refresh tokens were more ‘risky’ for public
> clients because “offline” refresh tokens may be good for an indeterminate
> period of time, and because lack of credentials means theft of the token is
> sufficient.
>
> In addition, a public client which does not use its refresh token in an
> “offline” manner may have theft go unnoticed for a considerable period of
> time, and the operational model of public clients usually puts detection of
> local token theft in the hand of the end user and client software, not an
> administrator or organizational security staff.
>
> But those concerns are mostly mitigated if the OP can set policy to
> control refresh token usage in concert with the authentication session.
>
> -DW

---

From: "Brock Allen" <[email-masked]>
Date: Sun, 21 Jul 2019 10:44:40 -0400

> IdentityServer allows a choice of behavior on refresh token expiration time. It can have a absolute expiration time, or use a sliding window.

FWIW, in addition, those can be used together -- sliding & absolute. Finally, refresh tokens can be re-use or one-time use only. These are all per-client settings.

-Brock

---

From: Leo Tohill <[email-masked]>
Date: Sun, 21 Jul 2019 22:22:32 -0400

I left out Okta
<https://developer.okta.com/docs/guides/refresh-tokens/overview/>(how could
I?)  - it supports a refresh token expiration, but I couldn't find doc on
the details.

On Sun, Jul 21, 2019 at 10:44 AM Brock Allen <[email-masked]> wrote:

> > IdentityServer allows a choice of behavior on refresh token expiration
> time. It can have a absolute expiration time, or use a sliding window.
>
> FWIW, in addition, those can be used together -- sliding & absolute.
> Finally, refresh tokens can be re-use or one-time use only. These are all
> per-client settings.
>
> -Brock
>
>

---

From: Tomek Stojecki <[email-masked]>
Date: Mon, 22 Jul 2019 11:03:34 +0000 (UTC)

> FWIW, in addition, those can be used together -- sliding & absolute. 

Azure AD does both at this point. They used to do 90 days absolute, now it is a sliding, 72 hours by default I believe. 

Good discussion overall, would this be a good summary for the type of a client the spec is for:

SHOULD NOT use refresh tokens unless the token endpoint mirrors user authentication or the OP supports expiration, rotation and revocation of refresh tokens

-Brock

---

From: Neil Madden <[email-masked]>
Date: Mon, 22 Jul 2019 12:59:13 +0100

Thank you both for your replies, my responses are below:

> Because it is complex and unwritten, it is hard to do a true evaluation. My impression was always that refresh tokens were more ‘risky’ for public clients because “offline” refresh tokens may be go…

Access tokens (without PoP) are also usable without credentials, so this is not a reason why refresh tokens are more risky. From the responses, it appears that token lifetime is the primary concern - access tokens usually have a limited lifespan but refresh tokens are unlimited. But there are very few threats that are eliminated by short token lifetimes. For example, when somebody goes for a coffee leaving their computer or phone unlocked. But even in these cases you are normally concerned with idle-timeouts rather than overall token lifetime. The token should become invalid after 3 minutes of inactivity, for example.

> In addition, a public client which does not use its refresh token in an “offline” manner may have theft go unnoticed for a considerable period of time, and the operational model of public clients u…

Given that a refresh token has to be used at the AS, isn't the situation here *better* for refresh tokens? Every time an attacker uses a stolen refresh token you get a nice ping against your centralised token endpoint, giving you a great opportunity to run contextual checks to decide if something looks fishy. 

> But those concerns are mostly mitigated if the OP can set policy to control refresh token usage in concert with the authentication session.

I'm not sure that OAuth should tie itself to a concept of authentication session. Would it be better to say that all tokens issued to browser-based clients should have a short idle timeout?

There's also a privacy aspect to linking refresh tokens to a user's authentication session, as it gives the 3rd-party client a way to detect when you are/are not logged into Facebook or whatever. That may be desirable in some cases, but not necessarily always. 

-- Neil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Jul 2019 14:12:35 +0200

Hi Neil,

> On 22. Jul 2019, at 13:59, Neil Madden <[email-masked]> wrote:
> 

I agree with your assessment. 

That why the Security BCP (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12) requires authorisation servers to detect refresh token replay. Even if the refresh token cannot be sender constraint, one-time refresh tokens (or refresh token rotation) is a viable option when used in combination with conditional revocation of the active refresh token if something looks fishy.

kind regards,
Torsten.

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 24 Jul 2019 19:12:20 -0400

Ok thanks for the input here everyone. I'm not seeing much of a consensus,
but these are all excellent points and I've collected them for discussion
during the meeting on Friday.

----
Aaron Parecki
aaronparecki.com

On Mon, Jul 22, 2019 at 8:12 AM Torsten Lodderstedt <[email-masked]>
wrote:

> > Given that a refresh token has to be used at the AS, isn't the situation
> here *better* for refresh tokens? Every time an attacker uses a stolen
> refresh token you get a nice ping against your centralised token endpoint,
> giving you a great opportunity to run contextual checks to decide if
> something looks fishy.
>
> That why the Security BCP (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4..12)
> requires authorisation servers to detect refresh token replay. Even if the
> refresh token cannot be sender constraint, one-time refresh tokens (or
> refresh token rotation) is a viable option when used in combination with
> conditional revocation of the active refresh token if something looks fishy.
>
> kind regards,
> Torsten. _______________________________________________
> OAuth mailing list
> [email-masked]