Security of my HA instance is my number 1 priority, so I am not comfortable with too many tokens in my config. Every now and then I delete tokens. But it would be great if I could name each token so I know which login it represents.
Yah this is pretty standard, good wth!
2 Likes
Great suggestion! I’ve had several times I’ve been testing something new, only to back out and leave a token behind (which is admittedly my mistake)…would be so great to (re)name them at will.
Do you mean the refresh tokens or the long-lived access tokens?
You can give the long-live access tokens names when you create them, but it would be nice to be able to change this, if you thought a different name would be more obvious.
I definitely agree that the refresh tokens are a mess, with no obvious way to identify which one is for which device (particularly if you use the Nabu Casa remote access when the last used IP address will always show as 127.0.0.1).
Being able to give those names would be good, but you would still need to identify them to give them names. It would be better if the information shown made this easier (by showing the user agent, etc.)
Not sure if you were replying to me or the OP, but just in case: I was a little muddled about the two token types. It would definitely be good to have some naming control over the refresh tokens (as well as browser UA if available, and other related info for them.
And it would be nice also to be able to rename both (I forgot Long Lived tokens do get names initially, since I only have one and its been…long lived 
Agree - i’d also like to move them to a folder called tokens (or put them in .storage)
these are immensely important files and they are dropped into the root of the /config dir when they shouldn’t really be accessible.
Can we implement a standard?
All the tokens are in the auth file under .storage for me, there are no tokens in the root of the config directory. Are you thinking of something else, like secrets.yaml (that’s a YAML configuration file so belongs in config) or maybe custom integrations which do this?
There are a bunch (maybe custom components) that leave token files in the root. When I’m at my PC I’ll add the list
If it’s custom components, it’s up to the dev of the custom component to store the token in the correct location.
Correct. With the sole exception of secrets.yaml, no secret information (passwords/auth-tokens, private keys, etc) should be stored directly in the config folder. Such potentially sensitive data currently belongs in .storage subfolder.
Perfect world, no such tokens would even be stored in .storage either, since it is better to store them an OS native keystore, like mac os’s Keychain, or Windows’ Credential Vault. But Linux does not have a single standard credential store, but multiple, and the ones it does have are not really optimal for use by a server program. Even still, Home assistant does let you use these options as a secrets.yaml replacement. Currently there does not appear to be a way to make it store secrets it would store inside .storage there, but there really should be such a way.
2 Likes
ok, should we have an HA wide amnesty/intervention on asking custom_component owners to move tokens to the right place?
Not much you can do if they don’t want to make the change. That’s one of the risks going custom.
ah, right, as there is no way to enforce it as its not being ‘published’ anywhere.
Still I guess we can ask nicely (off to raise some Feature Requests )
Doesn’t hurt to ask for sure!
To get back to the subject: any chance my WTH might make it in the feature list? 
I would love to be able to clean out my older tokens every once in a while and right now I have no clue what the old tokens were about…
for example uses a webos.conf in the config directory
or
drops tokens in the config directory too.
Should these not be either stored in the auth file, or be customizable to move them from the root?
LG webOS doesn’t have config flow (Configure via UI), so it’s a moot point. And flume does, if you configure through config flow.
right, but my point was there are a variety of tokens/auth/pickle/conf files in all different places.
It would be good to have a single rule, or allow the user to customize so all these random (and important) files are in one place no?
It does go into one place if you use config flow… You do realize that most of the 1500 integrations were made prior to config flow and they haven’t been updated yet?
with hacktoberfest round the corner, it could present a great opportunity to drive consistency?
(and no, not a clue how many have or haven’t, but if there is an example of the change needed, i could help out with those that haven’t made the update)