Welcome to the Kinde community

Updated last week

Refresh claims approach

Hi, I'm trying to figure out how to refresh claims / user details with Kinde. There are few scenarios I'm trying to solve this for:

  • As part of registration activities a user might be allocated to an organisation & role via the M2M API. Their original access token doesn't have these claims and they end up with forbidden access. I understand the why as the Nuxt server is using the cached values.
  • Users might have their roles changes within an admin section using the M2M API.
If I log the user out and in again, it works fine. If I refresh the claims using refreshUserClaims() in the management API (either via the JavaScript SDK or .NET SDKs) then nothing happens and the user still gets forbidden access issues from my application (I do get a success response from Kinde when calling the refresh API).

With Kinde, how are you supposed to handle this? Ideally without logging out and in again.
W
O
S
19 comments
Just came here to ask the exact same question, cause I'm having the same use-case as described above and want the user changes reflected immediately in my app instead of them only being reflected after logging out and back in again
Hey @Stephen and @Woet,
Thanks for reaching out on refreshing claims. The logic to refresh claims is different per SDK.

Are you able to let me know what SDKs you want to know how to refresh claims, and I can get back to you with some advice?
Hey @Oli - Kinde , thanks for the response! I'm currently using the Next.js app router SDK
Hey @Oli - Kinde.

  • I'm using Nuxt (Vue) to perform auth / registration using your SDK. In the case of the API call to refreshing claims I'm using your TypeScript SDK as that's your current guidance.
  • I'm also using the .NET SDK to try and force a claims refresh. My .NET APIs are the one's doing the M2M 'heavy lifting', I'm only using TypeScript SDK to do the claims refresh as that is the Nuxt server which 'owns' the Kinde cookie / JWT. (I do also force a claims refresh for actions which change claims values in the .NET API but I understand why it does nothing, my .NET API only validates the JWT with Kinde)
