0 Design: multiuser
knolleary edited this page 2014-11-07 15:05:54 -08:00

Node-red is currently a userless system. Anyone can point their browser at the runtime and edit the active flows.

When we talk about multiuser/multitenancy, there are a number of things that could mean.

  • An editor that can be logged into by multiple users
  • A runtime that runs the flows of multiple users

There are no immediate plans to change the runtime to support multiple, isolated flows. This item is focussed on what changes are needed in the editor and api to support multiple users.

An alternative runtime could be conceived that serves the editor and forwards individual user requests to individual runtime instances.

This must also consider how to seamlessly migrate from being userless to having a default user.


Need to investigate choices for authentication mechanism between a client and the runtime. It might not just be the editor; should be possible to secure http nodes using the same mechanism.

Is OAuth 2.0 - Resource Owner Password Credentials Grant (RFC 6749, Section 4.3) - a good starting point?


Currently developing this in my knolleary/node-red fork under the auth branch.

When enabled, all api requests must provide a valid access token in the Authorization header. The header is obtained by posting to '/auth/token', providing username, password, client_id, client_secret and scope.

  • should we use refresh tokens as well as access tokens?
  • how to tie it into 'httpAdminAuth'?
  • how to plug in multiple users?
  • how to do 3rd party oauth auth?
  • websocket connection auth