Personal access tokens and connected-tool JWTs, and when each is right

Two credentials, two jobs

Personal access token

Issued to a person, in their name, carrying exactly their permissions and nothing more. It is a sign-in credential, and it answers the question who is this.

Connected App, direct trust

Set up once per site by an administrator. The server mints short-lived JWTs from it that assert a named service account. It is a feature extender, and it answers a different question: what may this platform capability do, and for which account.

These are two routes to two different places. Treating them as interchangeable is the most consequential credential mistake in a Tableau integration. The mistake is common, because both of them work.

Why the personal token wins

The rule here is written into the code, and stated in the module that implements it. Every user signs in with their own Tableau token. That token carries their exact Tableau permissions. It is the governance boundary for every read, every write, and every assistant or tool call made for them.

Signing in belongs to the personal token alone. A one-click path that skipped it did exist at one point, and it was retired deliberately. The resolver was removed, and the gateway now turns down a connect attempt that is JWT-shaped.

The reason is practical rather than architectural. Let a service credential sign a person in, and every action after that carries the service account’s permissions rather than the person’s. The Tableau permission model your team spent years building then stops deciding who can see what.

What the Connected App does

It covers platform capability: a person is already signed in, and the platform itself needs a token of its own. Embedding is the live example. A real Tableau view rendered inside another surface needs a token the embedding API will accept, and a personal token is the wrong shape for that.

• Client ID, secret ID and secret value are locked in per Tableau site by an administrator, encrypted at rest, and never echoed back to a browser.
• The token is minted server-side and scoped per domain. It is short-lived by design, because a long-lived service token is a standing grant nobody reviews.
• The JWT asserts a named Tableau service account: what it can reach is what that account can reach. Give it a large role and you have given it a large role.

Keeping personal tokens clean

• One token per person for interactive use. It is their identity inside the product, and sharing it destroys every attribution downstream.
• A separate, dedicated token for any automation. Tableau allows one live session per token. An automation reusing somebody’s interactive token will sign that person out of their own session, usually at an inconvenient hour.
• Name a token for its purpose, not its creator. Within a year the creator has changed roles and the purpose has not.
• Rotate on a cadence you will actually keep, and put the expiry in a calendar rather than discovering it.

The second one produces support tickets that look like product flakiness. They are a credential collision. It is worth checking first whenever a scheduled job and a person seem to be interfering with each other.

The one deliberate exception

Secrets in this suite are session-only. That holds cleanly until something has to run at two in the morning with nobody signed in. A session-only secret cannot exist at that hour, by definition.

There is one exception, and it is explicit rather than implied. An operator clicks to lock in a token for scheduled runs. It is encrypted at rest under a machine key, never logged, and never echoed back to the browser. The describe call returns the token name only. One click removes it. The interface recommends a dedicated automation token, for the collision reason above.

An exception a person has to click is an exception somebody can find later. An exception that happens automatically is one nobody can audit, and eventually one nobody remembers agreeing to.

Say which credential answered

A scheduled job can try a personal token first and fall back to a Connected App JWT. That is a sensible design. It can also hide a broken credential for months, because from the outside the run keeps succeeding.

The fix is small and it matters. Record which credential actually authenticated, and show it on the row. A fallback that happens invisibly is a fallback nobody ever repairs. The first anyone hears of it is the day the fallback fails as well.

Choosing, in four checks

1. A specific person is doing this, right now, in front of a screen. Their own token.
2. A platform capability needs a token of its own while a person is present. The Connected App.
3. It runs with nobody there. A dedicated automation token, locked in deliberately, rather than a person’s interactive one.
4. Some part of it needs permissions belonging to somebody other than the person asking. Stop there. That is the check that turns a governance boundary into a suggestion.

Four checks, and the fourth is the one worth being slow about. Everything else on this page is downstream of getting it right.