JWT Refresh Token

[Timshel]

To facilitate review decided to move out the switch to a JWT refresh_token from the sso PR #3899.

Without the SSO logic it's not the most useful still :

• Add an expiration on the refresh_token (work like an idle timer reset when a new access_token is generated).
• Store the information of the AuthMethod in the token (Password ...).

[Timshel]

When discussed with @BlackDex we thought that 7 days might be an appropriate value for the refresh_token expiration.

Had some feedback on it, and it might be a bit short, since many actions in the application will not trigger a refresh (reading password is done as "offline"`).

Might make sense to raise it to something around 30 days as mentioned in this documentation.

[BlackDex]

I agree, lets keep it the same as Bitwarden, and 7 days is a bit short indeed.
Also, how is this linked to the refresh roll PR? Could that potentially break offline logins too?

[Timshel]

Also, how is this linked to the refresh roll PR?

This is a superset of the refresh roll PR, the same logic of changing the device token is used to prevent reusing twice the same refresh_token.

Could that potentially break offline logins too?

I'm unsure what are the offline logins ?

[BlackDex]

Also, how is this linked to the refresh roll PR?

This is a superset of the refresh roll PR, the same logic of changing the device token is used to prevent reusing twice the same refresh_token.

Could that potentially break offline logins too?

I'm unsure what are the offline logins ?

I mean offline unlock in some way. But i doubt it.

[Timshel]

A yes when unlocking I don't believe any call is done to the refresh endpoint, so there should be no issue/change.

[Timshel]

Removed the rolling of the device token since it caused issues when the web client called the refresh token endpoint in parallel.