Table of Contents

• How are Trusted Origins different from iFrame embedding in Customizations?
• What happens if the Okta org has both types of embedding enabled?
• How to prepare to switch iFrames from Customizations to Trusted Origins?
• What are the known issues with Trusted Origins for iFrame embedding?

How are Trusted Origins different from iFrame embedding in Customizations?

The iFrame embedding in Customizations uses x-frame-options. Trusted Origins use the Content Security Policy (CSP) frame-ancestors directive. The CSP frame-ancestors directive specifies which parent pages may embed a page using an iFrame based on the following enablement statuses.

• Not enabled: Okta uses the SAMEORIGIN directive or CSP frame-ancestors and restricts iFrame embedding to the same origin as the Okta org.
• Enabled: Okta does not send the SAMEORIGIN header, and any origin can embed Okta resources in an iFrame.

What happens if the Okta org has both types of embedding enabled?

If the org has iFrame embedding enabled using both the Customizations option and the Trusted Origins method, Okta sends CSP frame-ancestors in the report-only header as a precaution. This means that the iFrames configured through Trusted Origins stay in monitoring mode unless an administrator disables iFrame embedding under Customizations.

How to prepare to switch iFrames from Customizations to Trusted Origins?

In a test org, configure all origins requiring iFrame embedding using Trusted Origins. Disable the Customizations option and ensure that the newly configured iFrames function properly. Repeat the same procedure in the production org.

What are the known issues with Trusted Origins for iFrame embedding?

• Third-party integrated URLs fail to work with iFrame embedding if the third-party application does not allow it. For example, if a Salesforce instance in the Okta org does not allow iFrame embedding, embedding the application in an iFrame using Trusted Origins fails.

• The third-party application must also support iFrame embedding. If it relies on cookies for session management, the cookie must be Secure and have SameSite=None to work in Google Chrome.

• Enrolling in or verifying with a WebAuthn factor fails when this feature is enabled. Hosting the iFrame in a domain that is different from the org domain causes the WebAuthn authentication to fail because WebAuthn blocks authentication across different domains. To allow the WebAuthn authentication to authenticate users, edit the HTML attribute of the iFrame code with the following setting:

  <iframe src="..." allow="publickey-credentials-get *" />

  This displays the iFrame in a domain that is different from the org domain. The * represents the non-Okta web page domain.

• End users enrolling in an authenticator from the embedded End-User Dashboard > Settings exit the iFrame. The enrollment happens outside the iFrame.

• If an embedding application has its own CSP, modify it appropriately to allow the Okta org in its frame-src directive.

• If the browser does not support CSP, it defaults to x-frame-options. Check the browser documentation to find out whether it supports CSP.

• If an embedded Okta Access Gateway (OAG) resource has x-frame-options set to SAMEORIGIN, the resource fails to appear in the iFrame. This fails even when the user successfully signs in.

• The resource fails to display properly in an iFrame if the CSP header is missing.

• Adding too many trusted origins causes the HTTP header size to exceed the limit allowed by server software such as NGINX. In such cases, update the default server limits or reduce the number of trusted origins in Okta.

Related References

• Trusted Origins for iFrame embedding