knolleary
commented
1 year ago This was originally raised in the Node-RED Slack. I think the issue description here is raising some points above and beyond what we'd discussed there and I wouldn't want them to be overlooked.
The original report was that the recently added Personal Access Tokens couldn't be used to access Node-RED endpoints when the FF User Auth option is set on the instance. This is because the FF User Auth option was primarily geared towards browser-sessions accessing a hosted dashboard rather than non-interactive requests.
So the scope of this issue is to update our FF User Auth handling to work with the Personal Access Tokens being provided as a bearer token in a request to Node-RED.
The FF User Auth option (if at all implementable for API consumption) is an anti-pattern for several reasons — sharing personal access tokens, access granularity, unlimited expiry dates and hostile account take-overs.
It is true to say our initial implementation of Personal Access Tokens does not provide any granularity of scope - that was an intentional choice for the first iteration. We will add the ability to have finer-grained scopes for the tokens in a future iteration (action: check that got raised and if not, raise it for the backlog).
lgrkvst
MarianRaphael
ZJvandeWeg
Description
When exposing an FF instance through an HTTP In endpoint, the endpoint becomes subject to the instance's HTTP Node Security settings.
Of these settings, options None and Basic Auth offer no to little security when protecting a REST API. The FF User Auth option (if at all implementable for API consumption) is an anti-pattern for several reasons — sharing personal access tokens, access granularity, unlimited expiry dates and hostile account take-overs.
In order to expose HTTP In endpoints to an API consumer in a secure manner, HTTP Node Security should offer access through user-generated bearer tokens.
Have you provided an initial effort estimate for this issue?
I am not a FlowForge team member