Subject: [OAUTH-WG] First Draft of OAuth 2.1

From: Aaron Parecki <[email-masked]>
Date: Wed, 11 Mar 2020 17:28:22 -0700

I'm happy to share that Dick and Torsten and I have published a first
draft of OAuth 2.1. We've taken the feedback from the discussions on
the list and incorporated that into the draft.

https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01

A summary of the differences between this draft and OAuth 2.0 can be
found in section 12, and I've copied them here below.

> This draft consolidates the functionality in OAuth 2.0 (RFC6749),
> OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
> (RFC7636), OAuth 2.0 for Browser-Based Apps
> (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
> Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
> (RFC6750).
>
>   Where a later draft updates or obsoletes functionality found in the
>   original [RFC6749], that functionality in this draft is updated with
>   the normative changes described in a later draft, or removed
>   entirely.
>
>   A non-normative list of changes from OAuth 2.0 is listed below:
>
>   *  The authorization code grant is extended with the functionality
>      from PKCE ([RFC7636]) such that the only method of using the
>      authorization code grant according to this specification requires
>      the addition of the PKCE mechanism
>
>   *  Redirect URIs must be compared using exact string matching as per
>      Section 4.1.3 of [I-D.ietf-oauth-security-topics]
>
>   *  The Implicit grant ("response_type=token") is omitted from this
>      specification as per Section 2.1.2 of
>      [I-D.ietf-oauth-security-topics]
>
>   *  The Resource Owner Password Credentials grant is omitted from this
>      specification as per Section 2.4 of
>      [I-D.ietf-oauth-security-topics]
>
>   *  Bearer token usage omits the use of bearer tokens in the query
>      string of URIs as per Section 4.3.2 of
>      [I-D.ietf-oauth-security-topics]
>
>   *  Refresh tokens must either be sender-constrained or one-time use
>      as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]

https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12

I'm excited for the direction this is taking, and it has been a
pleasure working with Dick and Torsten on this so far. My hope is that
this first draft can serve as a good starting point for our future
discussions!

----
Aaron Parecki
aaronparecki.com
@aaronpk

P.S. This notice was also posted at
https://aaronparecki.com/2020/03/11/14/oauth-2-1

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Thu, 12 Mar 2020 06:11:08 +0000

Hi,

I just read the document and have minor feedback:

Under "2.3 Client Authentication" you mention mTLS (RFC8705) and reference OpenID.
I am kind of missing RFC7523 here (JWT client authentication). Also, the OpenID link is broken.

Best
Martin

> On 12. Mar 2020, at 01:28, Aaron Parecki <[email-masked]> wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 12 Mar 2020 11:24:17 -0700

Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint |
rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the discussion
for dPOP, hence I won't go in the details here.
Rotation isn't something that can be added without significant impact on
development and runtime experiences:

   - on distributed scenarios, it introduces the need to serialize access
   to shared caches
   - network failures can lead to impact on experience- stranding clients
   which fail to receive RTn+1 during RTn redemption in a limbo where user
   interaction might become necessary, disrupting experience or functionality
   for scenarios where the user isn't available to respond.
   -

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 12 Mar 2020 11:28:08 -0700

damnit, i hit enter too soon.
  Hey guys,

   - on distributed scenarios, it introduces the need to serialize access
   to shared caches
   - network failures can lead to impact on experience- stranding clients
   which fail to receive RTn+1 during RTn redemption in a limbo where user
   interaction might become necessary, disrupting experience or functionality
   for scenarios where the user isn't available to respond.
   - remediations currently in the wild for this are either clunky (grace
   periods) or downright cumbersome (waiting for the AT refreshed via RTn to
   be used by the client to invalidate RTn, which locks RS and AS in a
   transaction that is both expensive and itself subject to network failure)

I think it's fine to recommend using those mechanisms with a SHOULD, but
imposing those complexities to everyone in the core is asking too much IMO.
Thanks
V.

On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci <[email-masked]>
wrote:

> Sender constraint isn't immediately actionable - we just had the
> discussion for dPOP, hence I won't go in the details here.

---

From: Mike Jones <[email-masked]>
Date: Thu, 12 Mar 2020 18:35:04 +0000

+1 on sender constraints being RECOMMENDED but not REQUIRED.  Different applications have different risk profiles.  We should enable people to make reasonable choices for their use cases.

