Allows users to log in with client_id&client_secret pair that can be obtained from Bitwarden.
Apikey based login does not return refresh_token as part of the response, instead it's required to just reauthenticate with the credentials (same approach as in the official CLI).
What was changed:
New refresh_token type was added to differentiate between the refresh flows required. SSO and email+password return the refresh_key, apikey stores the client_id&client_secret pair instead.
This means that these credentials are stored on disk in plaintext, in the rbw's DB file.
It's consistent with how it's done in Bitwarden's official CLI, they do it the same way
New client_id field was added to config
client_secret is read via pinentry
Added some docs
I also cleaned up a bit in src/api.rs, the apikey request is sent in three different places now, it looked bad without these changes:
Separated the common "login request" parameters into a separate struct, to not duplicate the values all over the src/api.rs
device_id and email are needed for the relogin with apikey (to run it exactly the same way as the initial login), I've initially kept these alongside client_id and client_secret in the DB, but eventually changed to reading them from config. Thus adding device_id function non-async variant.
Tested (login + token refresh) the changes with all three flows we'd have now.
This topic started as part of https://github.com/doy/rbw/issues/182
According to it, apikey strategy seems to be less fragile than the password based one, so maybe it'd be helpful for debugging issues in the future
Allows users to log in with
client_id&client_secretpair that can be obtained from Bitwarden. Apikey based login does not returnrefresh_tokenas part of the response, instead it's required to just reauthenticate with the credentials (same approach as in the official CLI).What was changed:
refresh_tokentype was added to differentiate between the refresh flows required. SSO and email+password return therefresh_key, apikey stores theclient_id&client_secretpair instead. This means that these credentials are stored on disk in plaintext, in therbw's DB file. It's consistent with how it's done in Bitwarden's official CLI, they do it the same wayclient_idfield was added to configclient_secretis read via pinentryI also cleaned up a bit in
src/api.rs, the apikey request is sent in three different places now, it looked bad without these changes:src/api.rsdevice_idandemailare needed for the relogin with apikey (to run it exactly the same way as the initial login), I've initially kept these alongsideclient_idandclient_secretin the DB, but eventually changed to reading them from config. Thus addingdevice_idfunction non-async variant.Tested (login + token refresh) the changes with all three flows we'd have now.
This topic started as part of https://github.com/doy/rbw/issues/182 According to it, apikey strategy seems to be less fragile than the password based one, so maybe it'd be helpful for debugging issues in the future
CC @pfr-dev