[keycloak-user] Client scopes not checked?

[Marek Posolda]

On 20/06/18 13:36, Matthias Kesternich wrote:
>> This leads me to my next question: If I want to return only the scopes that
>> a user actually may acquire, how do I do this in Keycloak? Do I use the
>> "Authorization" tab and configure appropriate policies? Do I write a custom
>> mapper that overwrites the default "scope" value? I'm going to experiment
>> with this anyways, but I'd like to know if I'm abusing the wrong machinery
>> to achieve this goal.
>
>
> So I experimented a bit and it seems I can just use a "User Client Role" mapper
>
> that adds the roles/permissions to the token. This is much easier than the full
>
> UMA thing under "Authorization". There seem to be almost no working python
>
> clients for UMA as well.
>
> I am also probably going to separate "scope" and "permissions". I'm realizing
>
> that "scope" means "the client is allowed to access this and that" while
>
> "permissions" means "the user is allowed to access this and that".
>
> This understanding seems to be verified by https://stackoverflow.com/questions/48351332/oauth-scopes-and-application-roles-permissions .
Yes, exactly. The "scope" is "the client is allowed to access this and 
that" . In other words, if you create client scope "admin-write" and you 
add it as default client scope to the client "foo", then access token 
issued for client "foo" will always contain scope "admin-write" . 
Regardless of the roles which user actually has.

One more note: Access token already contains the roles available to user 
by default. You can see claims "realm-access" and "resource-access" 
inside access token. Which you can doublecheck in "Evaluate" tab of 
client. Right now, we're adding those claims "realm-access" and 
"resource-access" into the token automatically, but we want to add 
protocolMapper to add them just "on demand" .

The "User Client Role" protocol mapper is needed just if you want roles 
in the access token in some different format, than built-in claims 
"realm-access" and "resource-access" use. This was the case just for 
some 3rd party OIDC adapters (AFAIK it was Apache mod-auth-oidc, which 
was the original reason why "User Client Role" protocolMapper was 
developed and contributed by our community).

Marek
>
>
>
> Does the solution using "User Client Role" make any sense to you?
>
>
>
> Best,
>
> -Matthias
>
>