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(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
+1
On Wed, 14 Nov 2018 at 09:09, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev