Evaluate user permission

I would like to know what is the best practice to evaluate user permissions/policies stored in Keycloak server. I’ve read the documentation but it is still not obvious for me how this should be done.
I have backend application (example) with REST API with following endpoints

  • /clock
  • /hello-world

I know that I can use roles to authorize access for specific roles. However. I would like to prepare permissions that

  • Alice user can send GET request to /clock endpoint
  • John user can not send GET request to /clock endpoint
  • Alice user can not send GET request to /hello-world endpoint
  • John user can send GET request to /hello-world endpoint

I found that I can evaluate user permissions using endpoint {{keycloackServer}}/realms/{{realm}}/protocol/openid-connect/token
but I can do it once and need to regenerate the user token.
Initially I thought that when I have user token and client credentials I can evaluate user permissions to the endpoint until token expires but it looks like when I evaluate token then it automatically expire.
I wanted to do something similar what can be done in:

Is it good approach to check if user have access to REST endpoint or should choose different one.

Sounds like you want to implement something against these APIs.

https://www.keycloak.org/docs/latest/authorization_services/index.html#_service_protection_api

You can do so via integrating one of the OOTB adapters in-front of your resource server.

https://www.keycloak.org/docs/latest/securing_apps/#_oidc

Or by using the Java client API inside your java services.

https://www.keycloak.org/docs/latest/authorization_services/#_service_client_api

FYI, the way we have done this is to use Spring Boot and the Java Spring Boot adapter (provided by Keycloak adapters) to secure a resource server. The Spring Boot app intercepts all requests to resource server and evaluate whether the users token has permissions. We use UMA to give the client a progressive way of obtaining permissions. We use Apache Camel HTTP to reverse proxy to the Resource Server once authorisation has succeeded. This components acts like a PEP (Policy Enforcement Point) within our solution.