What's the wrong with making the ApplicationCookie SameSite=Strict in IdentityServer4?

Viewed 682

I'm developing an IdP with IdentityServer4, and everything works fine, but now from the security perspective, I want to make it as secure as I can; So I made all cookies SameSite as Strict, and after that, I got HTTP error code 400 in situation below:

  • User TestUser opens the client app A
  • TestUser signed in to the client app A
  • TestUser signed out from the client app A
  • TestUser is trying to log into the client app A again (he/she hits the login button in the client app A)
  • at this point, the TestUser redirects to my IdP's login page but receives only the HTTP 400 error code and no other details are displayed to check the status.

And here are my cookies: My cookies

And my configuration:

// Identity Cookie (Authentication cookie)
services.ConfigureApplicationCookie(options =>
{
    // options.Cookie.Name = ..... 
    options.Cookie.HttpOnly = true;
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    options.Cookie.SameSite = SameSiteMode.Strict;  // <<<<<<<<<<<<<<<<<<<<<<< 
    options.SlidingExpiration = false;

    // without expire time ~> session cookie. destroy after closing the browser
    // options.ExpireTimeSpan = TimeSpan.FromSeconds(10000);
    // options.Cookie.Expiration = TimeSpan.FromSeconds(1000);
});

And as you can see, .AspNetCore.Identity.Application (application cookie) cookie is set to be SameSite=Strict. If the SameSite set to be Lax, everything works fine, but what is the matter with SameSite=Strictin this scenario?

1 Answers

In short because IdentityServer4 (and any OpenID Connect provider for that matter) relies on HTTP redirects between different sites and cookie authentication for the OIDC endpoints themselves. SameSite=Strict is inherently incompatible with the duties the primary authentication cookie has to perform unless all clients live within the same site (according to the SameSite rules of what constitutes "same site").

When you move from client.x.com -> idp.y.com that's a non-SameSite navigation so any Strict cookies for idp.y.com will be blocked by the browser.

Having SameSite=None is OK however provided you have comprehensive CSRF protection on all of your cookie-secured endpoints. Note that idsrv.session must be SameSite=None as it is used by the session monitoring endpoint which is loaded inside an iframe within the client application.

You can see this behaviour if you inspect the request cookies in the developer tools - it will indicate blocked cookies with a warning triangle and explain the reason in the tooltip.

Related