Support authentication via Auth Token (alternative to username/password)

[lukaslisowski]

Description:
Currently, the integration only supports authentication using username and password.

Expected Behavior:

• It should be possible to provide an Auth Token as an alternative to username/password in the configuration flow.
• Validation must ensure that either an Auth Token or username/password is provided.
• The Auth Token should be passed to the API client and used for all requests.
• The configuration and reconfiguration flows should also support the Auth Token field.

Motivation:
Supporting Auth Token authentication will make the integration more future-proof and accessible.

[RustyDust]

Motivation: Supporting Auth Token authentication will make the integration more future-proof and accessible.

Unfortunately, right now that's not the case.

Accessibility: To enable the API v2 access and using a token, you have to first log in to the web interface of the Sonnenbatterie and actively enable the API v2 read and write access as well as generate an API token itself.
So while it is quite certain that the user has access to the credentials to log in to the web interface, it is not guaranteed that the owner of the Sonnenbatterie visited the web interface and activated the API access and token. In addition, some API v1 endpoints used in the integration have no counterpart in the v2 API, so right now you'd lose functionality.

Future-proof-ness: From a technical point of view, there is no difference between using the username/password credentials and the Auth Token. The simple reason far that is that once you log in using your username and password, the Sonnenbatterie will issue a session token to you. The only difference between that and the APIv2 Auth Token is that the session token has an inactivity timeout (roughly two minutes). For everything else, it works just like the Auth Token and is already used by the integration internally. So since there's no functional difference between the session token and the Auth Token, at least for the moment there's no added benefit when using the latter. Actually, right now it's exactly the other way around: some API endpoints that can be used to query additional settings and data points of the Sonnenbatterie aren't accessible when using the Auth Token, those can only be used when authenticated using the username/password credentials.
If you take a closer look at the underlying Python library sonnenbatterie you'll notice, that it is already split in an APIv1 and an APIv2 part, with the APIv1 system already using APIv2 calls where appropriate/possible.

So:

It should be possible to provide an Auth Token as an alternative to username/password in the configuration flow.

As stated above, using the Auth Token alone would result in reduced functionality whereas using the username/password combination also gives the same access to the APIv2 (if enabled by the user - well, actually, the integration even could do that for you but I decided against it because I don't want to tinker with the user's equipment without them knowing).

Validation must ensure that either an Auth Token or username/password is provided.

Why go through the hassle if we don't need to? 😉

The Auth Token should be passed to the API client and used for all requests.

It already is - where possible/necessary. Just not the Auth Token you suggested to use.

The configuration and reconfiguration flows should also support the Auth Token field.

Why go through the hassle if we don't need to? 😉

Of course, if in a future firmware Sonnen changes the functionality of the APIv2 in a way that would prevent the integration from using some endpoints when authenticated using username and password only, that would be a reason to also support the Auth Token. But right now, there isn't a really good reason to do so.

[svendebont]

This more as a security issue and a validation of the 'least privilege' principle.

Given that integration configuration values are stored in clear text on home assistant, any use of a username/password configuration should be avoided whenever possible.
Anyone who manages to obtain the username/password will be able to do far more than what is possible with an API Key, including enabling the write api, changing network settings, adding a webhook, changing the password of the user and locking the user out of the system, ... I see no need for any integration to have need for those privileges.

Using the API token allows me as a user to control the level of access given to the integration (read-only or read/write).
By using username and password, the integration will always have read/write access and any user of my home assistant instance can (accidentally) change the settings of my battery.

Also any bug (or malicious code) in the integration could lead to unwanted configuration changes or even getting locked out of the device.

I don't know what functionalities would be reduced by only using the API keys, but I'm pretty sure none of them justify the added security risks of using username/password (which, again, are stored in clear text).

[RustyDust]

This more as a security issue and a validation of the 'least privilege' principle.

This is open source so you're welcome to send a PR.