Replies: 1 comment
|
I don't quite understand how your proposal would solve the problem you have described? If you don't know which button to click, how would an additional auth_method enum help? If your issue is not knowing what a login was used for I'd recommend saving a named entry with the correct email address for the site and you should get the information you need. E.g. if you have multiple Stackoverflow Accounts you could call one entry Stack Overflow (Work Account via Google SSO) and use the correct user mail address to know which account and which SSO provider to use. (I mean if you add additional accounts to a site how can the password manager know what the account is used for?) Also I would point out that Vaultwarden is only a server backend and not responsible for maintaining the Bitwarden clients or steering the direction they are developed towards. So your feature request is a bit out of scope for this project because it would have to be accepted and implemented by Bitwarden first. |
Uh oh!
There was an error while loading. Please reload this page.
The Problem
Currently, Vaultwarden treats all logins as username + password. For OAuth/SSO logins (WeChat, Google, Apple, GitHub, etc.), users have to:
Leave the password field empty
Use custom fields with inconsistent naming (e.g., auth_method, login_type, provider...)
Manually remember which identity was used (critical when you have two Google accounts and forget which one was bound to a site)
This leads to data drift — some entries have the field, some don't, and the naming is never consistent. After 6 months, you open a site and have no idea whether to click "WeChat" or "Google", or which email to use.
Proposed Solution: First-Class auth_method Field
Add a native auth_method enum to the Login cipher type, making it a structured, validated field instead of a free-text custom field.
All reactions