FAQ

How does OpenID Connect work?

Please refer to How OpenID Connect Works.

Why is SameSite=None required?

OpenID Connect protocol exchanges are, in most use cases, cross-site. The OpenID provider and client are different sites. Furthermore, these flows do not involve users clicking navigation links from one site to the other. For example, some flows return a 200 HTTP response to the browser containing an HTML form and some JavaScript to automatically submit the form to the client via an HTTP Post. From the browser's perspective, the current site is the OpenID provider and destination site for the HTTP Post is the client.

If the OpenID session cookie is marked as SameSite=Strict, the browser won't include it with the OpenID response as the sites are different. If the OpenID session cookie is marked as SameSite=Lax, the browser still won't include it as this isn't considered a top-level navigation action. Specifically, the SameSite specification doesn't consider Post to be a safe HTTP method.

Consequently, the OpenID session cookie is created with a SameSite value of None.

However, if the MinimumSameSitePolicy for the application is set to SameSiteMode.Lax or SameSiteMode.Strict, the OpenID session cookie will take on this minimum setting. This will mean the browser won't return the cookie and the corresponding OpenID session state cannot be identified.

To circumvent these issues, the recommended approach is to set MinimumSameSitePolicy to SameSiteMode.None and to specify the SameSite setting on individual cookies as required.

builder.Services.Configure<CookiePolicyOptions>(options =>
{
  options.MinimumSameSitePolicy = SameSiteMode.None;
});

These considerations aren't specific to OpenID Connect. Other external authentication protocols potentially have the same issues.

No cookie, not just the OpenID session cookie, marked as Strict or Lax will be included with the HTTP Post. This may impact other aspects of the site's functionality.

It may be required to set the application cookie as SameSite=None as well.

builder.Services.ConfigureApplicationCookie(options =>
{
    options.Cookie.SameSite = SameSiteMode.None;
})

Are multi-server deployments supported?

Yes. However, for multi-server deployments not using sticky sessions or session affinity, OpenID session state and other cached information must be stored in a central repository rather than using the default implementation which is server memory.

The OpenID session store, and other caches all use IDistributedCache.

An IDistributedCache implementation with a central repository such as the RedisCache or SqlServerCache should be used.

For more information, refer to the article Distributed caching in ASP.NET Core.