How about protocolMappers? If there were no changes to user, the refreshToken endpoint won't call protocolMappers but just use user data from previously saved cached token from userSession?

Marek

On 02/12/15 19:25, Stian Thorgersen wrote:

We don't replicate the session. It's a distributed cache so it's fetched internally from the correct node.

For refresh token maybe we could update the user session for a user that they need to be checked against the user changes?

On 2 December 2015 at 18:58, Bill Burke <bburke@redhat.com> wrote:

On 12/2/2015 12:54 PM, Bill Burke wrote:
>
>
> On 12/2/2015 12:46 PM, Stian Thorgersen wrote:
>> Wonder if we could do something similar with code 2 token. Could we not
>> set a cookie there as well? Then at most there would be two nodes for
>> one user.
>>
>> Alternative is to update code 2 token so it doesn't require the user
>> model. That would be more elegant. We could do that by making sure user
>> sessions are updated when required if user model changes.
>>
>
> You could optimistically create the token and store it within the client
> session. But then your overhead is in replication? Then again is
> replicating a few kilobytes that big of a deal?
>

Answering my own question...It probabbly isn't a big deal as you are
already replicating the client session anyways.

Doesn't help refresh token though. Refresh token needs to verify the
user is still enabled.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev