I have a Keycloak server running in a Docker container on my Synology NAS (via Portainer). It’s configured to use Service Accounts Roles for client credentials authentication.

My Node.js/Express backend uses keycloak-connect to protect API endpoints. When running the backend locally, everything works fine—tokens are issued correctly and the protected routes are accessible. However, when I containerize the backend and run it on the same NAS (same Portainer instance), I encounter a 403 Forbidden error on protected routes.

Below is my Keycloak configuration and how I initialize it in my application:

Keycloak Configuration (auth/keycloak-iot-device.js)

const Keycloak = require('keycloak-connect');

const keycloakIot = new Keycloak({ }, {
  "realm": process.env.KEYCLOAK_REALM,
  "bearer-only": true,
  "auth-server-url": process.env.KEYCLOAK_SERVER_URL,
  "ssl-required": "none",
  "resource": process.env.KEYCLOAK_CLIENT_ID_IOT
});

module.exports = keycloakIot;

Application Initialization (app.js)

const keycloakIot = require("./auth/keycloak-iot-device");

...
app.use(keycloakIot.middleware());
...

Protected Route Example

router.post("/v3/connection", keycloakIot.protect(), (req, res, next) =>
  postDeviceConnection(req, res, next)
);

Additional details

• Both containers (Keycloak and the backend) run on the same Docker network in Portainer.
• The backend uses the same Keycloak client credentials (client ID and secret) as the local environment.
• Tokens issued to the service account contain the correct roles.
• The backend container can reach the Keycloak container via its internal Docker hostname.
• Docker container logs do not reveal any specific errors.

Question What might be causing the keycloak-connect middleware to return a 403 error when the backend is containerized on the NAS, even though it works fine when run locally? Is there a known issue or configuration step with service account roles in this Dockerized setup that I might be missing?

Any help or pointers would be greatly appreciated. Thanks!

Testing is done using Postman running on the development machine. Token looks ok when checking it with jwt.io.