Tableau Connected Apps: Secure Embedding Without Managing User Accounts

Tableau Connected Apps are an authentication mechanism that allows external applications to embed Tableau views, dashboards, and full UI experiences without requiring embedded users to have Tableau accounts. Authentication is handled through signed JSON Web Tokens (JWTs) generated by the embedding application, which Tableau validates to grant access. For organisations building customer-facing analytics portals, internal business applications with embedded reporting, or enterprise platforms that include Tableau visualisations, Connected Apps are the modern, secure approach that replaces the older trusted authentication mechanism.

The Embedding Authentication Problem

Embedding Tableau in external applications presents an authentication challenge: Tableau needs to know who the embedded user is and what they are allowed to see, but the embedded user may not be a named Tableau user, may not have Tableau credentials, and may be accessing Tableau through a customer portal rather than a corporate SSO system.

The traditional approaches to this problem had significant drawbacks. Trusted authentication — where the embedding application passes a username to Tableau, which grants access without a password — required network-level trust configuration and exposed the trusted IP address as the security boundary. It also required that every embedded user have a Tableau user account, which is economically impractical for customer-facing deployments with thousands of users.

Connected Apps solve this by shifting the authentication trust to a cryptographic model: the embedding application holds a secret key and signs JWTs that assert the user's identity and entitlements. Tableau validates the signature using the corresponding public key registered in the Connected App configuration. No network trust, no username whitelist, no per-user Tableau accounts required.

Connected App Types

Tableau supports two Connected App architectures:

**Direct trust** — The embedding application generates and signs JWTs using a secret key stored in the application. This is the simpler model and appropriate when the embedding application is a trusted server-side application with secure secret storage. The secret is registered in Tableau and held in the embedding application; valid JWTs signed with that secret grant access.

**OAuth 2.0 trust** — The embedding application delegates token generation to an external OAuth 2.0 Identity Provider (IdP). The JWT is issued by the IdP, not the embedding application directly, and Tableau validates the token against the IdP's JWKS endpoint. This model is appropriate when the organisation already has an OAuth 2.0 IdP infrastructure and wants to leverage it for Tableau embedded authentication — avoiding the need to manage a separate Tableau secret.

Most new deployments start with direct trust for its simplicity. OAuth 2.0 trust is typically adopted when the organisation's security policy requires all authentication to flow through the central IdP.

JWT Structure for Tableau

JWTs for Tableau Connected Apps have a specific structure. The payload must include:

**sub** — the subject, typically a username or user identifier.

**jti** — a unique JWT ID, used by Tableau to prevent token replay attacks. Each JWT must have a unique jti value; Tableau rejects tokens with previously used jti values.

**aud** — audience, set to "tableau".

**iss** — issuer, the Connected App's client ID registered in Tableau.

**iat** — issued at timestamp.

**exp** — expiration timestamp. Tableau enforces token expiration; tokens should be valid for a short window (typically 5 minutes for initial authentication, with the Tableau session persisting after that).

**https://tableau.com/oda/claims/v1** — the optional claim block that allows passing user attributes — site role, group memberships, and custom attribute values — that Tableau uses for entitlement and personalisation decisions.

A Python example of JWT generation for a Tableau Connected App:

import jwt

import uuid

from datetime import datetime, timedelta

payload = {

"iss": "your-connected-app-client-id",

"exp": datetime.utcnow() + timedelta(minutes=5),

"jti": str(uuid.uuid4()),

"aud": "tableau",

"sub": user_email,

"scp": ["tableau:views:embed"],

"https://tableau.com/oda/claims/v1": {

"stsi": "Creator", # site role

"groups": ["Analytics Users"]

}

}

token = jwt.encode(payload, connected_app_secret, algorithm="HS256")

The token is then passed to the Tableau Embedding API v3 as the JWT parameter when initialising the embedded view.

Embedding API Integration

Connected App authentication integrates with the Tableau Embedding API v3, the current JavaScript library for embedding Tableau content:

The embedding application includes the Tableau Embedding API v3 script, initialises a TableauViz object with the URL of the view to embed, and passes the JWT in the token parameter. Tableau validates the token and renders the view for the authenticated user.

The flow is:

1. User loads the embedding application page.

2. The embedding application's server generates a JWT for the current user, signed with the Connected App secret.

3. The JWT is returned to the browser (either embedded in the page or via an API call).

4. The JavaScript embedding code initialises the Tableau viz with the JWT.

5. Tableau validates the JWT signature against the registered Connected App, verifies the claims, and renders the view.

The user never sees a Tableau login prompt. Authentication is seamless from the user's perspective.

User Provisioning and Licensing

Connected Apps support two user provisioning models:

**Provisioned users** — Users with explicit Tableau accounts. The JWT's sub claim maps to an existing Tableau username. This model is appropriate for internal applications where all users are already Tableau users.

**On-demand activation (ODA)** — Users provisioned on first access. When a JWT arrives for a user who does not yet have a Tableau account, Tableau creates the account automatically, assigning the site role specified in the JWT claims. ODA requires appropriate licensing — Tableau Embedded Analytics licensing is typically used for customer-facing deployments that require on-demand user creation.

For customer-facing deployments with large user populations, ODA with Embedded Analytics licensing is the standard model. For internal applications where the user population is controlled, provisioned users with Viewer or Explorer licences may be more appropriate.

Security Considerations

Connected Apps introduce security considerations that require attention:

**Secret rotation** — The Connected App secret must be treated like an API key. It should be stored in a secrets manager (AWS Secrets Manager, HashiCorp Vault), not in application configuration files or environment variables. It should be rotated on a defined schedule, with the rotation coordinated between the Tableau Connected App configuration and the embedding application's secret store.

**JWT expiration** — JWTs should have short expiration windows (5 minutes maximum). Long-lived tokens are a security risk; if a token is intercepted, it can be used until it expires.

**HTTPS requirement** — Connected App JWT authentication must occur over HTTPS. Tokens transmitted over HTTP can be intercepted and replayed. The Tableau Server or Cloud endpoint and the embedding application must both use HTTPS.

**Token replay prevention** — Tableau validates jti uniqueness to prevent replay attacks. Embedding applications must generate unique jti values for every JWT — uuid4 generation is the standard approach.

**Scope restriction** — The scp claim limits what the JWT grants access to. Use the minimum scope required: tableau:views:embed for view embedding, not broader scopes. Principle of least privilege applies to JWT claims.

Our Tableau consulting practice implements Connected App integrations for enterprise embedding projects — customer portals, internal business applications, product analytics. Contact us to discuss embedded Tableau analytics for your application.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.