BW Client silently continues with expired auth (SSO)

[Gabgobie]

Hi,

since I started using the Bitwarden desktop and mobile apps, I noticed an issue where I will remain logged in and can unlock my vault with the master password but synchronization/saving will always fail. This is only fixed by manually logging out and back in but after a small period of inactivity, the issue will come back. It is my assumption is that the authentication expires but the Bitwarden client for some reason doesn't act on it.

As a user of Kanidm, I don't yet have access to the offline_access scope. kanidm/kanidm#4034

The Wiki currently documents Kanidm as necessitating no special configuration.

Looking at the docs for other OIDC providers and skimming #6311 leads me to believe that I should set SSO_AUTH_ONLY_NOT_SESSION to true. (Let's see if that fixes my issues; ping me so I remember to report back)

Since the Kanidm devs generally like to keep a tight grip on session lifecycle and token validity, I'll cross post over there as my understanding of this setting is that it reduces the SSO provider to the initial authentication step whereas later authentication is handled between VW and the client without involvement of the IDM.

In the mean time I'd suggest adjusting the Kanidm wiki section to include SSO_AUTH_ONLY_NOT_SESSION: true.

Best,
Gab

[Firstyear]

Per https://www.rfc-editor.org/rfc/rfc6749#section-4.1.4

The access_token response provides an expires_in time. The OAuth2 client then needs to either use the refresh token (which issues a new access_token, with a new expiry), or the refresh fails and the token is no longer valid.

So if you are seeing that vaultwarden sessions are "detached" from the access_token expiry, I think it becomes a vault warden bug, not a Kanidm one. The session in vaultwarden should be limited by both the access_token expiry, but also the refresh token validity and if it can refresh.

The offline_access scope is needed for something else - offline_access specifically in Kanidm is related to how sessions work. That when you login you get a user-auth-token (UAT) and that UAT is the parent session of all OAuth2 sessions you initiate. When your UAT expires, so do all OAuth2 tokens (access and refresh).

offline_access detaches these concepts, where the UAT that issues that OAuth2 session does not bound the lifetime of the OAuth2 session in question. For the vaultwarden case, it's likely you actually want the session to be bound, since then single logout is possible by logging out in Kanidm which causes the access-tokens in vaultwarden to become invalid at that moment.

[Gabgobie]

Thanks for joining in the discussion.

So if you are seeing that vaultwarden sessions are "detached" from the access_token expiry, I think it becomes a vault warden bug, not a Kanidm one. The session in vaultwarden should be limited by both the access_token expiry, but also the refresh token validity and if it can refresh.

It is either that the response of the Vaultwarden server for expired authentication tokens doesn't match the Bitwarden client's expectations or the more likely case that the Bitwarden client doesn't correctly handle the expiry. In either case, the Vaultwarden project explicitly asks for all issues to be reported here and to not directly to Bitwarden.

The detachment of session validity comes from the SSO_AUTH_ONLY_NOT_SESSION: true setting that takes away session control from the OAuth2 server but seems to be necessary for correct operation without the offline_access scope.

For the vaultwarden case, it's likely you actually want the session to be bound, since then single logout is possible by logging out in Kanidm which causes the access-tokens in vaultwarden to become invalid at that moment.

For web, yes but I usually solve that by setting up my browser to delete all cookies and session data when closing the last window. I unfortunately don't think a distinction in scopes can be made depending on login for web or login for desktop apps.

For my desktop and mobile applications not really. My understanding of your comment on kanidm/kanidm#4034 is that these UAT sessions would be displayed to the user in the Kani UI and could be terminated there or by an admin for example when the necessary group membership for this service is revoked.

[Firstyear]

For the vaultwarden case, it's likely you actually want the session to be bound, since then single logout is possible by logging out in Kanidm which causes the access-tokens in vaultwarden to become invalid at that moment.

For web, yes but I usually solve that by setting up my browser to delete all cookies and session data when closing the last window. I unfortunately don't think a distinction in scopes can be made depending on login for web or login for desktop apps.

For my desktop and mobile applications not really. My understanding of your comment on kanidm/kanidm#4034 is that these UAT sessions would be displayed to the user in the Kani UI and could be terminated there or by an admin for example when the necessary group membership for this service is revoked.

Yes exactly.

But either way the issue here is I think in the initial report - the issue is not offline_access scope support in Kanidm or anything related to how we handle session lifetime inheritance, but that something in either vaultwarden or bitwarden aren't setting their session times to be bounded to the access token lifetime, and that the refresh token may or may not be being used correctly to revalidate the session of the user.

From the sound of the report it's quite likely the bitwarden extension given the symptoms described.

[Gabgobie]

I think this is developing into another instance of us aggressively agreeing although I maintain that support for the offline_access scope would be an applicable solution.

The central issue is the incorrect handling of the access/refresh token lifetime but the symptoms can be cured through the offline_access scope. Without this scope, I will have to enable the arguably undesirable band aid setting SSO_AUTH_ONLY_NOT_SESSION that takes authority over session validity away from Kani.

A proper solution would require someone more familiar with Vault-/Bitwarden to determine if the issue is here or upstream and fix the issue there. Still, that would only fix the UX issue of not prompting for re-authentication. Long-lived sessions would still be desirable and the band aid setting still required.

[Firstyear]

I think this is developing into another instance of us aggressively agreeing although I maintain that support for the offline_access scope would be an applicable solution.

Yeah it would, but then you still would have an issue that if the oauth2 session was canceled on the Kanidm side, it would still cause some issue on the bw/vw side, so handling the revoke nicely is probably the best outcome.

The central issue is the incorrect handling of the access/refresh token lifetime but the symptoms can be cured through the offline_access scope. Without this scope, I will have to enable the arguably undesirable band aid setting SSO_AUTH_ONLY_NOT_SESSION that takes authority over session validity away from Kani.

Again, not really, because even offline_access tokens can be revoked. So this would still come up :)

A proper solution would require someone more familiar with Vault-/Bitwarden to determine if the issue is here or upstream and fix the issue there. Still, that would only fix the UX issue of not prompting for re-authentication. Long-lived sessions would still be desirable and the band aid setting still required.