Remember that OAuth 1.0 was rejected by the marketplace because implementing the sender-constraint mechanism specified was perceived as too hard.  That’s why we have OAuth 2.0.  Particularly given that there’s not a deployable sender-constraint standard (other than MTLS, which is deployable for some use cases), we should put ourselves in developer’s shoes when telling them what they MUST do.  If we overreach, the OAuth 1.0 experience tells us they’ll likely just rebel and we’ll lose credibility.

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of Vittorio Bertocci
Sent: Thursday, March 12, 2020 11:28 AM
To: Aaron Parecki <[email-masked]>
Cc: OAuth WG <[email-masked]>
Subject: [EXTERNAL] Re: [OAUTH-WG] First Draft of OAuth 2.1

damnit, i hit enter too soon.
  Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint | rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the discussion for dPOP, hence I won't go in the details here.
Rotation isn't something that can be added without significant impact on development and runtime experiences:
·  on distributed scenarios, it introduces the need to serialize access to shared caches
·  network failures can lead to impact on experience- stranding clients which fail to receive RTn+1 during RTn redemption in a limbo where user interaction might become necessary, disrupting experience or functionality for scenarios where the user isn't available to respond.
- remediations currently in the wild for this are either clunky (grace periods) or downright cumbersome (waiting for the AT refreshed via RTn to be used by the client to invalidate RTn, which locks RS and AS in a transaction that is both expensive and itself subject to network failure)
I think it's fine to recommend using those mechanisms with a SHOULD, but imposing those complexities to everyone in the core is asking too much IMO.
Thanks
V.

On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci <[email-masked]<mailto:[email-masked]>> wrote:
Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint | rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the discussion for dPOP, hence I won't go in the details here..
Rotation isn't something that can be added without significant impact on development and runtime experiences:

  *   on distributed scenarios, it introduces the need to serialize access to shared caches
  *   network failures can lead to impact on experience- stranding clients which fail to receive RTn+1 during RTn redemption in a limbo where user interaction might become necessary, disrupting experience or functionality for scenarios where the user isn't available to respond.
  *

On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:
I'm happy to share that Dick and Torsten and I have published a first
draft of OAuth 2.1. We've taken the feedback from the discussions on
the list and incorporated that into the draft.

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

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 12 Mar 2020 19:57:59 +0100

Hi,

sender constraining refresh tokens for confidential client means client authentication + check the binding of the refresh token with the respective client id. I don’t think this is new as RFC6759 already required ASs to check this binding. Assuming backends are generally confidential clients also means no rotation and no cache synchronization needed.

Rotation should be used for frontends, e.g. native apps and only if there is there no other option. If a refresh fails, the app must go through the authorization process again. That’s inconvenient so the question is how often this happens. What I can say, I have never seen customer complaining in several years of operation of ASs with refresh token rotation (including replay detection) for native apps with millions of users.

best regards,
Torsten.

> Am 12.03.2020 um 19:24 schrieb Vittorio Bertocci <Vittorio=[email-masked]>:
> 
> 
> Hey guys,
> on distributed scenarios, it introduces the need to serialize access to shared caches
> network failures can lead to impact on experience- stranding clients which fail to receive RTn+1 during RTn redemption in a limbo where user interaction might become necessary, disrupting experience or functionality for scenarios where the user isn't available to respond.
> 
> 
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 12 Mar 2020 14:58:07 -0400

I also am in favor of not requiring "sender constraint" as a MUST. 
SHOULD or RECOMMENDED is fine. Many websites are NOT Single-Page-Apps 
and as such DPOP doesn't work for those environments. Converting all web 
based environments to SPAs so not viable.

Thanks,
George

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 12 Mar 2020 20:00:16 +0100

I think we need to change wording. Sender constraining for confidential client and refresh tokens does not require any signature. It’s client authentication + checking the client id matches. I don’t see an issue with this.

> Am 12.03.2020 um 19:36 schrieb Mike Jones <Michael.Jones=[email-masked]>:
> 
> 
> On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci <[email-masked]> wrote:
> Hey guys,

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 12 Mar 2020 12:04:40 -0700

Thanks for the clarification, Torsten.
I believe it's the first time I see use of client credentials positioned as
sender constraint; if the intent is saying that confidential clients should
use their credentials when redeeming refresh tokens, I am of course in
agreement but I think the language should be clearer and state the above
explicitly.

Re: failure frequency, I know of scenarios were the designers added
rotation by default, and after a while it was turned to opt in because of
the frequency of errors and impact on user experience/call center.
I really believe that putting this as a MUST is justified only for
exceedingly vulnerable situations, like SPAs.
Native/desktop clients should be free to decide whether they want to opt in
without loosing compliance. Just my 2 C

