Re-using bearer token


I’m building an angular app that successfully handles the logging in of users.
Now, once logged in, the app makes some requests to a nodejs server (the same server that serves the static app, but the server proxies the request to a nodejs server).

In the request that comes in on the nodjs server, a bearer token is present.
In my server setup (expressjs) I have this code for the url in question:

app.use('/test', keycloak.protect());

when the request comes in, the bearer token from the angular app is in the request headers. However, it seems that keycloak in the nodejs server is not picking this up as the request to /test returns 403 permission denied.

As there anything that is obvious to the knowledgeable people here that is missing or that I’m doing wrong?

One thing I can think off is that the angular app is defined as a different client than the nodjs server. But the user I’m logged in with has all the roles that are required to access through both clients.

thx for any hints!


There might be more wrong in my setup. When doing direct calls to the nodejs server, as mentioned, I get access denied when the protect() is in place.
Should it not redirect my request to the sso server for login in that case?

further findings: It feels like the nodejs server is better configured now, it is sending 302 responses for login.

So while that is fixed, my problem remains that I want to make it so that the nodejs server considers the requests with the bearer token from the client app as ‘authorized’. This seems not yet the case.

This is my keycloak.json for the nodejs application:

  "realm": "Myrealm-test",
  "auth-server-url": "",
  "ssl-required": "external",
  "resource": "my_resource",
  "verify-token-audience": true,
  "credentials": {
     "secret": "abc-def-ghi-xxx-xxxxxxx"
  "use-resource-role-mappings": true,
  "confidential-port": 0

This might be completely off of course, any hints welcome.

in the end the problem was fixed with removing the ending / on the sso url that was in my keycloak.json file. This resulted in internal urls with // that didn’t match the realmurl comparison check. It’s a bit of a weird problem as this json file is generated by keycloak with the trailing /