[Feature Request] [L] TokenCacheNotificationArgs should expose the token expiry so that cache can optimize eviction (client_credentials only)

[jmprieur]

Is your feature request related to a problem? Please describe.
In token cache serializers for confidential client applications:

• for user flows, a RT is present in the cache and expiration cannot be determined, because tokens can be refreshed indefinitely.
• for AcquireTokenForClient however, there is no RT and the expiration of the cache can be computed as the max over the expiration of each access token in cache.

Describe the solution you'd like

In TokenCacheNotificationArgs add a new property of type SuggestedCacheExpiry, and of the same type as the expiry in the token cache times (I suppose this is DateTimeOffset, but this needs to be checked).

This property will be computed by items.Max(item => item.ExpiresOnUnixTimestamp), and then convert that to a UtcDateTime.

class TokenCacheNotificationArgs
{
 // Other members

 /// <Summary>
 /// Suggested value of the expiry, to help determining the cache eviction time. 
 // This value is <b>only</b> set on the <code>OnAfterAcces</code> delegate, on a cache write
 /// operation (that is when <code>args.HasStateChanged<code> is <code>true</code>) and when the cache write 
 /// is triggered from the <code>AcquireTokenForClient<code> method. In all other cases it's <code>null<code>, as there is a refresh token, and therefore the
 /// access tokens are refreshable.
 /// </Summary> 
 UtcDateTime? SuggestedCacheExpiry {get; private set;}

[jmprieur]

Requires a bit more spec:

The problem is that the cache corresponding to an incoming token into a web app contains several OBO tokens. What should be the expiry? How do the OBO token expire vs the incoming token ? (for which MSAL.NET does not know the expiry)

[bgavrilMS]

Needs more spec and a better understanding of OBO being able to refresh using RT or not.

[jmprieur]

Some things to consider:

• For client credential tokens don't have a refresh token, so they could expire. The expiry of the cache could be the max of the expiry of the tokens in the cache
• @jmprieur and @jennyf19 to propose an end to end (including what would happen in the app/Ms.Id.Web)

[jmprieur]

After doing an investigation it appears that given the access tokens can be refreshed for 90d, this does not make sense to expose an expiry.
Closing this issue.

[jmprieur]

@bgavrilMS: I've improved a bit the spec. do you want to check?
cc: @trwalke

[bgavrilMS]

Lgtm @jmprieur, thx for providing clarity. The return type should be nullable DateTimeOffset?, Since in most cases we will not set this.

Also, this property will only be set on OnAfterAccess callbacks.

[jmprieur]

@bgavrilMS : yes it should be nullable, but I don't think we have nullable in MSAL.NET?
Yes, in the InAfterAccess, and probably only when (args.HasStateChanged) ?

[bgavrilMS]

We have nullable structs since C# 3.0 or smth. The "nullable reference types" feature is C# 8.0 only, so MSAL can't use that.

Another way of achieving this is to set the expiry to max, via DateTimeOffset.MaxValue, but I feel that null is more descriptive.

[trwalke]

released in 4.34.0