I guess one question I would have for your team is why an API call to Kinde's servers via refreshUserClaims() is needed at all, at least in terms of understanding what is actually happening. I would have thought just forcing a refresh of the users auth token would in turn refresh the claims. It's been a minute since I looked at your Nuxt SDK source code, but IIRC there was another method to refresh claims (that didn't require a M2M app) but because it was using your sessionManager the session manager already saw that there was a 'valid' auth token and so doesn't call your servers to refresh, at least to my understanding.

P.S. working on Christmas day Oli? That's dedication 😁
Hey @Woet,
We have some major changes to our NextJS SDK that will fix a whole range of refresh claims issues - so stay tuned for this.
I'm using Nuxt (Vue) to perform auth / registration using your SDK. In the case of the API call to refreshing claims I'm using your TypeScript SDK as that's your current guidance.
I'm also using the .NET SDK to try and force a claims refresh. My .NET APIs are the one's doing the M2M 'heavy lifting', I'm only using TypeScript SDK to do the claims refresh as that is the Nuxt server which 'owns' the Kinde cookie / JWT. (I do also force a claims refresh for actions which change claims values in the .NET API but I understand why it does nothing, my .NET API only validates the JWT with Kinde)
It sounds like you are using the TypeScript SDK to refresh claims and it's not working as expected.
So I would suggest raising an GitHub issue on the TypeScript SDK GitHub repo around your use-case of refreshing claims - it's easier for my expert TypeScript teammate to address TypeScript queries raised on GitHub when he has time to look into them
I guess one question I would have for your team is why an API call to Kinde's servers via refreshUserClaims() is needed at all, at least in terms of understanding what is actually happening. I would have thought just forcing a refresh of the users auth token would in turn refresh the claims. It's been a minute since I looked at your Nuxt SDK source code, but IIRC there was another method to refresh claims (that didn't require a M2M app) but because it was using your sessionManager the session manager already saw that there was a 'valid' auth token and so doesn't call your servers to refresh, at least to my understanding.

By default, Kinde caches tokens for performance.
The cache becomes invalid when user information is updated via UI or API, including:
  • Profile information updates
  • Organization membership changes
  • Role changes
  • Permission updates
  • Property changes
  • User-level feature flag updates
Why refreshUserClaims() is needed:
There are specific scenarios where individual user tokens don't automatically update, including:
  • Feature flag changes at organisation/environment level that users inherit
  • Permissions added to a role that the user has
For these cases, the refreshUserClaims endpoint explicitly invalidates the cache for that specific user. This ensures the next token refresh will pull fresh claims from Kinde rather than using cached data.

Token Refresh Behaviour
You raise an interesting point about the session manager and token validation. While I can't speak to the specific Nuxt SDK implementation, I can explain that just refreshing an auth token alone may not force new claims if the cache is still valid. The refreshUserClaims endpoint specifically invalidates that cache to ensure fresh data on the next token refresh.

Let me know if you have any further questions.
P.S. working on Christmas day Oli? That's dedication 😁
We keep our eyes on Kinde businesses and systems, whilst you enjoy your holiday period πŸ˜‰
Thanks @Oli - Kinde I've added to https://github.com/kinde-oss/kinde-typescript-sdk/issues/63 as I suspect this 'behaviour' might be the root cause of the issue and it may be intentional, not a bug.

If it's intentional I'm presuming it's because different organisations can have different authentication policies, particularly for your upgraded Organisations.
Hey @Stephen,
Thanks so much for raising this GitHub issue. My TS teammate will look at this when he is back online in the new year.

We are in the process of building out our js-utils package. Once its it at a state we are comfortable with, we will get all our JS-based SDKs to depend on the js utils package.
I am confident our js utils package solves your token refresh issues, e.g. when reassigning orgs.

Please don't hesitate to raise anymore GitHub issue - they are the best way for my teammates to investigate and communicate on our progress on issues that come up.
Thanks @Oli - Kinde, any rough timeframe for when you think you might have the js utils package in place? Right now it's just annoying, because I don't have any customers as I build out my MVP. But it would be a significant issue for me were I live, to the point where I'd need to heavily change my onboarding workflow to work around it.
Hey @Stephen,
I cannot provide any timelines at the moment. But when my teammate is back online on Jan 6 his #1 priority will be getting the new JS Utils package live.
NP @Oli - Kinde I understand. If I could get some rough ballpark at some point in Jan once your teammate has a better sense of the effort involved that would be appreciated as it would allow me to plan accordingly. E.g. if I can just wait for it to be released, if I need to do a workaround, or if I just go with early customers and advise them of the issue / workaround.
Not expecting / asking it to be delivered in Jan, just some 'no promises' indication of when it might drop
Hi @Stephen,
Totally understand info around when you can expect the new JS Utils package.
I am on break from New Years until Jan 13, and I will speak to my teammate then and post here when we think the new JS Utils package will be released.
@Woet if you follow the GitHub thread https://github.com/kinde-oss/kinde-typescript-sdk/issues/63 it might solve your issue for you. With guidance from Coel (Kinde) I was able to redirect the user to log in (with no prompt so they don't see the Kinde UI) with the organisation and get the expected claims.

cc @Oli - Kinde
@Stephen thanks for sharing! I think our needs to refresh claims are similar, so I'll take a look if this thread can help me. My exact use-case is that if an ADMIN changes the role of a user, that the change in permissions is reflected immediately for that user after changing the role. So what I think would need to happen, is that the change in roles done by the ADMIN user, needs to trigger a refresh of the claims for another user.
Same for when deleting users
Ahh, my use case might be slightly different @Woet.

The problem was that upon Kinde user creation the user didn't belong to any Kinde organisations (and roles are assigned to users in an org, not to the user itself). After initial registration I would then assign the user to the appropriate organisation. I would call refreshUserClaims() using Kinde's Management API but it did nothing.

Based on the GitHub thread I later learned it was because the user was still signed into no organisations and I needed to sign the user into the organisation they had been added to (which could be done 'silently'). This fixed my issue.

But I still also need to start working on your use-case at some point as well.

According to Kinde's document this should just happen - https://docs.kinde.com/authenticate/manage-authentication/sync-with-kinde/.

However, most systems will cache a valid JWT so it isn't clear to me how a web server (or browser) would know that the JWT is no longer valid unless it's using something like Token Introspection (https://www.oauth.com/oauth2-servers/token-introspection-endpoint/) or as suggested by Kinde using short expiry tokens.

@Oli - Kinde I know you're on leave, but it would be good if we could get some guidance on this when you get back, happy to jump on a call as well. It's likely it's just documentation but I would say for many developers (including myself) it would be good to get some more crystal clear guidance on how this works to save on confusion.
Add a reply
Sign up and join the conversation on Discord