Indefinite Refresh Tokens

[Sephster]

In its current state I believe the library enforces the use of expiry times for Refresh Tokens. This is good practice but mandatory expiry times are not specified in the OAuth2 spec.

We should evaluate this current stance and see if we want to support indefinite refresh tokens in a future release. Please see issue #944 for the original discussion that led to the raising of this issue.

[mtangoo]

I have seen many application use 0 as indefinite time. I would like to table this too for this specific use case. Set time t for specific expiry or 0 for non expiring

[sg3s]

Not in favor, setting a far future expires date is effectively just as good and makes you think about what you're actually doing.

What would be good is somehow being able to set an expiration time for refresh tokens (or access tokens really) per client. So you can control / write logic to determine which clients are actually allowed to receive long lifetime tokens and which are not, instead of always using the defaults configured on the server/grant.

[christiaangoossens]

Within the scope of this project: providing a out-of-the-box safe oauth2 library, I would strongly oppose allowing indefinite refresh tokens by default. If this is a feature that is really wanted, I would only consider it by setting an explicit flag (which is also not used in any examples, only stated in documentation). This way nobody will use indefinite refresh tokens without considering the implications (especially as you can also choose to not implement checking the jti claim).

[mtangoo]

@LuckyBaBa2022 what about setting expiry date of 100years ahead? ;)

[Starfox64]

@Sephster #1347 was closed in favor of this issue but I don't think this is related.