[Bug] MSAL Suggested cache key can create performance issues to due to over serialization

Which Version of MSAL are you using ? 4.16.1

Platform netcore

What authentication flow has the issue?

• Desktop / Mobile
  • Interactive
  • Integrated Windows Auth
  • Username Password
  • Device code flow (browserless)
• Web App
  • Authorization code
  • OBO
• Web API
  • OBO

Other? - please describe;

Is this a new or existing app? The app is in production, and I have started using MSAL instead of ADAL

Issue MSAL today in it’s suggested cache key makes following suggestions

• App context - ClientId+_AppTokenCache
• User context
  • Silent acquire - User account Id
  • OnBehalfOf exchange - Original token hash

However there are a couple of issues I see with this

Issue with App context cache

We recently onboarded MSAL (shifting away from ADAL) and during rollout we saw a trace (False) MSAL 4.16.1.0 MSAL.NetCore Microsoft Windows 10.0.14393 [07/18/2020 13:52:56] Serializing token cache with 4247 items.

This is happening because all app context tokens are being pushed into one single cache and since the tokens are tenantized, the moment a significant number of tenant hit the call the token cache just keeps on growing.

Issue with User context cache

For user context caches, since the cache key for OnBehalfOf exchange is the original token, as lots of callers make the call using unique clients (we have thousands of clients sending us potentially 100s of unique tokens per user) the token for same user gets cached over and over.

Solution which I propose

Based on the issues above, here is what I recommend as the token caches

• App context - ClientID+TenantId+_AppTokenCache
• User Context - ClientId + HomeAccountIdentifier (i.e. TenantID+UserId)

Additionally TokenCacheNotificationArgs should expose additional information like resourceId since for services which hit a lot of external services even tenant level cache might be too big and they might need to go granular.

[jmprieur]

Thanks @bgavrilMS and @RamjotSingh for these explanations.

• Given that MSAL.NET will anyway do what is needed (get only the OBO token with the given hash key of the incoming token from the cache once deserialized, whatever partition is realized by the serialization), it’s ok to have the homeAccountId + something as the suggested cache key as well for OBO. This would also help @TiagoBrenck in his scenario;
• I don’t think that there is FOCI for confidential client applications, and therefore using the clientID would not break it. Alternatively, @RamjotSingh you could have your storage (assuming you’ve been using a IDistributed cache of something). indexed by the ClientID outside the cache serialization methods. Would that be an option for you? I’m ok with adding the clientID. I just want to make sure that this won’t prevent future scenario.

Conclusion: proposing to go ahead with:

• App context - ClientID+TenantId+_AppTokenCache
• User Context - ClientId + HomeAccountIdentifier (i.e. TenantID+UserId)

@jennyf19 do you see any objections?

@bgavrilMS : would it make sense to also expose TenantId and ResourceId in the args? I would suggest raising another issue for this, @RamjotSingh.

[jmprieur]

Thanks @RamjotSingh, this is good feedback. @bgavrilMS @jennyf19 @henrik-me let’s discuss if we want to take this quickly (before many people use it, as it’s a breaking change) . @RamjotSingh : For the OBO case we have to take the token hash for security reason (CA claims might have changed. the home account id is not enough). But could also add the client ID.