Open ravenclaw900 opened 1 year ago
I think the single credentials are even positive (simpler) from user perspective. But how to we handle the initial key exchange between frontend and backend?
Access+refresh tokens are quite common practice, also Google Drive and/or Dropbox use this (we needed to implement it into motionEye for cloud uploads).
I lost track on how authentication with backend nodes was/is actually handled until last release?
the terminal page could require a separate login
Simplest would be to enforce manual login on the console, so no additional login mechanism needs to be implemented.
My current thought is that a keypair will be generated on initial install, and the public key will just have to be copied from the main node to the other nodes. That seems easier than trying to implement something like ECDH over HTTP.
Before the fingerprint was set up, there was just a token stored in localStorage, with only the traditional verification (issuer, expiry time, issued time).
The public key long with a "copy to clipboard" button could be shown on the frontend as well, to make it a little easier.
Before the fingerprint was set up, there was just a token stored in localStorage
Ah right: #330 Does this mean that connecting to other backends is broken with current release, or is it just that one needs to re-enter the password whenever reloading the page? Not sure when I tested it the last time.
Yes, assuming the backend node has a password, it is currently broken.
Due to browser mechanics, when trying to connect to another node, the fingerprint cookie cannot be set by the other node when trying to login, therefore the token will always fail to validate. I have tried a lot of things to get it to work, but there really seems to be no way to either set the cookie or read the original one from a different domain.
Therefore, my new idea is to scrap the fingerprint/long-lived token approach for a different best-practice. 2 major things will need to change:
This will prevent many of the same security holes that the fingerprint approach did, with fewer downsides. However, if an access token is somehow stolen, the attackers will have access to change things until it expires. To minimize the damage caused from this hypothetical attack, the terminal page could require a separate login, which would give you one-time access to the terminal, so that it would not be possible to make any massive changes to the device by stealing the access token.
I hope that explanation made sense, but for more information on the access/refresh approach (though anything about OAuth2 can be ignored): https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/