What is happening?

Google Chrome is phasing out the use of third-party cookies. Third-party cookies are cookies that are accessible by websites that are on a domain that’s different from the domain that owns the cookies.

The phasing out of third-party cookies is in progress. Google has begun testing blocking third-party cookies with 1% of Chrome users in Q1 of this year. Third-party cookies are expected to be phased out completely for all users starting in Q1 of 2025 according to Google’s Privacy Sandbox Timeline

Useful references to understand this issue

  • Google shares update on next step toward phasing out third-party cookies in Chrome - https://blog.google/products/chrome/privacy-sandbox-tracking-protection
  • Saying goodbye to third-party cookies in 2024 MDN Blog - https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies

How does this impact you?

Any functionality that relies on grabbing cookies from the “parent application” may be at risk of not functioning as expected.

For example: If your application is iframed into Bullhorn and relies on information from Bullhorn ATS cookies, depending on the needed information your application may fail.

How to ensure that our applications run uninterrupted?

Test all known workflows by blocking third-party cookies via Chrome settings

  • Test known login and SSO workflows
  • Ensure that your application that is iframed into Bullhorn ATS works as expected with third-party cookies settings set to block

Alternatives to using third-party cookies

Bullhorn identity

Documentation Utilizing Bullhorn identity, a partner can gain an authorization code for the logged in user which can be used in conjunction with their clientId and client secret to receive a valid JWT token for making REST API requests to Bullhorn.

Section Already logged in users in the document above gives instruction on how to skip the first few steps of the process for users that are already logged into the ATS and navigating to iframed content.

Custom component

Documentation Utilizing a custom component, a partner can gain an authorization code for the logged in user that can be used in conjunction with their clientId and client secret to receive a valid JWT token for making REST API requests to Bullhorn

Security Recommendation

  • Keep your application and Bullhorn secure, we recommend that no clientId, client secret or JWT/BhRest token be stored in Javascript or frontend code.
  • Middleware or API services should be implemented to accept an authorization code provided by Bullhorn by one of the methods above.
    • Middleware should be responsible for retrieving properly secured clientId and client secret, combining these with the supplied authorization code to retrieve a valid JWT for use in calls to Bullhorn
Reference: [Check the impact of the third-party cookie phaseout on your sign-in workflows Privacy Sandbox Google for Developers](https://developers.google.com/privacy-sandbox/3pcd/guides/identity)