Third-party cookies are often used by advertisers to track user behavior across multiple websites, allowing them to build detailed profiles of users' online activities. This has raised significant privacy concerns, as many users are uncomfortable with the idea of being constantly monitored and profiled without their explicit consent. Blocking third-party cookies is a way of preventing such tracking.

Beginning from version 13.1, Safari blocks third-party cookies by default, disrupting Okta functionality in certain flows. Firefox and other browsers are also in the process of rolling out similar changes. Read more about Google’s plans here.
 

• Third Party Cookies

This issue will not affect an organization if the Okta-hosted sign-in page is used and the app does not call the Sessions API from the browser. Customers who host their own sign-in functionality may be affected.

When a self-hosted application makes a call to Okta that relies on an Okta Session Cookie being included in the HTTP request, the browser blocks the cookie from reaching Okta because the request made to Okta is in a third-party context. The specific functionality that is affected is session management, as well as token renewal in the OAuth 2.0 implicit flow and PKCE flow.

What are the potential impacts?

Third party cookie blocking can impact the following Okta use cases:

Session Management in Customer-built Applications

If the sign-in page is self-hosted, using a self-hosted instance of the Okta Sign-In Widget, and relies on JavaScript running in the user's browser to make calls to Okta for session management handling, functionality can be broken by the browser's blocking of third-party cookies.

Okta session cookies that accompany XHR calls to Okta API endpoints like /sessions/me and /users/me are blocked by the browser because they are sent to a different domain than the one the user is on. Okta session cookies never get through to Okta, and Okta cannot complete the request.

The result is that Okta returns 403 Forbidden errors to the user or that the application repeatedly directs users back to the sign-in page.

Specifically, this problem affects certain methods of the Okta Auth JavaScript SDK. The Okta Sign-In Widget uses the affected Okta Auth JavaScript SDK methods internally. Any customer-developed code that directly makes XHR calls to the Okta Sessions API is also affected. Refer to Third Party Cookies Utilized by the Sign-in Widget for more details.
 

Token Renewal in Customer-built Single Page Applications using the OAuth 2.0 Implicit flow

If the integration uses the OAuth 2.0 implicit flow or PKCE flow to handle token renewal (which typically occurs in the context of a SPA that uses the implicit flow or PKCE flow and is not utilizing Refresh Tokens), the browser can block Okta session cookies from being sent, so that token renewal is never successfully completed.

The result is that ID tokens and access tokens expire without being renewed, and users are prompted to sign in more frequently, with the frequency determined by the token expiry time.
 

Certain Pages Not Displayed in Okta

An example is when trying to access View Setup instructions for a SAML application in Incognito mode

One option is the use of a custom domain in Okta to effectively make the Okta URL and application server on the same domain from the browser’s perspective. This would result in Okta session cookies having a first-party context. Calls to Okta become calls within the same site, and browser third-party cookie blocking is no longer triggered.

For example, if the original Okta org is companyname.okta.com, and the application server is app.companyname.com, using the custom URL domain feature can give the Okta org a new URL like login.companyname.com.

Another option is to update the flow to utilize refresh tokens. This allows for refreshing the current token being used to access secure resources without prompting the user to re-authenticate. Be sure to enable the “Refresh Token” Grant on the application within the Admin console, and follow the sample request in the above link to ensure the required query parameters are present to successfully refresh the access token. Consider also that PKCE flow can utilize refresh token to perform token renewal.

NOTE: External Identity Providers will also need to update their Assertion Consumer Service (ACS) URL to match the one from the SAML IDP configuration in Okta in order for the users to authenticate through the custom domain and have the necessary cookie.

Related References

• Third Party Cookies Utilized by the Sign-in Widget
• Okta Developer Blog Post - How to Prepare Your Self-Hosted Okta Sign-in Widget to Work without Third-Party Cookies
• Deprecation of 3rd Party Cookies in Google Chrome
• Okta Developer Blog Post - The End of Third-Party Cookies
• Deprecating 3rd party cookies for Chrome users
• Preparing for the end of third-party cookies
• Session cookies via our APIs
• Embedded Sign-in Widget deployment model
• Implement authorization by grant type