Hi, I am using OpenID authentication to secure my NodeRed appllication. Unfortunately NodeRed does currently not support refresh tokens in the authentication flow: Securing Node-RED : Node-RED
The acces token has instead a really long lifespan of 7 days by default. I seem to experience some side issues because of this. I have linked the user rights to a claim, but because the user profile is only refreshed after a new login, the updates to the user rights by changing the claim seem only to be handled after the NodeRed access token expires. In a normal flow this user profile update would happen when the refresh token is used.
In the NodeRed documentation it is written that refresh tokens are not supported currently. Does this mean that this is on the road map? Is there any timeline when this will be implemented?
I'll be honest here and say that I don't recommend using node-red's built-in security for anything important. As you say, it has limitations. Great for something simple and low-value, but not really all that "Secure".
It is far better to move the security processing to a reverse proxy and restrict access to Node-RED to only come from the proxy (you need to also tell Node-RED settings to trust the proxy). Any decent proxy server should let you handle OpenID correctly including refresh tokens. Security Tokens are often susceptible to token hijack attacks and their lifespan should be short. Refresh tokens are critical to the security process.
The other thing of note if looking at Node-RED security is websockets. A traditional session handling process that works for an http only web app does not fully work when most of the traffic happens over websockets which is typical for Node-RED. The issue being that websocket connections, other than the initial handshake, do not permit custom headers which is the common way to pass the tokens. This can be an issue for some apps. The resolution is to force the token into all or some regular websocket messages. But it means that whatever is doing your security processing also needs to be aware of the websocket data and be linked into the standard http security process.
Thanks for the reply and the additional info over web sockets. Yes I fully agree that access tokens should be short lived and refresh tokens should be used. We do have other security measures like a reverse proxy in place. Unfortunately we also do need to identify the user that logs in in NodeRed itself. For instance to determine the allowed rights of a user. And to ensure that a user can only log in using the identity provider of our choice. Having no refresh tokens to update the access token is unfortunate. I was hoping that somebody from the NodeRed team could tell when support for refresh tokens would be added, since the documentation seems to suggest that this is something that will be added in the future.
If you already have a reverse proxy, if you use it to handle the authentication, you should be able to pass through a trusted header to Node-RED that could be used to indicate if the user is authenticated and even what their authorisation is shouldn't you?
