Silent flow returns stale token #2402
Comments
|
Hello @ShmuelCammebys, do you mind providing more context on your scenario? The log you shared here reports that the silent token request found a cached access token which was still valid:
And this seems to match the reported time of expiration here:
|
|
@mipetriu But when I decode the token, the expiration was 20 minutes before the request. Log: Token:
Error from Azure: {"code":401,"message":"IDX10223: Lifetime validation failed. The token is expired. ValidTo (UTC): '11\/28\/2024 06:40:38', Current time (UTC): '11\/28\/2024 07:01:27'."} |
|
@ShmuelCammebys - I see, the correlationID |
|
@mipetriu I do not. However the same issue occurred in the previous logs, so can't you use that correlation ID and those logs? Your original challenge to the 1st set of logs was that the logs claimed the expiration was later, but I showed using a 2nd set of logs that the claim is false, so your challenge was not a valid challenge, and the 1st logs should suffice. |
|
@ShmuelCammebys - apologies for the delay. In the more recent information you shared, I see that (1.) MSAL made a silent token request and returned a token which has a valid expiration time. I then see that (2.) your app makes a call a few seconds later and receives a response that the provided access token is expired. I asked about a full log for this test so that I could read back and check the request that initially retrieved this access token from the server. That way I could double-check this token acquisition with our service-side logs. From the information provided so far, is it possible that the app has different users/tenants/etc? Maybe a token returned with different search parameters was used between the shown silent token request and API request. I see some keychain items are being filtered out in the initial logs for that particular request because they have a different homeAccountId/authority/etc. |
|
@mipetriu There may be two accounts (two different emails). There are also two different client ids for the same authority. |
|
@ShmuelCammebys - Does this issue reproduce consistently? Is it possible to provide a complete log of the issue? Unfortunately, there is not enough information related to this issue for me to reach any conclusions. I can't trace the acquisition of the token that was expired, as the silent request logs provided seem to have result in a different token (likely due to a different user). |
|
@mipetriu still an issue, but only happens every 30 days or something. I had to introduce a workaround that whenever the user gets a 401, it forces an interactive authentication. I will try to get logs. |
|
@mipetriu we just downgraded from swiftui to uikit, because it is more reliable with the msal SDK. We will see if it has the same issue, but in testing it didn't. |
|
@mipetriu Here is an example of the problem. It authenticates with two separate resources. One, the user is not authorized, the other they are. For the one that they are, the token returned expires at 1737416909, but that is before the call was made. Times in the logs are UTC. |
The silent flow is returning a token with an expiration which is after the time the token was requested (dead out of box), so the APi is returning 401.
Logs (sanitized):
The text was updated successfully, but these errors were encountered: