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 from 0 to 60 seconds. Personally I also agree with Neil that a grace period is not a good idea from the security aspect, but I do also see that we have a lot of customers who ask for this feature due to things like flaky mobile networks. I like the suggested text from Neil. I assume this would go into the Security BCP as well as OAuth 2.1? Aaron On Tue, Nov 2, 2021 at 7:09 AM Pieter Kasselman <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/ > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FWXwKxQM2poW7bqOOGGp4POYolFk%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cbdb0969234774ba6f87608d99deba06c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637714457664531224%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CDskCHwXxJxGdmudTW33gUT5f3%2B835uZDxyNEmKkiFc%3D&reserved=0> > > > > > Kind regards, > > > > Neil > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
