UMA tickets are sent by the resource server to the client when the access token does not have the necessary permissions. The client uses the ticket to enrich the access token with permission information, which can then be sent back to the resource server in order to access the resource. UMA tickets do not replace tokens. In Keycloak, users (and clients) have roles. When using UMA protection, you can use roles to determine what resources and scopes a user can access. For example, if the client tries to POST to /bank_accounts with an access token, your resource server could create a permission ticket requesting the create scope for the bank_account resource. The resource server responds with 401 and the permission ticker to the client. The client is smart enough to see the permission ticket and in turn sends the ticket (and auth token) to Keycloak. Keycloak can then look up the user's roles to determine if the user has the create scope for bank_accounts. Keycloak responds with an access token which includes the permissions, and with the new token the client once again tries to POST to /bank_accounts. The resource server confirms the permissions and creates a bank account. You don't need to use roles to determine UMA permissions. You can use groups, attributes, whatever you want. You don't actually need to use UMA permissions for the scenario described above. Access tokens usually have roles included in them. The resource server could examine the roles in the token to determine whether she can create a bank account or not. See https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript... and https://www.keycloak.org/docs/latest/authorization_services/index.html#_e... for javascript and UMA tips. On Fri, 21 Dec 2018 at 16:09, BELMONTET Matthieu <m.belmontet(a)systel-sa.com&gt; wrote: -- Regards, Geoffrey Cleaves