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 without a grace period the first request would have invalidated the old RT leaving the client with no option but to perform a full authorization flow again to get a new one.
I’m generally against allowing a grace period at all, but given that it’s a common request and some implementations are already allowing this, I’m hoping we can find some wording we can all agree on. I agree that a grace period is more acceptable if the RT is sender-constrained by something like DPoP, but then in that case does RT rotation add anything anyway? The current BCP lists these two as either/or rather than defence in depth. — Neil > On 2 Nov 2021, at 14:09, Pieter Kasselman <[email protected]> > wrote: > > > 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 expiry time by a set time > (60 seconds in your example) and having the client present the token a little > earlier. > > If grace periods are allowed, it may be worth considering adding additional > mitigations against replay. For example, a grace period may be allowed if the > refresh token is sender constrained with DPoP so there is at least some > assurances that the request is originating from the sender (especially if the > nonce option is used with DPoP). > > I would worry about adding more complexity and less predictability by adding > grace periods though (e.g. by looking at a refresh token, will you be able to > tell if it can still be used or not), but your point that implementors may > solve for it in other less predictable ways raises a valid point. > > Cheers > > Pieter > > From: OAuth <[email protected]> On Behalf Of Neil Madden > Sent: Tuesday 2 November 2021 10:29 > To: oauth <[email protected]> > Subject: [EXTERNAL] [OAUTH-WG] Rotating RTs and grace periods > > 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 period. We > (ForgeRock) currently do not, but we do periodically receive requests to > support this. The current security BCP draft is silent on whether > implementing such a grace period is a good idea, but I think we should add > some guidance here one way or another. > > My own opinion is that a grace period is not a good idea, and if it is to be > supported as an option then it should be kept as short as possible. The > reason (as I mentioned in the previous thread) is that it is quite easy for > an attacker to observe when a legitimate client performs a refresh flow and > so can easily sneak in their own request afterwards within the grace period. > There are several reasons why it is easy for an attacker to observe this: > > - RT rotation is primarily intended for public clients, such as mobile apps > and SPAs. These clients are geographically distributed across the internet, > and so there is a good chance that the attacker is able to observe the > network traffic of at least some of these client instances. > - The refresh flow is typically the only request that the client makes > directly to the AS after initial authorization, so despite the traffic being > encrypted it is very easy for an observer to determine that the client is > performing a refresh whenever it makes any connection to the AS. > - As well as observing the request itself, an attacker may be able to observe > the DNS lookup for the AS hostname instead, which is even more likely to be > observable and also in plaintext most of the time. > - An attacker in a position to steal RTs from e.g. localStorage, is probably > also in a good position to either observe when the legitimate client > refreshes or to actually force it to refresh early (e.g., by deleting the > corresponding AT from the same storage). > > I know some people argue that a grace period is a reasonable trade-off > between security and usability. But I think that this kind of attack would be > quite easy to carry out in practice for the reasons I suggest above, so I > think the security actually degrades extremely quickly if you allow a grace > period of any reasonable length. > > On the other hand, if we discourage this entirely then people may use dubious > workarounds instead (e.g., one proposal I’ve seen was to use an ID token with > the JWT Bearer grant, effectively turning the ID Token into an ad-hoc RT with > much fewer protections). > > As a strawman, what would people think of wording like the following: > > --- > The AS MAY allow the original RT to be replayed for a short grace period to > allow the client to recover if the response is not received due to a network > problem or other transient issue. However, implementors should be aware that > an attacker may be able to easily observe when the legitimate client makes a > refresh request to the AS and so time their use of a stolen RT to occur > within the grace period. Any grace period MUST be kept as short as possible, > and MUST NOT exceed 60 seconds. Clients should prefer sender-constrained > refresh tokens if recovery from network issues is a priority. > — > > (The 60 seconds limit here is based on Auth0’s grace period). > > [1]: https://mailarchive.ietf.org/arch/msg/oauth/WXwKxQM2poW7bqOOGGp4POYolFk/ > > Kind regards, > > Neil
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
