Caddy Reverse Proxy JWT Authorization for node red dashboard


This configuration described below is working, but I'm wondering if there is a way to pull from the authenticated users JWT token, what their user name (subject) is and have it display in a node red dashboard. So example if user "ricky" is logged in at the reverse proxy layer, and then connects through the reverse proxy to a node red dashboard (/ui/*), presenting the JWT auth token (cookie) to node red. Then the dashboard can display "Well Hello Ricky!" (and more importantly we want to pass "Ricky" as needed via flows as the authenticated user for an action).

We have a working configuration for node-red behind caddy reverse proxy, using caddy-auth-portal & caddy-auth-jwt, and jsonwebtoken installed via npm into node-red.

So a dashboard-middleware.js file was created and put into the .node-red/ path that handles the JWT token auth.

Then in the settings JS, we added the line:

ui: { path: 'ui', middleware: require('./dashboard-middleware') },

For the dashboard (ui), at this point we have followed the discussion around enabling dashboard ui's to configure in a way similar to admin for middleware authentication from the pull request that was merged here: add middleware, can be used for auth by librae8226 · Pull Request #209 · node-red/node-red-dashboard · GitHub as well as the's coverage of the ui configuration.

So the last 10 feet of integration is getting node red flows aware of this user from header, cookie, etc.

Any pointers on how to scrape session for user to be used in a dashboard display and actions... would be greatly appreciated.

just for reference in case anyone else is figuring out how to get caddy's part configured, assuming you have all the rest of the required caddy auth portal configuration present in your Caddyfile, you would define the route for node red as:

        route /ui/* {
                jwt {
                        enable claim headers
                reverse_proxy http://localhost:1880

I'm looking at the isLoggedIn node from the node-red-contrib-users (node) - Node-RED, and the question becomes would it be possible to bypass the user management portion of node-red-contrib-users and just provide a user (or role in the future) access list to the flow.

For situations where the user management is in another system, and node red is imbedded or operating behind a strong authenticating proxy, having the value of being able to leverage the isLoggedIn looks very powerful...

I think the first step would be to find out what information your caddy proxy passes to the node-red server. You could setup a simple middleware to console.log the headers of the proxied request. In your ./dashboard-middleware file, add a function that can do the logging, such as:

(req, res, next) => {

If you do find a jwt in there, you can view its content by copy/pasting it at

Thank you for your response, we we are processing the JWT token in our middleware like so:

 * Middleware for redirecting unauthenticated users to login page
const jwt = require('jsonwebtoken')
const dashboardAuth = (req, res, next) => {
  const token_name = 'access_token'
  const secret_key = 'AnExampleSecretString123'
  function parseCookies (request) {
    var list = {},
    rc = request.headers.cookie
    rc && rc.split(';').forEach(function( cookie ) {
      var parts = cookie.split('=')
      list[parts.shift().trim()] = decodeURI(parts.join('='))
    return list
  const cookie = parseCookies(req)
  jwt.verify(cookie[token_name], secret_key, (err, decoded) => { // verifies secret and checks if the token is expired
    if (err) {
    } else { // if everything is good, save to request for use in other routes
      req.decoded = decoded
      req.user_role = decoded && decoded.roles && decoded.roles[0]
module.exports = dashboardAuth

So the gap in knowledge is understanding how to take the elements we have unwrapped and leverage them from a node-red dashboard to incorporate the authenticated username in the flow. IF there are any good blogs/posts that you (or anyone in the community has seen) that is the content we need to give to the engineers developing the flows to start leveraging the authenticated user detail.