2

I've got an site using Azure B2C AD for authentication, and using the Graph API to update user claims. The claims are getting updated correctly, BUT, I've run into what looks like a propagation/timing issue.

Put simply: the front end is .Net core 2 MVC, calling through to a .net core webapi backend which does all the data manipulation, etc. When a user logs in normally? Everything is fine. Claims get passed through to the Web API no problem (via the bearer token, automagically handled via middleware, perfect).

The problem comes when we update user claims - if we update claims via the graph API, and then immediately do a challenge request right after (say, for example, we're switching user profiles inside the site), the claims that come back are still the old claim values, not the updated claim values. Solutions I've tried:

  1. Just updating the user object's when I update via graph API (obviously this doesn't work, it doesn't save back to the cookie so the next call in to the server will bring back the user via cookie with the old claim values)

  2. Putting in hardcoded delays after updating claims via the graph API, but before calling challenge. This works, but is obviously an awful solution because we have to hardcode our delays for the worst cast scenario (and still might not guarantee that we've waited long enough)

  3. Caching the updated claim values, capturing the OnTokenValidated event in OpenIdConnectOptions, and just updating the User object there if the claims coming back from the challenge don't match the updated claim values. This does save to the cookie, so all the front end calls will now see the new claim values, but it doesn't update the bearer token (which has all the claims encrypted inside) so the web API doesn't see the updated claim values

  4. Cache the updated claim values, and passing a redirectURI to the challenge call that lands on a specific page, which simply checks to see if the User's claims all match the updated claim values now. This works, and gives us the minimum amount of time so that we see the updated claims as soon as they're fully updated in B2C. BUT, it still can take several seconds, and while it's waiting to see all the updated claims, it's just sitting there recycling over to B2C and back to the landing page over and over again, flickering in the title bar, waiting.

My ideal solution would be if I could take #3 above, and update the bearer token at the same time so the web API sees it too. But I don't believe that's possible. I'm hoping somebody will tell me that it is. Next best would be if there's a way to just refresh the User object without doing a synchronous challenge over and over again - I was trying to figure out ChallengeAsync, various combinations of signout/signin calls with an updated user object with updated claim values, but none of those worked.

Hopefully I'm just missing something really stupid and somebody can point out where I'm being really stupid. That would save me a whole lot of headache.

WearySky
  • 107
  • 1
  • 11
  • Have you taken a look at this post? https://stackoverflow.com/questions/21960511/update-user-claim-not-taking-effect-why It goes over multiple solutions to the updated claims issue. – Frank H May 21 '19 at 19:25
  • 1
    @WearySky were you able to find a solution to this? I am running to a similar issue with an Angular-SPA/.NET Core API architecture. User profile is updated in .NET core Graph API, then I do a challenge using "loginRedirect" in angular but the new claims are not updated unless I wait up to 15 seconds after. – zaid safadi Jan 29 '22 at 20:26

0 Answers0