Out of curiosity: Have you seen this in practice? I’m asking since most/all
refresh token implementations I have seen are handles. Just rotating for
consistency makes especially the live of server based clients harder as they
need to propagate such a change through the cluster.
> Am 12.10.2020
An AS may decide refresh token rotation is useful for other reasons (such as if
the token is an encrypted value and the AS cluster does key rotation), or may
decide to rotate all tokens for consistency.
Eventually best practices may indicate sender constrained tokens for public
clients. At that
t; just extends the time in which the operation can occur, but every
>>>>> operation should be idempotent. All repeats of that operation within the
>>>>> grace period should have the same result, which means that every
>>>>> resulting RT is a represe
and that’s it.
>>>
>>> So, in your example I would consider RT1.1 and RT1.2 as equivalent, as
>>> they are both representatives of the RT_n+1 equivalence class.
>>>
>>>
>>>
>>> It would be very hard to do otherwise,
t would be very hard to do otherwise, given that network operations aren’t
> guaranteed to be concluded in the order they were executed without
> semaphores, and above all the network failures the grace period is designed
> to handle can apply to any of the requests, regardless of the ord
> they are both representatives of the RT_n+1 equivalence class.
>>
>>
>>
>> It would be very hard to do otherwise, given that network operations
>> aren’t guaranteed to be concluded in the order they were executed without
>> semaphores, and above all the network
In the past, customers brought to our attention that some clients were not
able to receive a new refresh_token and use it right away. For that use
case we added a different type of rotation. The new refresh_token was
exactly the same as the given one. Except that it had a new expiration
date, lifet
On Oct 6, 2020, at 16:05, Aaron Parecki wrote:
> However that also kind of defeats the purpose since attacks within that grace
> period would be hard to detect. I'm looking for an idea of where people have
> landed on that issue in practice.
This is effectively a race condition, and a grace per
> Am 07.10.2020 um 09:20 schrieb Neil Madden :
>
>
>
>>> On 6 Oct 2020, at 23:05, Aaron Parecki wrote:
>>>
>>
>> Hi all, I have a couple questions for those of you who have implemented
>> refresh token rotation...
>>
>> Have you included the option of a grace period on refresh token use
> On 6 Oct 2020, at 23:05, Aaron Parecki wrote:
>
>
> Hi all, I have a couple questions for those of you who have implemented
> refresh token rotation...
>
> Have you included the option of a grace period on refresh token use, allowing
> multiple uses within some time window? I'm wondering
alf Of *Aaron Parecki
> *Sent:* Tuesday, October 6, 2020 3:06 PM
> *To:* OAuth WG
> *Subject:* [OAUTH-WG] Implementation questions around refresh token
> rotation
>
>
>
> Hi all, I have a couple questions for those of you who have implemented
> refresh token rotation..
WG
Subject: [OAUTH-WG] Implementation questions around refresh token rotation
Hi all, I have a couple questions for those of you who have implemented refresh
token rotation...
Have you included the option of a grace period on refresh token use, allowing
multiple uses within some time
Hi all, I have a couple questions for those of you who have implemented
refresh token rotation...
Have you included the option of a grace period on refresh token use,
allowing multiple uses within some time window? I'm wondering because a
grace period where a refresh token may be used more than on
13 matches
Mail list logo
