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!

I understand you are asking how to securely propagate authentication from App A to App B, whether SSO is feasible in an iframe context given modern browser restrictions, what the recommended architecture is for this use case, and which patterns to avoid.

Root Cause:

The primary challenge is that when App B is embedded in an iframe on a different domain, its requests to Auth0 are treated as third-party requests. Browsers block third-party cookies by default, which prevents the SSO session cookie from being accessible to the iframe, causing silent authentication to fail.

Solution:

Do not propagate tokens from App A to App B. Instead, App B must independently and silently acquire its own token from Auth0 by leveraging the central SSO session created when the user logged into App A. This is achieved through Silent Authentication, a standard OIDC protocol mechanism that Auth0 supports.

Addressing browser restrictions with a Custom Domain:

Yes, SSO in an iframe is entirely feasible, but you must address third-party cookie blocking. The official and robust solution is to use Auth0’s Custom Domains feature. By configuring a custom domain (for example, 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.

Recommended architecture:

Follow these steps to implement secure cross-domain SSO with iframes:

  1. Register both applications. Register both App A and App B as separate applications within your Auth0 Dashboard.

  2. User authenticates to App A. The user navigates to App A and is redirected to the Auth0 Universal Login page. 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. App B requests a token silently. When the user accesses the page in App A containing the iframe, App B loads. App B’s code then uses an Auth0 SDK (for example, the Auth0 SPA JS SDK) to call a method like getTokenSilently().

  4. Hidden iframe handles the session check. The SDK creates a hidden, non-interactive iframe that points to Auth0’s /authorize endpoint with the prompt=none parameter. This iframe operates transparently to the user.

  5. Auth0 issues tokens for App B. 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. Handle logout gracefully. The iframed app should check frequently (for example, upon page reload) whether the session is still active. If the session has ended, clear the local storage and prompt the user to re-authenticate through App A.

Patterns to avoid:

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

  • Do not use Auth0 login pages inside an iframe. Auth0 discourages embedding the Auth0 login page (or any identity provider login page) inside an iframe due to inherent security risks. The parent application must always orchestrate the primary login; the iframe should never handle initial authentication.

  • Do not send tokens between applications via URL parameters or client-side mechanisms. App B must request its own token directly from Auth0, not receive it from App A through URL parameters, query strings, or any other client-side channel.

  • Account for silent authentication failures. Silent authentication may fail if Auth0 cannot find a valid session for the user. You must be prepared to fall back to regular authentication on App A when getTokenSilently() fails, and prompt the user to log in again if necessary.

I hope this clear things up, let us know if you have any other questions!
Kind regards,
Remus

5

Hi, thanks for the detailed explanation — this is really helpful.

I just want to clarify a couple of assumptions to make sure I’m understanding your proposed approach correctly:

  • Does your solution imply that both App A and App B need to be migrated to Auth0 and act as separate clients there?

  • Are you assuming that both applications live under the same parent domain (e.g. a.company.com and b.company.com) so that the custom domain (e.g. login.company.com) is considered same-site?

In our current setup, the two applications are hosted on completely different domains (e.g. xyz.com and abc.com), which is why I want to double-check whether the silent authentication approach you described would still work in this scenario, especially given third-party cookie restrictions in iframes.

Would you recommend a different approach for this case?

Thanks again!

6

Hi @rdechiara,

You are asking whether both App A and App B must be migrated to Auth0 as separate clients, and whether they must share a parent domain for Single Sign-On (SSO) to work with a custom domain.

Solution:

Yes, both applications must be registered as separate Auth0 Applications within your tenant. This is the recommended and most secure approach for token issuance and seamless SSO, particularly for iframed applications. Registering them separately reduces complexity and ensures proper token management.

Regarding domain requirements:

No, your applications do not need to share a parent domain. The architecture works even when App A and App B are hosted on completely different domains (for example, xyz.com and abc.com). Here is how it works:

Custom Domain as a trusted first-party context:

When you configure a Custom Domain (for example, login.company.com), both the authentication process and the SSO session cookie are anchored to that single domain. The browser treats this Custom Domain as a secure, first-party context, regardless of where your applications are actually hosted.

Silent authentication through a hidden iframe:

During silent authentication, the Auth0 SDK initiates the flow from within a hidden iframe that points directly to your Custom Domain (login.company.com). This iframe has first-party access to the SSO session cookie stored on that domain. The browser’s same-site cookie policy allows the iframe to read the cookie because the iframe origin matches the cookie’s domain.

Cross-domain SSO becomes transparent:

Because the session check happens entirely within the Custom Domain context, the original domains of App A and App B are irrelevant to the security validation. Auth0 securely bypasses the cross-domain problem by keeping the critical session check self-contained on your Custom Domain. This enables seamless SSO regardless of where your applications are hosted.

Thank you and if you have other questions please let me know!
Best regards,
Remus

7

I’ve started working on a proof of concept for Application B and have successfully integrated Auth0 into the SPA frontend. The authentication flow works as expected: after signing in, the user is redirected to the dashboard.

At this point, API calls are returning 401 responses, which makes sense because the authorization server is now Auth0 rather than our previous backend.

I’m now focusing on the Django REST backend. From what I understand, I need to configure the API to validate the JWTs issued by Auth0 (using JWKs), so that incoming requests can be properly authenticated and the endpoints protected.

I’m currently following this guide: https://auth0.com/docs/quickstart/backend/django/interactive. However, I’ve run into a couple of issues:

  • In step 2, the list of dependencies appears to be missing or blank.

  • I’m also unsure whether registering just the SPA as an application in Auth0 is sufficient, or if I also need to explicitly register my API (i.e., define it as an API resource with an identifier/audience) in order to properly validate tokens on the backend.

Could you please clarify these points?

8

Hi @rdechiara,

I understand you are integrating Auth0 with a Django REST backend and need clarification on the required dependencies and whether you must register your API in Auth0.

Solution:

The dependencies were not clearly listed in the quickstart documentation. Here is the complete list of packages you need to add to your requirements.txt file:

cryptography~=2.8
django~=2.2.7
djangorestframework~=3.10.31
django-cors-headers~=3.1.1
drf-jwt~=1.13.3
pyjwt~=1.7.1
requests~=2.22.0

Regarding API registration in Auth0:

Yes, you must explicitly register your API in the Auth0 Dashboard. This is required for two critical reasons:

  1. Audience definition. Registering your API defines it as a resource server and assigns it a unique identifier called the audience. When your Single Page Application (SPA) requests an access token, it specifies this audience to indicate which API the token is intended for.

  2. Token validation. Your Django backend validates every JWT access token it receives from clients. During validation, it checks that the aud (audience) claim in the token matches the identifier of your registered API. This ensures the token was issued for your API and not for another resource, preventing unauthorized token reuse.

The complete process—from registering your API in the Auth0 Dashboard to validating tokens in your Django application—is documented in the Django API: Authorization tutorial (see Sources below).

Sources:

I hope this clears things up and please let me know if you have any other questions.
Kind regards,
Remus