@pamapa do you have any thoughts?

You can control the claims remaining in the user with the filterProtocolClaims settings property. See https://authts.github.io/oidc-client-ts/interfaces/OidcClientSettings.html#filterProtocolClaims

Hi @pamapa , I believe I'm having the same issue as the OP but with Keycloak, it bundles the allowed roles for user into access_token and the only claims I'm seeing in user.profile are the ones from id_token. I.e. setting filterProtocolClaims: false doesn't help, I've tried loadUserInfo: true but it doesn't help either because apparently Keycloak doesn't provide this in user info endpoint or it needs additional configuration (doing additional requests also seems unnecessary anyway). Here is what the claims in access token look like (please excuse the noisy Go pretty printer)

 Claims: (jwt.MapClaims) (len=22) {
  (string) (len=15) "resource_access": (map[string]interface {}) (len=2) {
   (string) (len=19) "admin-panel.filters": (map[string]interface {}) (len=1) {
    (string) (len=5) "roles": ([]interface {}) (len=2 cap=2) {
     (string) (len=17) "restricted-access",
     (string) (len=7) "editors"
    }
   },
   (string) (len=7) "account": (map[string]interface {}) (len=1) {
    (string) (len=5) "roles": ([]interface {}) (len=1 cap=1) {
     (string) (len=12) "view-profile"
    }
   }
  },
  (string) (len=4) "name": (string) (len=16) "Evgeny Dolzhenko",
  (string) (len=11) "family_name": (string) (len=9) "Dolzhenko",
  (string) (len=9) "auth_time": (float64) 1.729688096e+09,
  (string) (len=3) "typ": (string) (len=6) "Bearer",
  (string) (len=3) "azp": (string) (len=19) "admin-panel.filters",
  (string) (len=13) "session_state": (string) (len=36) "3ed45452-7fab-42be-b638-330e99b7c0d7",
  (string) (len=12) "realm_access": (map[string]interface {}) (len=1) {
   (string) (len=5) "roles": ([]interface {}) (len=3 cap=4) {
    (string) (len=14) "offline_access",
    (string) (len=17) "uma_authorization",
    (string) (len=28) "default-roles-infrastructure"
   }
  },
 ...snip...
 },

Thing is, from the OpenID Connect (OIDC) specification:

• ID tokens are required to be JSON Web Tokens (JWTs)
• Access tokens are more flexible and could be JWTs (but not mandatory), or opaque, ciphered...

The User object is an aggregation of what's inside the ID token + what's returned from the UserInfo Endpoint.
Because they both contains info about the user and they both are "specified" by the specs.
=> we know upfront what we are going to receive (with the exception that ID tokens MAY contain other custom Claims).

But Access tokens on the contrary, are open to implementation (i.e. they can be anything).
So in your case, the fact that they contains some user's info is typically a Keycloak's choice.

Therefore, the best thing to do is to read the info you need directly from the access_token.
And if, for simplicity, you want those info inside the User object, then extend from it yourself and add them there.
This cannot be (and should not be) the library's responsibility.