Using cache key to partition the cache

I'm not sure we have that, so let me try to explain here. MSAL's token caching primitives are "store this blob" and "give me the blob back". This works fine for a public client application, which typically has <10 users logged in.

In a confidential client app, the number of users of that app is in the millions. This poses 2 problems:

a) memory pressure, i.e. you'll run out of memory since 1 entry (AT, RT, IDT and account metadata) is around 10KB.

b) token cache queries are O(n) and for large values of N we've seen searches taking 10+ seconds.

So the public client caching strategy is misleading / wrong and we need to try to correct it. To solve the above problems, the standard way is to use a distributed cache (e.g. Redis) and so there is a need for a KEY.

Usage in web site

• web site middlerware gets you an authorization code and ID token
• developer intercepts this and retrieves the home_account_id
• create a CCA and call GetAccount(home_account_id). CCA loads only the cache node associated with that home_account_id
• call AcquireTokenSilent(account) - CCA loads only the cache node associated with account.HomeAccountId
• or call AcquireTokenByAuthCode(auth_code) - and when the result come in, the CCA will save the tokens in based on response.home_account_id

Usage in S2S

• for S2S, there is no user involved. However, there could be millions of tenants involved and the problems above are still hit.
• AcquireTokenSilent() with no account will load the cache in node AppTokenCache_<tid> and will search for a token only in that cache partition
• AcquireTokenForClient() will go to ESTS and get a new token. Then it will save all in the cache node AppTokenCache_<tid>