Overview

Trusted Origins allows for sites to be embedded, like the Okta sign-in page or Okta-protected resources, in origins that are trusted. This prevents the site from being embedded in an untrusted site. It is more secure than the iFrame Embedding option in Customizations, which allows for embedding resources into any site.

This article provides answers to frequently asked questions about Trusted Origins for iFrame Embedding and presents the current Known Issue that might be faced when implementing and using Trusted Origins​​​​​​.

See Trusted Origins for iFrame embedding for more information.
 

Frequently Asked Questions

How are Trusted Origins different from iFrame embedding in Customizations?

The iFrame embedding in Customizations uses x-frame-options. Trusted Origins use the CSP frame-ancestors directive. This directive specifies which parent pages may embed a page using an iFrame.

• 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 if the 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 stays in monitoring mode unless iFrame embedding is disabled under Customizations.

 

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

In a test org, configure all origins where iFrame embedding is required using Trusted Origins. Disable the Customizations option and make sure that the newly configured iFrames are working properly. Then, repeat the same procedure in the production org.

 

Known Issues

• Third-party integrated URLs do not work with iFrame embedding if the third-party app does not allow it. For example, a Salesforce instance in the Okta org. If the Salesforce app does not allow iFrame embedding, it is not possible to embed the app in an iFrame using Trusted Origins.

• The third-party app 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 Chrome.

• Enrolling in or verifying with a WebAuthn factor does not work when this feature is enabled. Hosting the iFrame in a domain that is different from the org domain causes the WebAuthn authentication to fail. This is because WebAuthn is designed to block authentication across different domains. To allow the WebAuthn authentication to authenticate users, edit the HTML attribute of the iFrame code with this 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 are exited out of the iFrame. The enrollment happens outside the iFrame.

• If an embedding app 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 does not appear in the iFrame. This fails even when the user has successfully signed in.

• The resource is not displayed properly in an iFrame if the CSP header is missing.

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

Related References

• Trusted Origins for iFrame embedding