How do you embed a Tableau Cloud view in an app without making users sign in separately?

## The problem embedding actually solves You want a Tableau view inside your own application — a customer portal, an internal tool — and you do not want the viewer to see a Tableau login prompt. The naive fixes are all wrong: a shared service account destroys per-user data restriction and audit; putting credentials in the page hands them to anyone with developer tools; making the view public is not an option for customer data. The correct shape is **identity assertion from your backend**. Your app already knows who the user is. It vouches for that identity to Tableau with a short-lived, cryptographically signed token, and Tableau renders the view as that Tableau user. ## Connected apps and JWTs On current Tableau Cloud and Tableau Server, the mechanism is a **connected app**. An administrator registers the application on the site, which produces a client ID and a secret. Your backend then signs a JSON Web Token whose claims identify the connected app, name the **Tableau username to impersonate** as the subject, request an embedding **scope**, and carry a short expiry and a unique token ID. The token is passed to the embedded viz on the page, and Tableau validates the signature, checks that the named user exists on the site, and renders the view under that identity. What matters at interview depth is less the exact claim spelling than the properties: - **Signing happens server-side only.** The secret never reaches the browser. A backend endpoint mints a token for the currently authenticated session and returns just the token. - **Tokens are short-lived and single-purpose.** Minutes, not hours, scoped to embedding rather than to the full REST surface. - **The subject must map to a real Tableau user.** Impersonation is not user creation; provisioning still has to happen, typically by syncing identities from your identity provider. - **The connected app can be disabled centrally**, which is the kill switch if a secret leaks. ## Trusted tickets: the older path On older Tableau Server deployments the equivalent was **trusted authentication**. The Tableau Server is configured to trust the IP addresses of your web servers. Your backend POSTs the username to the server's trusted-ticket endpoint, receives a short-lived single-use ticket, and constructs the view URL containing that ticket. The browser loads it, the ticket is redeemed, and a session is established for that user. It works, and plenty of deployments still run it, but it authenticates by trusting a network address rather than a signature, so connected apps are the better model where they are available. ## The reason this matters more than convenience Because the viewer resolves to a real Tableau identity, **everything identity-dependent works**. Permissions on the workbook and its data source apply to the impersonated user. User functions in calculations — `USERNAME()`, `ISMEMBEROF()`, `FULLNAME()` — return that user, so a data source restricting rows to the viewer's own account, region or tenant behaves correctly inside your app. That is the entire security argument for doing embedding this way instead of with a shared account: a customer viewing your portal sees only their own rows because Tableau evaluates the restriction against the asserted identity, not because your application remembered to pass the right filter. That also flags the corresponding risk. If your backend will mint a token for **any** username it is asked for, an authorization bug in your app becomes a data breach in Tableau. The token endpoint must derive the subject from the authenticated session on the server, never from a request parameter the client controls. ## Getting the view onto the page Modern embedding uses Tableau's Embedding API v3, which provides a web component you place in your markup, pointing at the view URL and carrying the token, with JavaScript available to drive filters, respond to mark selection and coordinate the view with the rest of your page. Older integrations used the JavaScript API v2 or a plain iframe. Which one you use is a detail; the identity question above is the part interviews probe. One thing not to say: Tableau has no "publish to web" anonymous-sharing feature of the kind Power BI offers. Tableau's public-sharing product is Tableau Public, which is a separate service intended for genuinely public data. Confusing the two in an interview about customer data is a memorable mistake. ## Practicalities to mention Every embedded viewer still resolves to a licensed identity on the site, so **user provisioning and the commercial arrangement for embedded viewers are real project constraints** — worth raising early with whoever owns the Tableau contract, since the answer depends on the deployment rather than on anything you can reason out. Beyond that: keep an eye on render performance, since the embedded view carries the same query cost as the standalone one; plan for token refresh on long-lived pages; and log token minting on your side, because Tableau's audit will show the impersonated user, not the application that vouched for them.