Keycloak Full Scope Allowed: What it means ?

When a Client is created, we will get an option (on_off switch) for a parameter "Full Scope Allowed". In this Article, we will see what it means with examples. This article, is meant for beginners only, so steps for checking and verifying the same is given. If you are already aware about the topic, you can skip to the summary section of this article or check out other articles in this series.

Also Read

Client Roles and Scopes

Pre-Requisites

• keycloak should be up and running
• Realm (linux-data-hub-scope) should be created
• Create a new client (ldh-client) in the realm linux-data-hub-scope
• Create a user (casy) in the realm with credentials

Pre-Checks for the exercise

We will do some pre-checks for the sake of our article.

Verify Role Mapping of User

• Verify the role mapping given for the user
• Go to Realm (linux-data-hub)  → Users → Casy →  Role Mapping
• Below snippet shows the output, effective roles is the one in our interest

Keycloak Full Scope Allowed : Turned on

• Verify if the full scope is allowed for the client

• Access token obtained for the user casy will have the required roles and other details associated with the user
• Lets check the claim of the access token for the  user casy using the client ldh-client, when full scope is allowed

{
    "exp": 1667215412,
    "iat": 1667215112,
    "jti": "92635bb0-792d-4cf3-bcc6-2aa761c80c4e",
    "iss": "http://10.39.251.173:8080/realms/linux-data-hub-scope",
    "aud": "account",
    "sub": "2369f9b6-b46c-4ae6-bf03-a7f99347600f",
    "typ": "Bearer",
    "azp": "ldh-client",
    "session_state": "b837c9c0-6b1d-44b5-be12-e238a9526c77",
    "acr": "1",
    "allowed-origins": [
      "http://10.39.251.173:3000"
    ],
    "realm_access": {
      "roles": [
        "offline_access",
        "default-roles-linux-data-hub",
        "uma_authorization"
      ]
    },
    "resource_access": {
      "ldh-client": {
        "roles": [
          "manager"
        ]
      },
      "account": {
        "roles": [
          "manage-account",
          "manage-account-links",
          "view-profile"
        ]
      }
    },
    "scope": "email profile",
    "sid": "b837c9c0-6b1d-44b5-be12-e238a9526c77",
    "email_verified": false,
    "club_names": "Santos,FC Barcelona,borussia dortmund fc",
    "name": "***",
    "preferred_username": "casy",
    "given_name": "**",
    "family_name": "*",
    "email": "[email protected]"
  }

• From the above snippet, it can be seen that the claim obtained have all the roles associated with the user which was verified earlier

Keycloak Full Scope Allowed : Turned off

• Make the Full Scope Allowed as false, once it is marked as false. Additional options will be seen
• From the below snippet, it can be seen that, we will get another option called "Available Roles", from this option we can select the required roles and can be added in Effective Roles

• Lets check the claim for the user casy. It should be kept in mind, we have not done any changes to the roles of casy

[root@abhi-rocky ~]# token=$(curl -s -k -g -d "client_id=ldh-client" -d "username=casy" -d "password=1234" -d "grant_type=password" -d "client_secret=" "http://10.39.251.173:8080/realms/linux-data-hub-scope/protocol/openid-connect/token" | sed 's/.*access_token":"//g' |sed 's/".*//g');jq -R 'split(".") | .[1] | @base64d | fromjson' <<< $token
{
"exp": 1667216265,
"iat": 1667215965,
"jti": "759f56df-96ba-4a0f-8f51-f4ab1e2bed25",
"iss": "http://10.39.251.173:8080/realms/linux-data-hub-scope",
"sub": "2369f9b6-b46c-4ae6-bf03-a7f99347600f",
"typ": "Bearer",
"azp": "ldh-client",
"session_state": "279f8e2f-30a5-4bbf-bd39-6ccadff618c5",
"acr": "1",
"allowed-origins": [
"http://10.39.251.173:3000"
],
"realm_access": {
"roles": [
"offline_access"
]
},
"resource_access": {
"ldh-client": {
"roles": [
"manager"
]
}
},
"scope": "email profile",
"sid": "279f8e2f-30a5-4bbf-bd39-6ccadff618c5",
"email_verified": false,
"club_names": "Santos,FC Barcelona,borussia dortmund fc",
"name": "***",
"preferred_username": "casy",
"given_name": "**",
"family_name": "*",
"email": "[email protected]"
}

• It can be seen that, only the roles assigned in the Assigned Role is available in the access token  claim, even though the roles (default-roles-linux-data-hub, uma_authorization) are available to the user. since we used ldh-client for getting the token, ldh-client was able to control/filter the roles available for the user

Keycloak Full Scope Allowed: What it means ?

• When we give full scope allowed as on, all the roles given for  the users will be part of the access token  claim given by the client
• When we give full scope allowed as off, we will get more control over the roles available in the access token claim
• Even though the user have the roles assigned, when access token is generated by the client where required roles are selected. Only those selected  roles will be part of the access token
• Roles given in the client via Scope Mapping taken higher precedence over the roles given for the User
• In other words, from the point of Set Theory, Effective role available in the token will be  intersection of User Roles and Roles given for the client via Scope Mapping