On Thu, Mar 12, 2020 at 11:58 AM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> Hi,
>
> sender constraining refresh tokens for confidential client means client
> authentication + check the binding of the refresh token with the respective
> client id. I don’t think this is new as RFC6759 already required ASs to
> check this binding. Assuming backends are generally confidential clients
> also means no rotation and no cache synchronization needed.
>
> Rotation should be used for frontends, e.g. native apps and only if there
> is there no other option. If a refresh fails, the app must go through the
> authorization process again. That’s inconvenient so the question is how
> often this happens. What I can say, I have never seen customer complaining
> in several years of operation of ASs with refresh token rotation (including
> replay detection) for native apps with millions of users.
>
> best regards,
> Torsten.
>

---

From: Pedro Igor Craveiro e Silva <[email-masked]>
Date: Thu, 12 Mar 2020 16:22:30 -0300

Hi Aaron,

In regards to `code_challenge_method` parameter in authorization requests.
Wouldn't make more sense to have the default value as `S256` based on the
statement in Section `4.1.1.2.  Client Creates the PKCE Code Challenge`
that says that `S256` is MTI on the server?

So you have `plain` as a special case for clients not able to support a
more strong code challenge?

Regards.
Pedro Igor

---

From: Pedro Igor Silva <[email-masked]>
Date: Thu, 12 Mar 2020 16:32:21 -0300

I agree with you and recently, we had to deal with an issue where a `web
application` using rotation (as defined by the draft) was having issues to
refresh tokens due to multiple concurrent requests at the moment a token is
about to expire or already expired. We had to add some controls to deal
with concurrency and additional complexity + performance penalties. And for
such clients, I was not sure whether or not rotation makes sense.

On Thu, Mar 12, 2020 at 4:05 PM Vittorio Bertocci <Vittorio=
[email-masked]> wrote:

> I believe it's the first time I see use of client credentials positioned
> as sender constraint; if the intent is saying that confidential clients
> should use their credentials when redeeming refresh tokens, I am of course
> in agreement but I think the language should be clearer and state the above
> explicitly.
>
> Native/desktop clients should be free to decide whether they want to opt
> in without loosing compliance. Just my 2 C
>
>> Am 12.03..2020 um 19:24 schrieb Vittorio Bertocci <Vittorio=
>> [email-masked]>:
>>
>> 
>> Hey guys,
>>    - on distributed scenarios, it introduces the need to serialize
>>    access to shared caches
>>    - network failures can lead to impact on experience- stranding
>>    clients which fail to receive RTn+1 during RTn redemption in a limbo where
>>    user interaction might become necessary, disrupting experience or
>>    functionality for scenarios where the user isn't available to respond.
>>    -
>>
>>
>>
>> On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki <aaron@parecki..com
>> <[email-masked]>> wrote:
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 12 Mar 2020 20:39:20 +0100

Is that a public client?

> Am 12.03.2020 um 20:32 schrieb Pedro Igor Silva <[email-masked]>:
> 
> 
> I agree with you and recently, we had to deal with an issue where a `web application` using rotation (as defined by the draft) was having issues to refresh tokens due to multiple concurrent requests at the moment a token is about to expire or already expired. We had to add some controls to deal with concurrency and additional complexity + performance penalties. And for such clients, I was not sure whether or not rotation makes sense.
> 
>> On Thu, Mar 12, 2020 at 4:05 PM Vittorio Bertocci <Vittorio=[email-masked]> wrote:
>> I believe it's the first time I see use of client credentials positioned as sender constraint; if the intent is saying that confidential clients should use their credentials when redeeming refresh tokens, I am of course in agreement but I think the language should be clearer and state the above explicitly.
>> 
>> Re: failure frequency, I know of scenarios were the designers added rotation by default, and after a while it was turned to opt in because of the frequency of errors and impact on user experience/call center.
>> I really believe that putting this as a MUST is justified only for exceedingly vulnerable situations, like SPAs.
>> Native/desktop clients should be free to decide whether they want to opt in without loosing compliance. Just my 2 C
>> 
>>> On Thu, Mar 12, 2020 at 11:58 AM Torsten Lodderstedt <torsten=[email-masked]> wrote:
>>> Hi,
>>> 
>>>>> Am 12.03..2020 um 19:24 schrieb Vittorio Bertocci <Vittorio=[email-masked]>:
>>>>> 
>>>> 
>>>> Hey guys,
>>>>> On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki <aaron@parecki..com> wrote:

---

From: Pedro Igor Silva <[email-masked]>
Date: Thu, 12 Mar 2020 16:47:46 -0300

