Embed a Streamlit in Snowflake app for viewers with a Snowflake account¶

This tutorial embeds a Streamlit in Snowflake app in an external page for viewers who are already provisioned in Snowflake, typically through an external identity provider (IdP) such as Okta. The app runs as the viewer rather than as a shared service user, so each viewer sees only the data their own privileges allow.

If your viewers don’t have Snowflake accounts, follow Embed a Streamlit in Snowflake app for viewers without a Snowflake account instead. For background on the two models, see Embedding Streamlit in Snowflake apps in external pages.

The examples assume the app needs to query a schema the app owner’s role can’t reach directly, mydb.finance, accessible only to the finance role, which is held by the viewers who should see that data.

Before you begin¶

This model has two additional prerequisites:

• Your IdP must be configured as a Snowflake External OAuth integration, so that Snowflake accepts tokens it issues. For setup instructions, see External OAuth overview.
• Your backend must be able to obtain a valid OAuth access token for each viewer. See Step 5: Decide how your backend gets each viewer’s token.
• Your app must run on a container runtime, which is required for restricted caller’s rights. See Runtime environments for Streamlit apps.

Step 1: Register allowed embedding domains¶

ALTER ACCOUNT SET STREAMLIT_EMBEDDING_CONTROLS = $$
allowed_embedding_domains:
  - https://portal.example.com
  - https://analytics.example.com
$$;

Step 2: Grant privileges to your viewers’ roles¶

With this model the embed URL is minted under the viewer’s role, not a service role. That means each role your viewers use needs both privileges on the app:

GRANT USAGE ON DATABASE  mydb               TO ROLE finance;
GRANT USAGE ON SCHEMA    mydb.public        TO ROLE finance;
GRANT USAGE ON STREAMLIT mydb.public.my_app TO ROLE finance;
GRANT EMBED ON STREAMLIT mydb.public.my_app TO ROLE finance;

REVOKE EMBED ON STREAMLIT mydb.public.my_app FROM ROLE <role_name>;

A viewer whose role has USAGE but not EMBED can open the app in Snowsight but can’t be served it through your embedded page. That’s the useful distinction: EMBED controls who may be shown the app in an external page, separately from who may view it in Snowflake.

Step 3: Set up caller grants¶

For the app to query data on the viewer’s behalf, an ACCOUNTADMIN, or a role with the MANAGE CALLER GRANTS privilege, must authorize the app owner’s role to pass caller privileges through to the target schema. The following example uses the high-level caller privilege DATA READ:

-- Run as ACCOUNTADMIN, or the owner of mydb.finance
GRANT CALLER DATA READ ON SCHEMA mydb.finance TO ROLE <app_owner_role>;

This doesn’t give the app owner read access to mydb.finance. It only authorizes the app owner’s role to delegate the viewer’s own finance privileges through the app. Viewers who hold finance see the data; viewers who don’t are denied.

For more information, see Restricted caller’s rights and Streamlit in Snowflake.

Step 4: Use a caller’s rights connection in your app¶

In your app code, use the named connection for restricted caller’s rights:

conn = st.connection("snowflake-callers-rights")

Queries run through this connection execute as the viewer, so row access policies and privilege checks reflect the viewer’s grants rather than the app owner’s.

Step 5: Decide how your backend gets each viewer’s token¶

Unlike the service-user model, there’s no single stored credential here. Your backend authenticates to Snowflake as the viewer, using an OAuth access token that your IdP issued for that viewer. Where that token comes from is your application’s decision, and there are two common patterns.

Server-side token (recommended). Your backend already authenticated the viewer, so it holds their tokens in a server-side session store. The token never enters the browser, and your minting route looks it up from the session:

// Preferred: the token is looked up server-side from the viewer's session.
const session = await getSession(request); // your existing auth layer
const embedUrl = await mintEmbedUrl(session.snowflakeAccessToken, session.snowflakeRole);

Token forwarded from the browser. If your frontend obtains the token directly from the IdP, for example with an IdP SDK that performs the authorization code flow in the browser, it forwards that token to your backend on each request:

// Frontend: attach the viewer's IdP access token to the mint request.
const token = await idp.getAccessToken(); // e.g. an MSAL or Okta SDK call
const res = await fetch("/api/embed-url", {
  cache: "no-store",
  headers: { Authorization: `Bearer ${token}` },
});
const { embedUrl } = await res.json();

Your backend then reads that header, which is the oauthToken the next step consumes.

Whichever pattern you use, each mint request carries a different viewer’s token, so there’s nothing to pool or reuse between viewers.

Step 6: Mint the embed URL per viewer¶

POST /api/v2/databases/{database}/schemas/{schema}/streamlits/{name}:generate-embed-url

{ "parent_origin": "https://portal.example.com" }

{ "embed_url": "https://…" }

For this model, send OAUTH as the token type, and set X-Snowflake-Role to the role that viewer should be served the app under:

