In ASP.NET Core OIDC authentication, how can I set the cookie persistence based on custom data that was received from OIDC server?

I have read more than 20 OAuth and OIDC specs and I don't remember any guidance regarding the "Remember Me" feature of the authentication server. When a user authenticates in the OIDC server, he/she has the option to select the "Remember Me" checkbox. I have included a custom field in the /token response of the server:

public record TokenResponseModel(
    [property: JsonPropertyName("access_token")]
    string AccessToken,

    [property: JsonPropertyName("refresh_token")]
    string RefreshToken,

    [property: JsonPropertyName("id_token")]
    string IdToken,

    [property: JsonPropertyName("expires_in")]
    long ExpiresIn,

    // this is my custom field to let the client know
    // if their cookie needs to be persistent
    [property: JsonPropertyName("is_persistent")]
    bool IsPersistent,

    [property: JsonPropertyName("token_type")]
    string TokenType = "Bearer");

Now my question is how can I use this field in the client to make the cookie persistent or not?

builder.Services
    .AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
    })
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
    {
        // ...
    })
    .AddOpenIdConnect(OpenIdConnectDefaults.AuthenticationScheme, options =>
    {
        // ...
    });

STANDARDS

OAuth and OIDC specifications define behaviours before and after user authentication. The actual behaviour of user authentication itself is intentionally left open ended, to avoid limiting the ways in which users can sign in. So standards do not cover behaviours like Remember Me.

SESSIONS

In OAuth, your application session is decoupled from that of the authorization server:

• Some authorization servers, like Entra ID, might provide a Remember Me feature and then issue a long lived persistent cookie, so that the user does not have to reauthenticate when they next run an OIDC code flow.

• For your application, cookies enable access to your data. Keeping those cookies short-lived may fare best in security reviews, so that an attacker who intercepts one somehow cannot misuse it for long.

Personally I prefer non-persistent cookies in applications. Then, if the SSO cookie is persistent, the user can automatically sign in using SSO when they next run the app, so the user experience remains good.

EXTENDING COOKIE BEHAVIOUR

Having said that, the Microsoft behaviour is pretty extensible using events, though OIDC and cookie processing use completely different handlers. For example, you might be able to do something like this:

• Override the OpenIDConnect.OnTokenResponseReceived event, read your token response model and store a custom property against Request.HttpContext.Items.

• Override the Cookie.SigningIn event and update the cookie properties dynamically based on the Request.HttpContext.Items property.

CLAIMS

One final point. I would aim to issue a custom claim remember_me=true to the ID token. The app can then specialize its cookie behaviour based on that. It is a more standard option than adding a custom field to the token response.