SSO between two web applications where on is embedded in the other in an iframe

Get Help
,
1

Hi everyone,

I’m looking for guidance on securely implementing SSO between two web applications where one app is embedded inside the other via an iframe.

Here’s our scenario:

  • We have a parent web application (App A)

  • A second web application (App B) is embedded within App A using an iframe

  • Currently, we are not using Auth0 — authentication is handled via a credentials grant flow

  • Our goal is that if a user authenticates in App A, they should be able to access App B within the iframe without needing to sign in again

We’re exploring whether Auth0 could help us achieve this, but we’re unsure about the best approach given the iframe setup.

Some of the concerns and questions we have:

  • How to securely propagate authentication from App A to App B

  • Whether SSO is feasible in an iframe context, especially with modern browser restrictions (e.g., third-party cookies)

  • If moving to Auth0, what would be the recommended flow or architecture for this use case

  • What patterns to avoid to ensure we don’t expose tokens or introduce security risks

Has anyone implemented something similar or can share best practices for this kind of setup? Any pointers, examples, or documentation would be really helpful.

Thanks in advance!

3

Hi @rdechiara,

Welcome to the Auth0 Community!

Please allow me some time to further investigate this and I will come back with an answer as soon as possible!

Thank you!
Best regards,
Remus

4

Hi @rdechiara,

Welcome to the Auth0 Community!

In Auth0 you can implement your desired use case and solve this type challenge securely and efficiently as well.

It is not recommended to propagate authentication. The secure and correct pattern is for App B to independently and silently acquire its own token from Auth0 . It does this by leveraging the central SSO session that was created when the user logged into App A. This is achieved through a mechanism called Silent Authentication , which is a standard part of the OIDC protocol that Auth0 supports.

Yes, it is entirely feasible , but you must address the primary browser restriction: the blocking of third-party cookies. When App B (e.g., app-b.com ) is in an iframe, its request to Auth0’s domain (e.g., your-tenant.auth0.com ) is considered a “third-party” context. The SSO session cookie set by Auth0 will be treated as a third-party cookie and blocked by the browser, causing silent authentication to fail.

The official and robust solution is to use Auth0’s Custom Domains feature. By setting up a custom domain (e.g., login.your-company.com ), you make the Auth0 authentication endpoint appear to be on the same primary domain as your applications. This transforms the SSO cookie into a “first-party” cookie, which browsers do not block.

Here is the recommended, high-level architecture for your scenario:

  1. Registration: Register both App A and App B as separate applications within your Auth0 dashboard.

  2. User Authentication: The user navigates to App A and is redirected to the Auth0 Universal Login page to sign in. Upon successful authentication, Auth0 sets a secure, encrypted SSO session cookie on your custom domain and redirects the user back to App A with their tokens.

  3. Silent Authentication (App B): When the user accesses the page in App A containing the iframe, the embedded App B loads. App B’s code then uses an Auth0 SDK (e.g., the Auth0 SPA JS SDK ) to call a method like getTokenSilently() .

  4. The Hidden iFrame: The SDK handles the complexity for you. It briefly creates a hidden, non-interactive iframe that points to Auth0’s /authorize endpoint with the prompt=none parameter.

  5. Seamless SSO: Auth0 checks for the first-party SSO cookie, finds the active session, and issues a new set of tokens specifically for App B without any user interaction. The SDK delivers these tokens to your App B code.

  6. Logout: The iframed app should nicely handle logout, by frequently (e.g. upon page reload) checking whether the session is still active and if not clear the local storage

To prevent security risks, you must avoid the following anti-patterns:

  • Auth0 discourages using the Auth0 (or any identity provider) login pages inside an iframe due to inherent security risks with the approach, so don’t have the iframe handle the initial login, the parent should always orchestrate the primary login.

  • You should not send tokens from App A to App B via URL parameters or any other client-side mechanism. The application should get its token directly from Auth0.

  • While you can rely on silent authentication, you need to account for the possible failures (i.e., when Auth0 can’t find a valid session for the user and needs to prompt for authentication) and be prepared to do a regular authentication on app A