My perspective is that the rotation of refresh tokens is an AS mechanism to
push for one-time-usage and break idempotency. This is specifically employed to
reduce the impact in scenarios where the refresh token can be leaked and used
by a third party attacker. A leaked refresh token can only be
The grace period is not about the refresh token lifetime, it's specifically
about whether what would be a single-use refresh token can be used more
than one time within a short window of the first use.
Okta supports a configurable grace period per application that the customer
can set, anywhere
All,
The following link has links to the *Token Chaining* slides and drafts to
be discussed tomorrow:
https://notes.ietf.org/notes-ietf-interim-2021-oauth-15-oauth
Regards,
Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
The grace period is to allow the client to retry if it fails to receive the new
RT for any reason. For example, the client performs a successful refresh flow
but loses mobile network signal before receiving the response. The grace period
allows the client to simply retry the request, whereas
Neil
Is the goal to accommodate network latency or clock drift? It would be helpful
to include reasons for why a grace period should be considered if it is allowed.
Without knowing the reasons for the grace period it is not clear why a grace
period is a better solution than just extending the
Hi all,
There was a previous discussion on whether to allow a grace period during
refresh token rotation, allowing the client to retry a refresh if the response
fails to be received due to some transient network issue/timeout [1]. Vittorio
mentioned that Auth0 already implement such a grace
