Can the Host Application’s SSO Access Token Be Used for Superset Embedded Guest Token Generation?

[HemTech]

Bug description

We are new to Superset embedding and would appreciate some guidance on the recommended authentication approach for our use case.
Our current setup
We have:
• An Angular application that is our core operational application.
• Apache Superset for reporting and dashboards.
• Both applications use ZITADEL as the authentication/SSO provider.
• Both applications are configured under the same ZITADEL project.
Currently, we have a link in our Angular application that opens the Superset dashboard in a separate browser tab.
Because both applications use the same ZITADEL project/SSO configuration, users who are already authenticated in our Angular application can access Superset without being prompted to log in again. We achieved this with a minor customization to the authentication process in superset_config.py/superset_server.py.
Our goal: Embed Superset in Angular
We now want to embed Superset dashboards directly inside our Angular application using Superset’s embedded dashboard functionality.
From our understanding, embedding requires a guest token.
Our current flow is approximately:

1. The user logs into our Angular application using ZITADEL.
2. The Angular application has the user’s ZITADEL access token.
3. Our backend calls:
   POST /api/v1/security/login
   using a Superset service account to obtain a Superset access token.
4. We then call:
   GET /api/v1/security/csrf_token
   using the Superset access token to obtain a CSRF token.
5. We use this authentication context to generate the guest token for the embedded dashboard.
   This works, but it requires us to use a Superset service account.
   Our question
   Since the user is already authenticated in our host Angular application, and both Angular and Superset use the same ZITADEL SSO provider and project, is there a way to use the user’s existing ZITADEL access token directly with Superset’s authentication/guest-token flow?
   For example, could we pass the user’s ZITADEL access token to:
   /api/v1/security/csrf_token
   or otherwise exchange/validate the ZITADEL token with Superset and generate the required guest token?
   We tried passing the host application’s ZITADEL access token to the csrf_token endpoint, but Superset returned a Bad Request.
   What we are trying to avoid
   Ideally, we would like to avoid using a Superset service account solely for generating guest tokens.
   Our desired flow would be something like:
   User
   |
   | Login
   v
   ZITADEL
   |
   | Access Token
   v
   Angular Application
   |
   | Existing user authentication
   v
   Superset Embedded Dashboard
   Rather than:
   User
   |
   | Login
   v
   ZITADEL
   |
   v
   Angular Application
   |
   | Request guest token
   v
   Backend / Service Account
   |
   | Superset login
   v
   Superset Access Token
   |
   | CSRF Token
   v
   Guest Token
   |
   v
   Embedded Dashboard
   Questions
6. Is it possible to use the existing ZITADEL access token to authenticate/authorize the user with Superset for an embedded dashboard?
7. If not, is there a recommended way to integrate ZITADEL with Superset’s embedded dashboard authentication without using a Superset service account?
8. Is the guest-token approach intentionally designed to require a backend/service account, or are we missing an alternative authentication flow?
9. If using the same ZITADEL project/SSO provider does not help with embedded dashboards, could someone explain why? We understand that SSO and Superset guest-token authentication may be separate mechanisms, but we would like to understand the recommended architecture.
10. What would be the recommended architecture for securely embedding Superset dashboards into an Angular application where the user is already authenticated through ZITADEL?
    We would appreciate any guidance, examples, or references to the recommended approach.
    We are relatively new to Superset embedding, so apologies if we are misunderstanding how the authentication flow is intended to work.

Thank you!

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.11

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[TongyiDai]

The ZITADEL access token cannot be passed directly to Superset's /api/v1/security/csrf_token/ or /guest_token/ endpoints unless you have implemented an authentication manager that accepts that token as a Superset API credential. Sharing an upstream IdP does not make tokens issued for the Angular application's client/audience valid for Superset's REST API.

The Embedded SDK's intended trust boundary is backend-to-backend:

1. Angular authenticates the user with ZITADEL.
2. Your backend validates that ZITADEL token and applies your authorization policy.
3. Your backend obtains or creates a short-lived Superset guest token containing only the allowed dashboard resource and any RLS rules.
4. The frontend's fetchGuestToken callback receives that guest token; no Superset service credentials or signing secret reach the browser.

For issuing the token, Superset documents two supported choices:

• call POST /api/v1/security/guest_token/ as a Superset principal with can_grant_guest_token; or
• mint the guest JWT directly in your trusted backend using the configured GUEST_TOKEN_JWT_SECRET, algorithm, and matching audience.

The second option avoids logging in a service account for each request, but it does not remove the backend trust boundary—it replaces the service-account credential with a highly sensitive signing secret. Rotate/protect it accordingly. CSRF is not part of the direct-JWT path.

Do not send the ZITADEL token or Superset signing secret to the Embedded SDK. Use the ZITADEL identity only as authenticated input to your backend's dashboard/RLS decision, then issue a narrowly scoped, short-lived guest token.