Incorrect authorisation from HTTP token

Agents, Protocols and APIs
1

Hello,

I am trying to communicate with OpenRemote via HTTP requests alongside MQTT to be able to make asset changes - like creating / deleting assets / attributes.
I have been stuck for a while at what feels like the last step. I can receive a token from the client_credentials flow, however while using it I consistently get the 403 error.

Swagger works correctly, and if I pinch it’s own token I can correctly use it to make calls elsewhere until it expires. The applications I’m making calls from are working correctly and can receive data from the /info GET request that, from what I can tell, doesn’t require authorization.

I am using postman to test my queries and will be calling from node-red once they are working. Both are currently in the same position of not being authorized with the token they receive.

Here are the raw-logs from both Postman requests (token & random GET).

Warning: Self signed certificate
POST /auth/realms/master/protocol/openid-connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: PostmanRuntime/7.29.0
Accept: */*
Cache-Control: no-cache
Postman-Token: 4976c3b3-fb87-4b5d-a80d-5acd7772d186
Host: 10.100.211.191
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 95
 
grant_type=client_credentials&client_id=httpuser&client_secret=g86inAa5rAFVO7r3ocdPI04aNuJ1E3LO
 
HTTP/1.1 200 OK
cache-control: no-store
set-cookie: KC_RESTART=; Version=1; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/master/; HttpOnly
x-xss-protection: 1; mode=block
pragma: no-cache
x-frame-options: SAMEORIGIN
referrer-policy: no-referrer
date: Fri, 15 Jul 2022 09:14:21 GMT
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
content-type: application/json
content-length: 1627
 
{"access_token":"eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICItQ3FGY1J2RGNGempoVFBoTjBwR05NOE1WaXNCVl8yV3pOZzEyUTlvTzBZIn0.eyJleHAiOjE2NTc4NzY1MjEsImlhdCI6MTY1Nzg3NjQ2MSwianRpIjoiODM5NjQ3YzEtMTBiYS00ODZhLTk3YTItZmI5ODc5MmE0YjA3IiwiaXNzIjoiaHR0cHM6Ly8xMC4xMDAuMjExLjE5MS9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJhdWQiOiJhY2NvdW50Iiwic3ViIjoiOGRiZWI3OWEtODljZS00MWRhLTlkN2YtOTRlNGU5NGY4MjhjIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoiaHR0cHVzZXIiLCJhY3IiOiIxIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbImRlZmF1bHQtcm9sZXMtbWFzdGVyIiwib2ZmbGluZV9hY2Nlc3MiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7Imh0dHB1c2VyIjp7InJvbGVzIjpbInJlYWQ6dXNlcnMiLCJ3cml0ZTpsb2dzIiwid3JpdGU6YXNzZXRzIiwid3JpdGU6cnVsZXMiLCJ3cml0ZTphZG1pbiIsInJlYWQ6bG9ncyIsInJlYWQ6bWFwIiwicmVhZDpydWxlcyIsInJlYWQ6YXNzZXRzIiwid3JpdGU6dXNlciIsIndyaXRlOmF0dHJpYnV0ZXMiLCJyZWFkOmFkbWluIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6InByb2ZpbGUgZW1haWwiLCJjbGllbnRJZCI6Imh0dHB1c2VyIiwiY2xpZW50SG9zdCI6IjEwLjEwMC4yMTEuMTkxIiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzZXJ2aWNlLWFjY291bnQtaHR0cHVzZXIiLCJjbGllbnRBZGRyZXNzIjoiMTAuMTAwLjIxMS4xOTEifQ.GTgk6I7InzVETTuTCyqgxDBYy2hlCZVlNxTxpbBZW7kjFP2315tsJJ53h5i7VH_BBx1Dk1Whue2Dx5I_oTl_qngS6AZ4UEwP20JtGmUy98GsBghRTcDK_fppiB_pcLT61kyebh9l5raZVkIvWr90qo-ybSqykLBIa_gizdNZxx5M8xXpLzcZqkdG8y6wtZdR5347uFROMD9lpjFcz6irhoXD3Gps3YjMvHz4vl0BP3_ew-I_uh15HrxFo9AxRsV3RxObpJ2Md6dloEw6jPKfy9pUYJ6IXoldx4FP4V_gWaEm3dRefBcQ5VoU9OI8CFVaaha5inZnxRqmfchYWVVI8Q","expires_in":60,"refresh_expires_in":0,"token_type":"Bearer","not-before-policy":0,"scope":"profile email"}

&

Warning: Self signed certificate
GET /api/master/health HTTP/1.1
Accept: application/json
Accept-Language: en-GB,en;q=0.5
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICItQ3FGY1J2RGNGempoVFBoTjBwR05NOE1WaXNCVl8yV3pOZzEyUTlvTzBZIn0.eyJleHAiOjE2NTc4NzY1MjEsImlhdCI6MTY1Nzg3NjQ2MSwianRpIjoiODM5NjQ3YzEtMTBiYS00ODZhLTk3YTItZmI5ODc5MmE0YjA3IiwiaXNzIjoiaHR0cHM6Ly8xMC4xMDAuMjExLjE5MS9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJhdWQiOiJhY2NvdW50Iiwic3ViIjoiOGRiZWI3OWEtODljZS00MWRhLTlkN2YtOTRlNGU5NGY4MjhjIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoiaHR0cHVzZXIiLCJhY3IiOiIxIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbImRlZmF1bHQtcm9sZXMtbWFzdGVyIiwib2ZmbGluZV9hY2Nlc3MiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7Imh0dHB1c2VyIjp7InJvbGVzIjpbInJlYWQ6dXNlcnMiLCJ3cml0ZTpsb2dzIiwid3JpdGU6YXNzZXRzIiwid3JpdGU6cnVsZXMiLCJ3cml0ZTphZG1pbiIsInJlYWQ6bG9ncyIsInJlYWQ6bWFwIiwicmVhZDpydWxlcyIsInJlYWQ6YXNzZXRzIiwid3JpdGU6dXNlciIsIndyaXRlOmF0dHJpYnV0ZXMiLCJyZWFkOmFkbWluIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6InByb2ZpbGUgZW1haWwiLCJjbGllbnRJZCI6Imh0dHB1c2VyIiwiY2xpZW50SG9zdCI6IjEwLjEwMC4yMTEuMTkxIiwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJzZXJ2aWNlLWFjY291bnQtaHR0cHVzZXIiLCJjbGllbnRBZGRyZXNzIjoiMTAuMTAwLjIxMS4xOTEifQ.GTgk6I7InzVETTuTCyqgxDBYy2hlCZVlNxTxpbBZW7kjFP2315tsJJ53h5i7VH_BBx1Dk1Whue2Dx5I_oTl_qngS6AZ4UEwP20JtGmUy98GsBghRTcDK_fppiB_pcLT61kyebh9l5raZVkIvWr90qo-ybSqykLBIa_gizdNZxx5M8xXpLzcZqkdG8y6wtZdR5347uFROMD9lpjFcz6irhoXD3Gps3YjMvHz4vl0BP3_ew-I_uh15HrxFo9AxRsV3RxObpJ2Md6dloEw6jPKfy9pUYJ6IXoldx4FP4V_gWaEm3dRefBcQ5VoU9OI8CFVaaha5inZnxRqmfchYWVVI8Q
User-Agent: PostmanRuntime/7.29.0
Postman-Token: 3d946ffe-d3e3-4e70-bcc3-ab002a191b6d
Host: 10.100.211.191
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
 
HTTP/1.1 403 Forbidden
content-type: text/plain;charset=UTF-8
content-length: 83
date: Fri, 15 Jul 2022 09:14:26 GMT
 
Request failed with HTTP error status: 403 Forbidden
Please contact the help desk.

Thanks

2

Hello again,

I’m afraid this issue is still haunting me and I’m unable to make any API calls via HTTP.

As a little explanation, I would ideally want to dynamically create / destroy assets during runtime as there will be a varying number of simulated / real units. Hard coding a limit on or individual components, while possible, is something I would like to avoid. As far as I understand, HTTP is the only API able to achieve this.

From my understanding, the 403 error means that both the request & token are correct / valid - however, it lacks permission after the authorization to access the requested resource.
I am not sure why my deployment is struggling on this when I cannot find the same issue elsewhere on this forum.

I have tried many combinations of permission allocated to the service user, for example:

httpuser
httpuser1310×537 30.6 KB

Having all boxes ticked or un-ticked makes no changes to the end result of the HTTP call.

I have been testing using postman; using the OAuth 2.0 Authorization tab to obtain / use my token.
Here is my configuration for that.

postauth
postauth1076×640 42.8 KB

I mentioned before that swagger works, and can even use it’s bearer token for my own requests. Perhaps using the authorizationCode flow - which swagger uses - will be successful for me? If so is there a robust way to use that instead of clientCredentials for my API calls?

Finally, I have had a nose around the Keycloak Admin Console. There are many different options available related to authorization (all of which I don’t really understand). Perhaps a small change of some of the options in there can fix my issue.

Apologies for a reply that may sound impatient. I have been avoiding or racking my brain over this for a week and have reached a point in my project where this is limiting my progress.

Thanks again

1 Like
4

So, it fixed itself.

After messing with configurations I broke MQTT API connection to OR too.
After days of nothing - and plenty of re-installs - I installed Docker Desktop.
It seems DD has it’s own separate docker environment depending on whether it is running or not.

Whether it was a fresh new environment to install from, or a coincidental update to the manager’s image, It all started working.

Thank you everyone who read through my issue and got just as puzzled as I did.

2 Likes