Chrome 80 is on its way, and it might change your cookies. Are you ready?

If you’re like me and have been riding the tech innovation wave for years, you’re probably an avid user of Google Chrome. Many modern day employees are, and who wouldn't be? It’s fast, it syncs data—it’s awesome!

With all this love for Chrome, it’s wise to be aware of the recent changes to the browser and how they might affect you. We’re writing this blog to alert users like yourself to some big changes in the next update, Chrome 80. This update will not only change how your cookies move around, but could alter how your favorite cloud software works, so you’ll want to be sure that all of your software providers are ready for this change as well.

Let’s take a deep dive into what’s changing.

An abridged history of cookies

To start, let’s talk about cookies. Cookies are small bits of information your browser stores about your interaction with certain sites or services. Each cookie is associated with a domain. Cookies are designed to give you a persistent state across sites, and as you traverse the internet, these cookies will often make their way from one site to another. This movement across sites can be classified as movement between first-party and third-party sites. Let’s delve into what these different sites mean and how they affect cookies.

First-party sites are those that have a web address that matches the current address in your address bar. So when the domain associated with a cookie matches the domain in the address bar of your browser, it's said to be a first-party site. For example, 1.okta.com to 1.okta.com.

Third-party sites are ones where the value of the address bar does not match the domain associated with the cookie. For example okta.com and example.com. While sending cookies to unrelated sites may sound odd, I assure you it’s quite common; especially in 3rd party widgets, advertising, and content sharing. It’s also common that malicious actors take advantage of this via cross-site request forgery (CSRF) attacks, exploiting victims via cookies to execute unwanted actions such as funds transfers or altering an email address.

If this is such a problem, why isn't anyone doing anything about it?

The short answer: they are. And this change is coming to our favorite browser, good ol’ Chrome. But before we detail Chrome, let’s talk about the root of this change. It initially came in the form of an additional cookie attribute called SameSite, which is a key-value pair developers can add to the cookies their sites are creating. SameSite allows you to state your intended use of the cookies. With the SameSite attribute, you have 3 configurable options, Strict, Lax and None.

Strict: Sets the SameSite cookie attribute to strict limits in terms of where the cookie will be sent. Specifically, it limits the sites to only the same sites you are currently visiting. This is great when you have pages that carry out functions such as password resets or other protected service functions.

Lax: Setting the SameSite attribute to Lax allows cookies to go to both first-party and third-party sites using safe HTTP methods (rfc6265bis). What this means is that if you were on a page (e.g., site1) and a cookie was created for you, then you click from another page (e.g., site2) that takes you back to site1, then cookies would be sent. This is great in situations where you need to simply view content such as advertising or SAML flows.

While Strict and Lax can cover most use cases, they do not cover every scenario under the sun. None allows you to state that if a cookie is not same-site (neither Strict nor Lax), it needs to be cross-site, but only when using the secure option, e.g., HTTPS.

Use of SameSite

Since its addition, the SameSite attribute has been optional, and in its absence the default behavior was to treat cookies as cross site cookies, or None. To help protect users, Google is making a change to Chrome that will add some new, default functionality to the browser. First off, it’s adding functionality to Chrome that will take advantage of the SameSite cookie attribute. Once the functionality is part of Chrome in February 2020, all cookies without an explicit SameSite value will automatically be treated as SameSite = Lax. What this means for you is that if you do not set this attribute on your site, Google Chrome will be setting it for you, possibly changing the functionality of your site.

Chrome 80, Okta and other flows

Okta has taken the necessary steps to ensure that all Okta cookies are compatible with the change that Chrome 80 brings. In essence, cookies created in Okta are automatically set to SameSite = None. This covers cookies generated by Okta in both IDP-initiated, SP-initiated and inbound SAML flows. This does not mean every system that integrates with Okta will carry that same update.

This change does not only pertain to the Chrome browser, as other browsers such as Firefox and Microsoft Edge have this functionality as optional (i.e., opt-in). To ensure that you are not adversely affected by this change, ensure that your applications state their intended cookie usage. Otherwise, the Chrome 80 browser will set it for you, and may result in some unexpected results.

For details and more technical assistance on how Okta is responding to the Chrome 80 change, check out the Okta Support FAQ page How Chrome 80 Update for "SameSite by default" Potentially Impacts Your Okta Environment.

For more general details on Chrome 80, check out the developer documentation from the Open Source Browser Project page.