-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] obo_cache_key_not_in_cache_error with SQL DistributedTokenCache #3808
Comments
Did you check the behaviour with 4.48? See #3736 for more information. |
I don't think we made any changes in 4.48 related to OBO |
@pmaytak - can you provide an opinion on this one please? |
Okay, I thought the changes in IByRefreshToken would also affect the OBO flow. |
@zmarkusdev Can you provide Verbose MSAL logs for one of those failed requests? I immediately don't see anything that may cause this behavior, so would need to look at detailed logs step-by-step. Based on those basic logs, it seems like no tokens are even loaded into MSAL from the distributed cache for that cache key. The cache key mentioned in the MSAL logs above is the same as the session key that you pass into the method, and same as the cache key in the SQL cache, right? Do I understand this - it works initially in the console app when you call AcquireToken, but then throws an error, even though the same session key is used, and the record is in the cache? |
Yes it is the same I got during the authentication dialog.
Exactly, I have the exact key in the database and it won't find it unfortunately, this is why I built in this additional Acquire. Here are the verbose logs, I hope you can work with this? Let me know if you need any more informations, thanks!
|
Any news regarding this problem, do you need any more informations or log outputs from this issue? |
We had a user report a similar behavior to this - also with SQL distributed cache, on .NET Fx runtime. Seems like the SQL client when retrieving data was throwing an exception which was swallowed, and MSAL perhaps got an empty result set. Can you try to get debug logs for the token cache. You can also set OnL2CacheFailure to retry the L2 call and/or add extra logs. |
@zmarkusdev Did you have a chance to try the above: extra logs and OnL2CacheFailure? |
Sorry for the late reply, I will check this 2 things this week and will deliver you more informations for troubleshooting. |
Hello!
Any solutions for this problem? |
This error doesn't come from MSAL. |
Documentation of my troubleshooting steps as per your recommendations:
Thanks for your help, we were able to fix this problem! |
Logs and network traces
Without logs or traces, it is unlikely that the team can investigate your issue. Capturing logs and network traces is described in Logging wiki.
Which version of MSAL.NET are you using?
MSAL.NET 4.47.2.0
Platform
.NET 4.6.1
What authentication flow has the issue?
Other?
Is this a new or existing app?
b. The app is in production, I haven't upgraded MSAL, but started seeing this issue.
Repro
Expected behavior
Using the OBO key acquired by my web application in another console application should work with the same database cache.
Actual behavior
I got the session key with AcquireTokenInLongRunningProcess in my web application and tried to use it in a background worker service (Console Application) to authenticate and send mails on behalf of the user. The log file reports, that the key cannot be found in the database cache, but the key is there and the connection string is the same as in the web application.
It works for a few days, if i refresh the key in the AggregateException handler. This code was added during troubleshooting of the problem.
Possible solution
Additional context / logs / screenshots / links to code
The text was updated successfully, but these errors were encountered: