[keycloak-dev] Remove TokenManager.verifyAccess method?

[Stian Thorgersen]

I think it's better if the old role is just removed. If you think about it
the new access token is sent to a service in most cases and the service
only has that new token as a reference for what roles the user has anyways.

I don't understand what you mean about "it is sufficient to check consents
rather than roles". Both need to be checked, always. Consents limits the
access, while role is the permissions the user/client have.

On Mon, 26 Nov 2018 at 08:53, Marek Posolda <mposolda at redhat.com> wrote:

> Yes, it is updated. And new token can contain some more roles, which
> weren't presented before on the old refresh token. However if the newToken
> doesn't contain any role, which was present in the old refresh token, then
> refreshToken request is rejected ATM. That's what I think is not great
> behaviour as it is sufficient to check consents rather than roles.
>
> Marek
>
> On 26/11/2018 08:46, Stian Thorgersen wrote:
>
> If I'm not mistaken the token is already updated with new roles today.
>
> On Mon, 26 Nov 2018 at 08:44, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> +1
>>
>> On Wed, 14 Nov 2018 at 09:09, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Right now, during each token refresh, we're verifying if the newly
>>> refreshed access token still contains all the roles, which were present
>>> in the refresh token. If not, the refresh token is rejected.
>>>
>>> I wonder if this check can be removed? This will also allow us to remove
>>> the roles (realm_access and resource_access claims) from the refresh
>>> token. Anyone knows a reason if this check can't be removed?
>>>
>>> I think the reason why this check was originally added is due the
>>> consent. Previously we did not have clientScopes and the consents on the
>>> consent screen were represented by individual roles and protocolMappers.
>>> However with clientScopes, this seem to be obsolete IMO.
>>>
>>> During token refresh, we should check that consents represented by
>>> clientScopes in the refresh token were not revoked by the user (or
>>> admin). If they were rejected, the refresh token should be rejected.
>>> We're doing this. However if some individual role was removed from the
>>> user (or from the role scope mappings), I don't see an issue with
>>> successfully refresh token and just ensure that the revoked role is not
>>> in the new token anymore.
>>>
>>> WDYT?
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>