feature request: Clarify SPA refresh token TTL behavior on rotation (revisit #4520)

[SongRongLee]

What problem did you meet?

We just got bitten by an unexpected forced sign-out 14 days after a user's initial sign-in on our SPA, even though tokens had been rotating fine the whole time.

After digging into defaults.ts, it turns out that for SPAs the rotated RT just inherits the old token's remainingTTL no
matter how often you rotate. The code comment is pretty direct about this: "Non-Sender Constrained SPA RefreshTokens do not have infinite expiration through rotation".

Totally reasonable as a security stance — but the docs threw us off a bit. This section says:

TTL refreshment is unavailable in SPA... To enhance the user experience, you can enable the "Rotate refresh token" feature...

We read that as "rotation extends TTL and lets users stay signed in longer", and it seems we're not alone (see #4520 and the recent bump). But for SPAs, rotation doesn't seem to do anything for the grant lifetime — it looks more like a pure security feature (reuse detection).

If we're reading this right, wouldn't that also mean users can get kicked out mid-task when the cap fires, since AT TTL is only 1 hour and the cap is at a fixed wall-clock moment?

Describe what you'd like Logto to have

Either of these would help:

1. Tweak the docs — say plainly that "Rotate refresh token" doesn't extend TTL for SPAs. Drop the "to enhance user experience" phrasing, or rewrite it to describe what rotation actually buys for SPAs (security against stolen RTs via reuse detection), so devs don't keep walking into this.

2. Bring back the toggle from #4520 — an opt-in "Renew refresh token TTL on rotation" per app, off by default, with a sane hard cap (1 year would match native / traditional web). Low-risk apps could trade a bit of security for much better UX.

[leoshusar]

Even for SPAs, in my opinion, short TTL with refreshment would be more secure than hard setting the TTL to 180 days, which I currently need to do. Personally I'd like the toggle.

[charIeszhao]

Thanks guys for bringing this up. I think it's a legit feature request. Looking back from today, I think it's not a bad idea to offer the "toggle" feature and allow it if the user understands what they are doing.

So at this point, I think we might need to do both. Will have a short discussion internally and update you once we make the decision on it.

[charIeszhao]

If we're reading this right, wouldn't that also mean users can get kicked out mid-task when the cap fires, since AT TTL is only 1 hour and the cap is at a fixed wall-clock moment?

You're right about the point that "the AT TTL is only 1 hour and the cap is at a fixed wall-clock moment". IMOH, this is inevitable even if we extend the refresh token and grant TTLs to 180 days or even up to 1 year. However, I do understand that extending the TTL to longer days would greatly reduce the chance of users hitting the wall, but you just never escape it from the extreme cases.

[SongRongLee]

Thanks for taking this seriously and for the quick reply!

One more thing that surfaced from your response — when you mentioned extending the RT / grant TTL up to 1 year, I went back to the Rotate refresh token docs section and noticed the wording there might be off. The docs list "rotated for one year" as a trigger for issuing a new RT:

When enabled, Logto will issue a new refresh token for token requests under the following conditions:

• If the refresh token has been rotated... for one year; OR
  ...

But reading defaults.ts, the code looks like the opposite — totalLifetime ≥ 1 year makes the function return false, i.e. it actually looks more like a hard cap that stops rotation.

If I'm reading this right, wouldn't that mean even traditional apps still hit a mid-task sign-out around the 1-year mark? At that frequency it barely affects UX in practice, of course — and honestly if SPA could align with that same "1-year hard cap from initial sign-in" behavior via the toggle, the trade-off would feel pretty acceptable to most teams I think.

[charIeszhao]

Guys, we've just submit a new PR to clarify things up in our docs:
logto-io/docs#1407

Also, a new feature project has been posted on our public roadmap, to allow admin to customize "Grant TTL" in application settings. You can vote for it and we'll prioritize our work based on user votes.
https://logto.productlane.com/roadmap?id=7cf42d18-e7c4-488a-a2a1-d41c8c5a4375

[charIeszhao]

Thanks for taking this seriously and for the quick reply!

One more thing that surfaced from your response — when you mentioned extending the RT / grant TTL up to 1 year, I went back to the Rotate refresh token docs section and noticed the wording there might be off. The docs list "rotated for one year" as a trigger for issuing a new RT:

When enabled, Logto will issue a new refresh token for token requests under the following conditions:

• If the refresh token has been rotated... for one year; OR
  ...

But reading defaults.ts, the code looks like the opposite — totalLifetime ≥ 1 year makes the function return false, i.e. it actually looks more like a hard cap that stops rotation.

If I'm reading this right, wouldn't that mean even traditional apps still hit a mid-task sign-out around the 1-year mark? At that frequency it barely affects UX in practice, of course — and honestly if SPA could align with that same "1-year hard cap from initial sign-in" behavior via the toggle, the trade-off would feel pretty acceptable to most teams I think.

Thanks for the careful read. You’re right that the current wording is misleading.

The “rotated for one year” condition is not meant to be a trigger that issues a new refresh token after one year. It is the opposite boundary: refresh token rotation is allowed only before the refresh token chain reaches that lifetime; after that, rotation stops and the current token’s expiration is final.

There is also one Logto-specific detail worth clarifying: refresh tokens are tied to app grants, and the current default grant TTL is 180 days. So in practice, refresh-token-backed authorization is capped by the earliest of grant expiration, refresh token expiration, session binding, or explicit revocation.

For SPAs, your original understanding is also correct: rotation issues a new refresh token, but it does not extend the refresh token TTL. The new token inherits the remaining TTL of the previous token.

For traditional web apps, once we complete the implementation of the customizable grant TTL feature, you can configure the grant TTL to indefinite in order not to hit the "mid-task sign-out" wall.

We’ll update the docs to make these boundaries explicit and avoid implying that rotation can extend SPA refresh token lifetime or bypass grant expiration.