SNOWFLAKE_ACCOUNT_URL=https://myorg-myacct.snowflakecomputing.com
STREAMLIT_APP=mydb.public.my_app
PARENT_ORIGIN=https://portal.example.com

// app/api/embed-url/route.ts
import { NextResponse } from "next/server";

export const runtime = "nodejs";
export const dynamic = "force-dynamic"; // never cache the single-use embed URL

async function mintEmbedUrl(oauthToken: string, role: string): Promise<string> {
  const [db, schema, name] = process.env
    .STREAMLIT_APP!.split(".")
    .map(encodeURIComponent);
  const res = await fetch(
    `${process.env.SNOWFLAKE_ACCOUNT_URL}/api/v2/databases/${db}/schemas/${schema}` +
      `/streamlits/${name}:generate-embed-url`,
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        // The viewer's OAuth access token from Step 5.
        Authorization: `Bearer ${oauthToken}`,
        "X-Snowflake-Authorization-Token-Type": "OAUTH",
        // The viewer's role. It needs USAGE and EMBED on the app.
        "X-Snowflake-Role": role,
      },
      body: JSON.stringify({ parent_origin: process.env.PARENT_ORIGIN }),
    },
  );
  if (!res.ok) throw new Error(`${res.status}: ${await res.text()}`);
  return (await res.json()).embed_url;
}

export async function GET(request: Request) {
  // Server-side pattern: read the viewer's token and role from their session.
  // If you forward the token from the browser instead, read it from the
  // Authorization header here and reject the request when it's absent.
  const session = await getSession(request);
  if (!session) {
    return NextResponse.json({ error: "Not signed in" }, { status: 401 });
  }
  try {
    return NextResponse.json({
      embedUrl: await mintEmbedUrl(
        session.snowflakeAccessToken,
        session.snowflakeRole,
      ),
    });
  } catch (e) {
    return NextResponse.json({ error: (e as Error).message }, { status: 500 });
  }
}

Step 7: Render the app in an iframe¶

If you forward the viewer’s token from the browser, add the Authorization header shown in Step 5: Decide how your backend gets each viewer’s token to the fetch calls below. With the server-side pattern, the frontend calls /api/embed-url with no extra headers, exactly as shown.

<p id="msg">Loading…</p>

<script>
  fetch("/api/embed-url", { cache: "no-store" })
    .then((r) => r.json())
    .then((d) => {
      if (!d.embedUrl) throw new Error(d.error);
      const frame = document.createElement("iframe");
      frame.src = d.embedUrl;
      frame.title = "My Streamlit app";
      frame.allow = "clipboard-read; clipboard-write; fullscreen";
      frame.style = "width:100%; height:800px; border:none;";
      document.body.replaceChildren(frame);
    })
    .catch((e) => {
      document.getElementById("msg").textContent = "Error: " + e.message;
    });
</script>

// app/page.tsx
"use client";
import { useEffect, useRef, useState } from "react";

export default function EmbeddedApp() {
  const [embedUrl, setEmbedUrl] = useState<string | null>(null);
  const [error, setError] = useState<string | null>(null);
  const requested = useRef(false);

  useEffect(() => {
    if (requested.current) return; // the embed URL is single-use, so mint once
    requested.current = true;
    fetch("/api/embed-url", { cache: "no-store" })
      .then((r) => r.json())
      .then((d) => (d.embedUrl ? setEmbedUrl(d.embedUrl) : setError(d.error)))
      .catch(() => setError("Could not load the app."));
  }, []);

  if (error) return <p>{error}</p>;
  if (!embedUrl) return <p>Loading…</p>;

  return (
    <iframe
      src={embedUrl}
      title="My Streamlit app"
      allow="clipboard-read; clipboard-write; fullscreen"
      style={{ width: "100%", height: "100vh", border: "none" }}
    />
  );
}

window.addEventListener("message", (event) => {
  // Only accept messages from the Snowflake app origin
  if (!event.origin.endsWith(".snowflake.app")) return;

  switch (event.data?.type) {
    case "SNOWFLAKE_EMBED_LOADED":
      console.log("App is ready", event.data.appId);
      break;
    case "SNOWFLAKE_EMBED_ERROR":
      console.error("App failed to load", event.data.appId);
      break;
    case "SNOWFLAKE_EMBED_SUSPENDED":
      console.warn("App suspended", event.data.appId);
      break;
    case "SNOWFLAKE_EMBED_SESSION_EXPIRED":
      console.warn("Session expired. Reload the page to get a fresh embed URL.");
      break;
  }
});

What’s next?¶

• Troubleshoot embedded Streamlit in Snowflake apps: Diagnose mint failures, blank iframes, and apps that load for some viewers but not others.
• Restricted caller’s rights and Streamlit in Snowflake: How caller grants scope what an app can do on a viewer’s behalf.
• Row access policies in Streamlit in Snowflake: Filter rows per viewer with row access policies.
• Security considerations: What the embedding domain list does and doesn’t protect against.