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
> Am 12.10.2020 um 09:04 schrieb Dave Tonge :
>
>
> Hi Neil
>
> > refresh token rotation is better thought of as providing protection
> against insecure token storage on the client
>
> I agree with your reasoning - and that was more the intent of what I said.
> We've seen refresh token ro
Hi Neil
> refresh token rotation is better thought of as providing protection
against insecure token storage on the client
I agree with your reasoning - and that was more the intent of what I said.
We've seen refresh token rotation used for confidential clients that have
secure storage (i.e. are
I’m not sure I agree with this advice. Singling out private_key_jwt and
tls_client_auth suggests that the problem is an attacker being able to
eavesdrop on the refresh request itself and then replay it. But if they are
able to do that then they can instead just steal the access tokens from the
> Our goal is to prevent cases where we lose the ability to Refresh a Token
due to transient issues (which have run the gamut from network problems to
bad software updates on the AS side).
We've seen this issue quite a bit and it's very frustrating. I would
suggest that refresh token rotation is n
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
My experience is more from the Client side of the equation on this problem,
but I do have some thoughts. Our goal is to prevent cases where we lose the
ability to Refresh a Token due to transient issues (which have run the
gamut from network problems to bad software updates on the AS side). Our
use
Hey Aaron,
Auth0 does offer a configurable grace period, during which the “preceding”
token can be reused.
I am not 100% sure what we do in the exact scenario you described, and I will
double check for you, but here’s my intuition.
The operation redeem(RT_n) should result in AT, RT_n+1. Th
12 matches
Mail list logo
