Greetings @abhijit007 , I did a little resarch and have come up with some hints/guidance to help you:
Hey @abhijit007 — I did a little digging on this and pulled together some concrete guidance that should help you unblock things.
Thanks for sharing the details. What you’re seeing is actually consistent with how basic iframe embedding behaves for Databricks dashboards.
Why the SSO loop happens
When you use the generated iframe embed code, the dashboard is served from your workspace domain (for example, *.databricks.com), while your Databricks App runs on *.databricksapps.com. That cross-site setup relies on the browser accepting third-party cookies for Databricks domains so the login session can persist inside the iframe.
If third-party cookies are blocked, the iframe can’t retain the session, so it keeps re-prompting for SSO and you end up in the loop you’re seeing.
Quick checks to break the loop
First, confirm your workspace Security settings have embedding enabled and that the allowed domains include the exact app host pattern for Azure Apps (for example, *.azure.databricksapps.com). Wildcards are supported, but embedding must be explicitly allowed for the host where the iframe lives.
Second, make sure third-party cookies are enabled for Databricks in your browser (or add site exceptions for your workspace and login domains) and retry the App page. Basic embedding does require third-party cookies to be enabled.
One additional note: if your embedded dashboard includes a Genie space, there were recent rendering issues specific to embedded contexts. Those were addressed via a hotfix, but depending on deployment timing you could still see cases where query results don’t render. That would be a separate (and known) issue.
Recommended approach inside Databricks Apps
If you’re aiming for a seamless experience inside a Databricks App — no per-user login prompts and no dependency on third-party cookies — the recommended path is Embedding for external users (also called app-delegated embedding).
In this model, your app authenticates using a Service Principal and injects short-lived embed tokens for the dashboard. The iframe never does user SSO, which avoids the cookie problem entirely and works cleanly with Apps.
At a high level, the flow looks like this:
Create (or use the automatically managed) Service Principal and grant it the required data permissions for the dashboard via Unity Catalog. Publish the dashboard without embedded credentials so it runs under the SP’s scope when embedded. Keep your allowed domains configured for the App host as before. In the App, request and inject an embed token for the dashboard and refresh it before expiry.
The JS client supports automatic token refresh, and the same pattern can be implemented from Streamlit by serving a small HTML/JS component, for example:
import { DatabricksDashboard } from '@databricks/aibi-client'
// Initialize with automatic token refresh
const dashboard = new DatabricksDashboard({
instanceUrl: config.workspace_url,
workspaceId: config.workspace_id,
dashboardId: config.dashboard_id,
token: config.embed_token,
container: containerRef.current,
getNewToken: async () => {
const response = await fetch('/api/dashboard/embed-config')
const data = await response.json()
return data.embed_token
}
})
await dashboard.initialize()
When basic embedding is sufficient
If all viewers are internal and already have Databricks accounts, the generated iframe with SSO is still the simplest option — just keep in mind it depends on third-party cookies being enabled in the browser.
If it still fails
At that point, grab a HAR from the page load and a screenshot of the workspace embedding configuration. Those artifacts make it much easier for Support to pinpoint whether the issue is a cookie restriction or a policy block in the flow.
Hope this helps clarify what’s going on and gives you a clear path forward.
Cheers,
Louis
