Clarification on refresh token requirements for browser-based clients #105
Description
I'm trying to determine whether indefinite session lifetimes are ever permitted for browser-based OAuth 2.0 clients, in each case of a. rotation or b. sender-constrained tokens. My impression is that this may be against the spirit of these requirements, particularly given the example described within the section. If indefinite session lifetimes are permitted but recommended against for browser-based clients, that would also be useful to have clarified. Since RFC 9700 doesn't weigh in on these topics for browser-based clients, it may be valuable to have it laid out plainly here.
Section 6.3.2.3 gives the following requirements for authorization servers regarding refresh tokens in this setting:
MUST either rotate refresh tokens on each use OR use sender-constrained refresh tokens as described in Section 4.14.2 of [RFC9700]
MUST either set a maximum lifetime on refresh tokens OR expire if the refresh token has not been used within some amount of time
upon issuing a rotated refresh token, MUST NOT extend the lifetime of the new refresh token beyond the lifetime of the initial refresh token if the refresh token has a preestablished expiration time
In the second requirement there are two kinds of expirations described: an absolute timeout ("maximum lifetime") and an idle timeout ("not ... used within some amount of time").
In the third requirement it indicates that rotated tokens cannot have a longer lifetime than the initial refresh token. Since refresh tokens are single-use under token rotation, we can only talk about the time between issuance and its first/only usage—so any differences between expiration based on an absolute timeout vs. an idle timeout of a token become a bit subtle. In particular, either might be read as "a preestablished expiration time." So it feels a bit open-ended whether indefinite session lifetimes are allowed when only using refresh token rotation.
When using sender-constrained refresh tokens, it appears the draft would permit you to use a refresh token that enforces only an idle timeout in order to achieve indefinite session lifetimes—this feels a little plainer to interpret with the current language.