Authorised API access failing due to missing authentication cookie attribute on ASP.NET Core

ServiceStack Authentication
1

Our use case is to have a web api that is accessible from a web client on another domain with CORS configured appropriately and SameSite cookie policy set accordingly i.e.

API - somedomain1.com
Client - somedomain2.com

SameSite cookie policy - None (to allow auth cookies to be set when calling /auth from the client app)
API CORS - configured to have somedomain2.com explicitly added to whitelist (with appropriate headers/credentials options set)

It seems that in an AspNetCore 3.1 web api targeting Service Stack 5.9.0 there is a problem with the API not setting attributes of some cookies that will result in failure to authorise access to an invoked API operation after successful authentication has occurred. This is partly because of browsers now enforcing SameSite cookie policy that requires the “secure” cookie attribute to be set but ultimately is due to the service stack API not setting the secure attribute for these cookies when it seemingly should.

Essentially, the ss-opt and X-UAId cookies are blocked by the browser SameSite policy because they do not have the secure attribute applied to them (despite the SameSite=None attribute coming through in the header) which is a requirement for SameSite. Oddly, the ss-id and ss-pid cookies both have the SameSite and Secure attributes set correctly and are therefore accepted and stored by the browser. What this results in is both session cookies (ss-id & ss-pid) being sent back on subsequent api requests but, due to the missing ss-opt cookie (previously blocked by the browser), the “temp” ss-id cookie is used by default rather than the “permanent” ss-pid. The user’s “perm” session is not found resulting in a new “temp” session being created with the ss-id key and the IAuthSession.IsAuthenticated flag being false (by default).

As you can see from the below image of the returned headers, whilst the ss-id & ss-pid seem to have been processed correctly according to the above host config, ss-opt & X-UAId seem to have skipped applying the “UseSecureCookies = true” config setting.

SS_Browser_Response_Headers
SS_Browser_Response_Headers807Ă—329 30.6 KB

Our AppHost configuration is as follows:

  • UseSameSiteCookies = false (should result in “SameSite=None” attribute)
  • UseSecureCookies = true (should result in “secure” attribute)
  • AllowNonHttpOnlyCookies = false (Not relevant here but can this be renamed and inverted to UseHttpOnlyCookies = true? The current name is horrible.)
    SS_ApiHostConfig_AspNetCore

If there’s something I’m missing from our host config or my understanding isn’t complete of the behaviour then please let me know, otherwise this may be a bug.

Using:

  • netcoreapp3.1
  • ServiceStack 5.9.0
  • Chrome (v86.0.4240.111)/Edge (v86.0.622.51)

Turning off the following browser settings sees the process complete successfully:

2

This should be resolved from the latest v5.9.3+ that’s now available on MyGet.

Note in the latest version UseSameSiteCookies is a bool? where the null default results in samesite=lax.

I’ve deprecated AllowNonHttpOnlyCookies and have added UseHttpOnlyCookies=true as suggested.

With the latest changes you’ll only need to configure UseSameSiteCookies, e.g:

SetConfig(new HostConfig
{
    //UseHttpOnlyCookies = true, //already default
    //UseSecureCookies = true,   //already default
    UseSameSiteCookies = true,   //strict
});

Which after signing in on a secure site will result in Strict, Secure, HttpOnly Cookies:

image
image1377Ă—215 16 KB

This change is available from the latest v5.9.3+ that’s now available on MyGet.

1 Like
3

Thanks for that. I’ve confirmed that it is indeed fixed in v5.9.3. Any idea’s on a prospective release date?

P.s. I also appreciate indulging my borderline OCD for nomenclature and introducing UseHttpOnlyCookies. Much clearer and consistent. Thanks again.

4

Next release hopefully within 1-2 weeks.

1 Like