[Feature Request] In confidential client apps, TokenCacheNotificationArgs or ITokenCache should tell the cache key to use

Is your feature request related to a problem? Please describe. In Web apps and Web APIs (confidential client applications) there should be one cache per user. The serialization implementation of the user token cache and the app token cache only differ by the key. It’s tempting to provide a single serialization implementation (Like PR https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/pull/172), however, the issue is that today the serializer has a member telling if the token cache is an app token cache or a user token cache (See _isAppTokenCache in https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/12e59804a307e01e8fe2e94562bef3aee272fbb1/Microsoft.Identity.Web/TokenCacheProviders/MsalAbstractTokenCacheProvider.cs#L27). From this member, the cache key is computed (from the appId or user ID)

There are also other complexities in the guest scenario that the oid/tid is not the home oid/tid, and therefore there is a work around to apply in the scenario: See https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/12e59804a307e01e8fe2e94562bef3aee272fbb1/Microsoft.Identity.Web/TokenAcquisition.cs#L276-L281

Describe the solution you’d like

• If TokenCacheNotificationArgs or ITokenCache could provide the information about whether the cache is an app token cache or a user token cache, a common implementation could be used to serialize the caches.
• Even better if TokenCacheNotificationArgs could provide a property proposing a cache key this would be more straiforward for application developers.

This would also be good for the OBO scenario as there would be no risk of using the wrong token cache key. cc: @jennyf19

Describe alternatives you’ve considered In Microsoft.Identity.Web, there is common implementation for token cache serializers in a given technology, and then it’s derived (thin wrapper) for user token cache and app token cache

@MarkZuber @henrik-me @jennyf19 @bgavrilMS @trwalke : I’d like us to dicuss this, ASAP. There is an impact on Microsoft.Identity.Web

[jpda]

What about the case where there is no account before the cache is fetched? I have a background process that uses a user’s cached RTs for processing (very similar to, say, Microsoft Flow). A web flow signs in interactively, requesting offline_access + a graph scope, msal swaps auth_code, persists cache. The second process iterates through a list of users subscribed to updates, uses that cache to acquire new ATs silently, using login_hint because account is null.

I’m specifically using cache key here to mean the individual user’s cache, not a key within the user’s cache - e.g., the file name/table row identifier/etc.

There is not enough information (like login_hint) to derive a cache/identifier for that specific user exposed to AfterAccess or BeforeAccess. The TokenCacheNotificationArgs don’t include login_hint, even though it’s used in the AcquireTokenSilent call. Ideally I’d be able to have a single cache implementation that uses the information in TokenCacheNotificationArgs to determine which cache file/identifier to use. What is the option for this kind of scenario? Should there be a new CCA for each token request under a different user?

[MarkZuber]

The cache key in this case is not one per entry, but the key to be used to persist the entire cache. So the user token cache key would be the key to store all of a single user’s cache items. And the app token cache would be a key for the app itself. there would only be one of these for a particular app in the system but it differentiates the app key from the individual users. so this is still atomic against the individual at/rt/idt.