Session timeouts despite SSO_AUTH_ONLY_NOT_SESSION

[tribut]

Hey, I've been running the current version of your sso-support branch for a few weeks now on a test installation. I have set SSO_AUTH_ONLY_NOT_SESSION: "true" because my IdP does not return a refresh_token.

But while the last version of the PR I had touched never logged anyone out, I am seeing frequent logouts after a few days of no contact with the server now.

SSO.md claims the generated refresh tokens are valid for a year, yet the generated tokens actually seem to be valid for only 7 days.

This appears to be a regression or am I holding it wrong? The non-sso vaultwarden does not return a JWT as refresh token but simply some opaque data as far as I can tell and the client has never logged me out for not having contacted the server a few days.

[Timshel]

Hey,

The doc is out of date, the refresh token was lowered to a 7 days idle timer (The one year was judged as too long, cf this discussion).

With activity, it can be extended indefinitely. But issue might be that not all activity trigger a call to refresh the tokens.

[tribut]

Ah yes, I remember reading that disussion. I believe it is a misunderstanding and the current behavior does not match the non-SSO experience.

According to this bitwarden article "Offline Vault sessions will expire after 30 days. Except for mobile client applications, which will expire after 90 days.".

What happens with the SSO patch right now is when the refresh_token expires, the client will automatically log out. This leads to the unfortunate consequence that a user who has stored their SSO password in the vault (but knows their master password) now has to somehow recover their SSO password before being able to unlock the vault again. This regularly happens over a period of just a few days.

I suggest raising this to 90 days with a reference to that article. Unfortunately I couldn't find the code in the client that deals with the case of the refresh_token not being decodable as a JWT quickly. Hopefully I'll find time in the next days to look into it.

[Timshel]

The current Vaultwarden non-SSO experience use a secret linked to the device and never expire.

I isolated the addition of the JWT Refresh Token in a separate PR. Will mention the suggestion of raising the expiration to 30 days.

[rizlas]

Notice same behaviour too

[Timshel]

I had some feedback from Blackdex in the other PR, I made the switch to 30 days in it and in sso-support.

So it will be in the next release, might wait a bit since I already had integrated the latest webvault change, so I might wait for the next Vaultwarden release.

[Timshel]

Hey forgot to mention it on the changelog but it was released with 1.30.5-8.

[rizlas]

So the behavior is now the following: "Offline Vault sessions will expire after 30 days. Except for mobile client applications, which will expire after 90 days." ?

[Timshel]

No 30 days (which can be extended) for all.

[rizlas]

How it can be extended?

[Timshel]

Each call to the refresh endpoint will generate a refresh token valid for the next 30 days.
Different actions trigger this such as a synchronize in the extension I believe or some navigation in the web app when the access token is expired.