Client scope evaluate of getUserInfo is not equal to the actual response

I have implemented a custom UserStorageProvider that I have added as a provider in User Federation for my realm. When using OIDC to access this I can see that my custom provider software is triggered ok after I have filled in the keycloak provided user form with username and password. My custom component is calling a REST API to login the user to a legacy system and a few attributes are returned if the user is authenticated. After the OIDC authentication flow has completed I can see that the user is added in the users section in keycloak and that all the attributes are added as user parameters. In my plugin I store these attributes to the keycloak session userlocalstorage user with setSingleAttribute(key, value).
If I call keycloak with the accesstoken to getUserInfo() I get a JSON response with sub and preferred_username, but my user attributes enriched from my rest api is missing.
I have created a unique Client for this and after adding one or more of the attributes under the Mappers section inside my client configuration I can set Token mappers with Type User Attribute to add the user attributes to access token, identity token and userinfo. I chose to add the attributes to user info.
Under Client Scopes I see I can evaluate the output and when evaluating user info for a specific user I can see that the attributes are added to the user info response. Yay… but when calling the getUserInfo from eg postman or from curl using the access token my attributes are still missing.

Does anyone know if the evaluate feature is broken or is there any known bug with keycloak as the real output is missing these attributes? I have tried several things now, but it seems impossible to map the user attributes from the user federation plugin back to the user info response. (Using keycloak 15.0.2)

After a lot of failing and trying I found a workaround myself. I updated the Cache Policy to NO_CACHE and everything is working as expected. I guess the user is read before the attributes are added and as the User Federation caches the user it returns the cached user before the attributes were set. If anyone has any comments on how the cache can be invalidated on changes to the User attributes I would be very happy to get updated on this. Thanks.

1 Like