Repository navigation
Authorization Enforcer API returns 403 Forbidden when realm roles are removed from JWT token #52609
Replies: 1 comment
|
Turn on Fetch Roles in the role policy (available since Keycloak 25, added by #27430 for exactly this symptom, #20736). By default a role policy only looks at the roles carried by the token you send with the authorization request, which is why removing them from the JWT (Full Scope Allowed off) makes the policy deny; with Fetch Roles enabled it ignores the token and checks the user's role mappings instead. From the Authorization Services guide, role policy configuration: "Fetch Roles: By default, only the roles available from the token sent with the authorization requests are used to check if the user is granted with a role. If this setting is enabled, the policy will ignore roles from the token and check any role associated with the user instead." In code that is So, to your questions: 1 and 2, yes, that is the default, the role policy evaluates the token unless it is told to fetch; 3, a role policy with Fetch Roles is the supported way to keep realm roles out of the JWT while still deciding on roles centrally, and on 24.x there is no equivalent; 4, the group policy has the same switch the other way round, "Groups Claim": leave it empty and, per the same guide, "If not defined, user’s groups are obtained from your realm configuration", so group-based policies work without any claim in the token either. The other policy types in the guide are User (a fixed list of users), Regex (matches a claim in the token, so it does not help here) and JavaScript (needs to be deployed as a JAR). The token you present still has to identify the user, since that is what the lookup starts from; it just no longer has to carry the roles. |
Uh oh!
There was an error while loading. Please reload this page.
Hi Team,
We are using Keycloak Authorization Services to evaluate API access through the token endpoint (/protocol/openid-connect/token) by sending:
grant_type
audience
response_mode
permission
Our goal is to keep JWTs lightweight, so we disabled Full Scope Allowed on the client, which removes realm roles from the access token.
The user is still associated with the same realm roles in Keycloak, and our authorization policies are role-based. However, when we request permission evaluation, Keycloak returns 403 Forbidden.
From our investigation, it appears that the authorization engine evaluates the roles contained in the subject token and does not perform a fresh lookup of the user's role assignments from the Keycloak database. As a result, once realm roles are removed from the token, the role-based policy evaluation fails even though the user-role mappings are still present in Keycloak.
Questions:
1.Is this the expected behavior for UMA permission evaluation?
2.Does Keycloak Authorization Services always rely on role claims present in the access token rather than looking up current role assignments from the database?
3.Is there a recommended approach to implement RBAC policies while keeping realm roles out of the JWT?
4.Are there alternative policy types or authorization patterns that allow permission evaluation based on user attributes, groups, or database lookups instead of token role claims?
Our requirement is to perform authorization centrally in Keycloak while avoiding large JWTs that contain realm-level roles.
Any guidance or best practices would be greatly appreciated.
Thanks!
All reactions