A confidential client, as per the `web application` definition in Section
`2.1.  Client Types`.

On Thu, Mar 12, 2020 at 4:39 PM Torsten Lodderstedt <[email-masked]>
wrote:

>>> Rotation should be used for frontends, e.g. native apps and only if
>>> there is there no other option. If a refresh fails, the app must go through
>>> the authorization process again. That’s inconvenient so the question is how
>>> I am concerned with the real world impact of imposing sender
>>> constraint | rotation as a MUST on refresh tokens in every scenario.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 12 Mar 2020 21:57:11 +0100

Then why are you rotating refresh tokens? 

> Am 12.03.2020 um 20:48 schrieb Pedro Igor Silva <[email-masked]>:
> 
> 
> A confidential client, as per the `web application` definition in Section `2.1.  Client Types`.
> 
>> On Thu, Mar 12, 2020 at 4:39 PM Torsten Lodderstedt <[email-masked]> wrote:
>> Is that a public client?
>>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 12 Mar 2020 13:58:57 -0700

> In regards to `code_challenge_method` parameter in authorization requests. Wouldn't make more sense to have the default value as `S256` based on the statement in Section `4.1.1.2.  Client Creates the PKCE Code Challenge` that says that `S256` is MTI on the server?
> So you have `plain` as a special case for clients not able to support a more strong code challenge?

One of the goals of this draft was to consolidate the information
available in the related extensions and BCPs, not actually define
anything new itself. This behavior described would be different from
what is described in PKCE. If this is a good idea to change the
default, then that should be included in the Security BCP and brought
into 2.1 from there.

----
Aaron Parecki
aaronparecki.com
@aaronpk

On Thu, Mar 12, 2020 at 12:22 PM Pedro Igor Craveiro e Silva
<[email-masked]> wrote:
>
> Hi Aaron,
>
> In regards to `code_challenge_method` parameter in authorization requests. Wouldn't make more sense to have the default value as `S256` based on the statement in Section `4.1.1.2.  Client Creates the PKCE Code Challenge` that says that `S256` is MTI on the server?
>
> So you have `plain` as a special case for clients not able to support a more strong code challenge?
>
> Regards.
> Pedro Igor
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 12 Mar 2020 22:01:01 +0100

> Am 12.03.2020 um 21:59 schrieb Aaron Parecki <[email-masked]>:
> 
> 
>> 

The Security BCP recommends S256.

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 12 Mar 2020 14:03:18 -0700

> The Security BCP recommends S256.

Is a recommendation enough to change the default? That's definitely
normative changes from PKCE. I could be convinced either way, but it
would be the first place that 2.1 deviates from the combination of the
RFCs and BCPs.

----
Aaron Parecki
aaronparecki.com
@aaronpk

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Mar 2020 15:10:19 -0600

I agree that the language around sender constraining refresh tokens and
confidential client could/should be clearer.
I did try and discuss the idea that that such a refresh token is
constrained by virtue of being bound to the client and the client having to
authenticate to use it in
https://www.rfc-editor.org/rfc/rfc8705.html#section-7.1 maybe there are
some words that can be borrowed. Maybe.

With respect to failure frequency, we've had reports similar to what
Vittorio said and did change the default behaviour in product to not do
rotation unless specifically configured to do so per client.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Mar 2020 15:17:28 -0600

On Thu, Mar 12, 2020 at 3:03 PM Aaron Parecki <[email-masked]> wrote:

> Is a recommendation enough to change the default?

No.

How would that work in practice anyway? If no code_challenge_method was
present, then you'd need to know which version of OAuth is being used
(how?) in order to know which default code challenge method to use.

Please don't.

---

From: Pedro Igor Silva <[email-masked]>
Date: Thu, 12 Mar 2020 19:08:50 -0300

I don't but people using our AS. As I mentioned, rotation for such clients
does not make sense but we had to deal with it.

I just wanted to bring an example of how rotation can't be added without a
significant impact on development and runtime experiences (as mentioned by
Vittorio) if considered for every scenario.

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 12 Mar 2020 15:14:46 -0700

Rotation can be used to detect leakage, right? Client credentials offer
more guarantees, but unless you are using private JWTs with a non
exportable certificate as client cred, a classic client secret _could_
technically leak. Having rotation would alert you if someone got a hold on
those. Admittedly it’s a stretch, but not entirely inconceivable.

On Thu, Mar 12, 2020 at 13:57 Torsten Lodderstedt <torsten=
[email-masked]> wrote:

