Id token and access token do not get the updated user info when doing AcquireTokenSilentAsync

[nataliahering]

I am doing the following steps

1. Execute this code

var authResult1 = await app.AcquireTokenInteractive(App.ApiScopesBasic)
                   .WithUseEmbeddedWebView(false)
                    .WithParentActivityOrWindow(new WindowInteropHelper(this).Handle)
                    .ExecuteAsync();

which is in the SignInButton_Click code of this sample.
an id token is returned, which includes several claims including for example the user's first name - which right now is "name1".

2. After the above call is done, I manually update the information of the user in the azure portal (eg. update the first name from "name1" to be "name2"). In reality, I would not update the user's info in the portal but I could have some other application updating the user's information using graph API while the user still has a valid refresh token.

3. Do this call

var authResult2 = await app.AcquireTokenSilent(App.ApiScopesBasic, accounts.FirstOrDefault())
                        .WithForceRefresh(true)
                        .ExecuteAsync();

in the id token of this auth result, I still get the "name1" as in the call of step 1 (instead of the "name2" as updated in step 2). If instead of acquiring the token silently, I do an interactive one then I will get the correct name.

Is the .WithForceRefresh(true) not enough? How can I force get the user's latest information without requiring user interaction?

thanks

[nataliahering]

In a similar manner, in the above step #2 I go in the portal and revoke the user's sessions. I would expect that step #3 would fail. Instead it fetches the user's tokens silently as if I never revoked the sessions

[jmprieur]

@nataliahering : yes, this is a limitation of the B2C service. It takes some time.
@jennyf19 to keep me honest.

[nataliahering]

@jmprieur For the revoke session case, how can I then as an admin ensure that a user gets blocked from starting the app while the refresh token that he got from the very first (interactive) sign in is still valid? I was planning to acquire token silently upon every startup (after the first interactive sign in).

[nataliahering]

For the user claims, can we in the acquire token silently still call the custom API if we use custom policies? So that at least if in step 2 instead of updating some of the default claims in b2c, we update some of the custom logic behind our custom claims, we can ensure that in step 3 we get the updated information.
I will also try this one out of course, just raising the concern here in case you have some more insights on what I should do with the custom policies

[jmprieur]

@nataliahering :

@jmprieur For the revoke session case, how can I then as an admin ensure that a user gets blocked from starting the app while the refresh token that he got from the very first (interactive) sign in is still valid? I was planning to acquire token silently upon every startup (after the first interactive sign in).

• the fact for a session to have been revoked is something that should be handled by the web API for which the token is requested.
• If you want to be sure to refresh a token when you start the client app, you could do an AcquireTokenSilent, with ForceRefresh(true) but mind you about the performance ...
• Usually, you'd want to do AcquireTokenSilent before AcquireTokenInteractive, btw (assuming you have your token cache serialzed)

For the user claims, can we in the acquire token silently still call the custom API if we use custom policies? So that at least if in step 2 instead of updating some of the default claims in b2c, we update some of the custom logic behind our custom claims, we can ensure that in step 3 we get the updated information.

• I don't understand the question :). Did you try app.GetAccountsAsync(policy) ?

cc: @jennyf19 and @nickgmicrosoft for the second question if they understand better than me.

[nataliahering]

@jmprieur I want to be able to call a custom API, not only upon interactive sign in /sign up (which can be easily achieved by following the steps of the custom policies here https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-rest-api-claims-exchange), but also when I call AcquireTokenSilent, even with ForceRefresh(true). This is necessary, because some updates in my custom logic happen after the user has interactively signed up/in and before the refresh token has expired so that he has to again interactive sign in.

I saw this post
https://stackoverflow.com/questions/49549317/azure-ad-b2c-refresh-token-refresh-claims-via-rest-identity-experience-framew/49603509#49603509
which describes this issue, but it doesn't seem to work for the authorization code flow (the users in the comment also explain that they get an error if they follow the suggested answer).

Regarding the revokation of the refresh token, if I revoke the user's session from the portal and then call AcquireTokenSilent, with ForceRefresh(true) I can still get an access token. How do I need to revoke the user's refresh tokens in order to not get an access token in the next AcquireTokenSilent?

Many thanks