Blocked third-party cookies disrupt Okta functionality in self-hosted applications that rely on an Okta session cookie in a third-party context. Configuring a custom domain in Okta or updating the authentication flow to utilize refresh tokens can resolve this issue. When browsers block third-party cookies, self-hosted applications experience broken session management, token renewal failures in the OAuth 2.0 implicit and Proof Key for Code Exchange (PKCE) flows, 403 Forbidden errors, and display issues for certain pages in Incognito mode.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Third-Party Cookies
• Custom Domains
• OAuth 2.0
• Session Management

This issue occurs when a self-hosted application makes a call to Okta that relies on an Okta session cookie included in the HTTP request. The browser blocks the cookie from reaching Okta because the application makes the request in a third-party context. This affects organizations that host their own sign-in functionality and call the Sessions API from the browser.

Blocked third-party cookies impact the following Okta use cases:

• Session Management in Self-Hosted Applications: If the sign-in page is self-hosted, uses a self-hosted instance of the Okta Sign-In Widget, and relies on JavaScript running in the browser to make calls to Okta for session management, the browser blocks the third-party cookies. The browser blocks Okta session cookies that accompany XMLHttpRequest (XHR) calls to Okta API endpoints like /sessions/me and /users/me because the application sends them to a different domain. Okta returns 403 Forbidden errors, or the application repeatedly directs users back to the sign-in page. This affects certain methods of the Okta Auth JavaScript SDK and any custom code making direct XHR calls to the Okta Sessions API.
• Token Renewal in Single Page Applications (SPA): If the integration uses the OAuth 2.0 implicit flow or PKCE flow to handle token renewal without utilizing refresh tokens, the browser prevents the application from sending Okta session cookies. Identity (ID) tokens and access tokens expire without renewal, and the application prompts users to sign in more frequently based on the token expiry time.
• Certain Pages Not Displayed in Okta: Specific pages fail to display correctly, such as when attempting to access the setup instructions for a Security Assertion Markup Language (SAML) application in Incognito mode.

How are blocked third-party cookies resolved in Okta?

Resolve third-party cookie blocking issues by configuring a custom domain in Okta to establish a first-party context or by updating the authentication flow to utilize refresh tokens.

• Configure a custom domain in Okta to place the Okta URL and the application server on the same domain from the browser's perspective. This establishes a first-party context for Okta session cookies, converting calls to Okta into same-site requests that bypass third-party cookie blocking. For example, if the original Okta org is <companyname.okta.com> and the application server is <app.companyname.com>, the custom URL domain feature provides a new URL like <login.companyname.com>.
• Update the authentication flow to utilize refresh tokens. This allows the application to refresh the current token for accessing secure resources without prompting the user to re-authenticate. Enable the Refresh Token grant on the application within the Okta Admin Console and ensure the required query parameters are present to successfully refresh the access token. The PKCE flow can also utilize refresh tokens to perform token renewal.

NOTE: External Identity Providers (IdPs) must update the Assertion Consumer Service (ACS) URL to match the SAML IdP configuration in Okta to allow users to authenticate through the custom domain and receive 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