>> about to expire or already expired.. We had to add some controls to deal
>>>> [email-masked]..org <[email-masked]>>:
>>>>
>>>> 
>>>> Hey guys,

---

From: Dominick Baier <[email-masked]>
Date: Fri, 13 Mar 2020 01:47:00 -0700

Off the top of my head, rotation is useful for 2 things

* reducing the likelihood that an “old” refresh token is still valid (e.g.
“found” on some device, log file, source code etc...)
* being able to revoke all the active refresh tokens if a refresh token is
used twice

..and yes it introduces a higher chance of false positives.

https://leastprivilege.com/2020/01/21/hardening-refresh-tokens/

But I agree with the spec - if the refresh token cannot be bound to a
client by a secret (looking at you, SPAs) - it should be hardened using
sliding expiration, rotation and replay detection. Maybe the wording needs
to be clearer.

———
Dominick Baier

On 12. March 2020 at 23:15:19, Vittorio Bertocci (
vittorio=[email-masked]) wrote:

On Thu, Mar 12, 2020 at 13:57 Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> Am 12.03.2020 um 20:48 schrieb Pedro Igor Silva <psilva@redhat..com
> <[email-masked]>>:
>
> 
OAuth mailing list
[email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 13 Mar 2020 09:57:38 +0100

> On 12. Mar 2020, at 23:08, Pedro Igor Silva <[email-masked]> wrote:
> 
> I don't but people using our AS. As I mentioned, rotation for such clients does not make sense but we had to deal with it.
> 
> I just wanted to bring an example of how rotation can't be added without a significant impact on development and runtime experiences (as mentioned by Vittorio) if considered for every scenario.

Thank you for bringing this up. I will add a note that implementations should not use rotation in backend applications. client authentication+client_id binding is the better and easier mechanism. 

> 
> On Thu, Mar 12, 2020 at 5:57 PM Torsten Lodderstedt <[email-masked]> wrote:
>>>> 	• on distributed scenarios, it introduces the need to serialize access to shared caches
>>>> 	• network failures can lead to impact on experience- stranding clients which fail to receive RTn+1 during RTn redemption in a limbo where user interaction might become necessary, disrupting experience or functionality for scenarios where the user isn't available to respond.
>>>> 
>>>> 
>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 13 Mar 2020 10:00:42 +0100

> On 12. Mar 2020, at 23:14, Vittorio Bertocci <[email-masked]> wrote:
> 
> Rotation can be used to detect leakage, right? Client credentials offer more guarantees, but unless you are using private JWTs with a non exportable certificate as client cred, a classic client secret _could_ technically leak. Having rotation would alert you if someone got a hold on those. Admittedly it’s a stretch, but not entirely inconceivable.

I would rather recommend use of public key based client authentication methods instead of RT rotation. 

> 
> On Thu, Mar 12, 2020 at 13:57 Torsten Lodderstedt <torsten=[email-masked]> wrote:
>>> I agree with you and recently, we had to deal with an issue where a `web application` using rotation (as defined by the draft) was having issues to refresh tokens due to multiple concurrent requests at the moment a token is about to expire or already expired.. We had to add some controls to deal with concurrency and additional complexity + performance penalties. And for such clients, I was not sure whether or not rotation makes sense.
>>> 
>>>> Am 12.03..2020 um 19:24 schrieb Vittorio Bertocci <Vittorio=[email-masked]..org>:
>>>> 
>>>> 
>>>> Hey guys,

---

From: Neil Madden <[email-masked]>
Date: Fri, 13 Mar 2020 09:25:45 +0000

We have had several customers express interest in sliding expiration (idle timeouts) of refresh tokens and push back against rotation, particularly for mobile apps where they worry that the false positive rate with rotation can be too high to be practical due to flaky network connections. 

Neil

> On 13 Mar 2020, at 08:47, Dominick Baier <[email-masked]> wrote:
> 
> 
> * reducing the likelihood that an “old” refresh token is still valid (e.g. “found” on some device, log file, source code etc...)
> * being able to revoke all the active refresh tokens if a refresh token is used twice
> 
> But I agree with the spec - if the refresh token cannot be bound to a client by a secret (looking at you, SPAs) - it should be hardened using sliding expiration, rotation and replay detection. Maybe the wording needs to be clearer.
> 
> ———
> Dominick Baier
> 
>> On 12. March 2020 at 23:15:19, Vittorio Bertocci (vittorio=[email-masked]) wrote:
>> 
>>>>> Am 12.03.2020 um 20:48 schrieb Pedro Igor Silva <psilva@redhat..com>:
>>>>> 
>>>>