Use cookieless trusted authentication. Your backend requests a short-lived authentication token for the signed-in user, and the ThoughtSpot Visual Embed SDK sends it with every request, so browsers that block third-party cookies don't break the embed.
This approach is particularly useful for SaaS embedded analytics, where applications need to deliver a seamless experience through an embedded dashboard without requiring users to authenticate separately.
In ThoughtSpot, these tokens last 300 seconds by default and never extend. If users drop out after five minutes, return a fresh token from getAuthToken on every call, request a longer validity_time_in_sec, and run SDK 1.48.0 or later on ThoughtSpot Cloud 26.3.0.cl or later, where the SDK fetches a new token before the old one expires.
Checked against Visual Embed SDK 1.53.1 and the ThoughtSpot Cloud 26.10.0.cl documentation, October 2026.
Cookieless authentication signs users in to embedded analytics without third-party cookies, which many browsers block in iframes. With ThoughtSpot Trusted Authentication, your backend vouches for a signed-in user: it uses a secret key to request a short-lived authentication token, and the Visual Embed SDK sends that token instead of a cookie.
Which ThoughtSpot settings keep users signed in?
|
Setting |
Where |
Value |
|
authType |
init() |
AuthType.TrustedAuthTokenCookieless |
|
autoLogin |
init() |
true |
|
getAuthToken |
init() |
A function that returns a new token on every call |
|
refreshAuthTokenOnNearExpiry |
Each embed |
true (on by default from SDK 1.48.0) |
|
validity_time_in_sec |
Your token request |
1800 (default 300) |
What should you check when you compare tools?
"Many web browsers block third-party cookies (Safari, Edge, mobile browsers)", and "cookieless authentication avoids this restriction" (trusted auth in the SDK). Your app stays in charge of identity, and the secret key never reaches the browser.
When evaluating an embedded analytics tool, also consider how its authentication approach supports customer facing dashboards, particularly when users access analytics through an existing SaaS application.
Ask any vendor:
Does the embed still work when the browser blocks third-party cookies?
Do my users get single sign-on through my app, or sign in a second time to the analytics?
Who sets token lifetimes, and does the SDK refresh tokens before they expire?
What does the five-minute logout look like?
The embed loads, then stops working about five minutes later. The SDK may emit EmbedEvent.AuthExpire, which the docs describe as "The ThoughtSpot authentication session has expired" (EmbedEvent).
If getAuthToken returns the expired token again, SDK 1.53.1 shows the first message below as a browser alert and logs the second to the console:
Duplicate token. Please issue a new token every time getAuthToken callback is called. See https://developers.thoughtspot.com/docs/?pageid=embed-auth#trusted-auth-embed for more details.
Received invalid token from getAuthToken callback or authToken endpoint.Received invalid token from getAuthToken callback or authToken endpoint.
Why does it happen?
Two documented defaults set the clock:
validity_time_in_sec "defaults to 300 seconds (5 minutes)" (token request service).
"When used as a bearer token, the lifespan of the token is established when it is requested and does not ever extend" (trusted auth in the SDK).
From SDK 1.45.2 with ThoughtSpot Cloud 26.3.0.cl, the SDK can call getAuthToken again before the token expires, and from SDK 1.48.0 it does this by default. So a five-minute logout usually means one of three things:
getAuthToken returns the same token again, for example from a cache, so it has already expired.
The SDK is older than 1.45.2, the instance is older than 26.3.0.cl, or the SDK is 1.45.2 to 1.47.x without refreshAuthTokenOnNearExpiry: true.
autoLogin is false, which turns off the SDK's token refresh.
How do I fix it?
1. Return a fresh token on every call. The SDK calls getAuthToken again when auth expires, and the docs warn: "if it is called with an older token, the authentication will not succeed" (EmbedConfig: getAuthToken).
import { init, AuthType } from '@thoughtspot/visual-embed-sdk';
init({
thoughtSpotHost: 'https://<TS_HOST>',
authType: AuthType.TrustedAuthTokenCookieless,
autoLogin: true,
getAuthToken: async () => {
const r = await fetch('/api/ts-token', { credentials: 'include' });
if (!r.ok) throw new Error(`Token request failed: ${r.status}`);
const { token } = await r.json();
return token;
},
});Set autoLogin: true explicitly. The reference lists its default as false (EmbedConfig: autoLogin). SDK 1.53.1 treats an unset value as true only when it refreshes cookieless tokens; other parts of the SDK, such as the login redirect, still read it as unset.
2. Run SDK 1.48.0 or later, or turn on near-expiry refresh yourself. refreshAuthTokenOnNearExpiry is available from SDK 1.45.2 with ThoughtSpot Cloud 26.3.0.cl (LiveboardViewConfig), and the SDK turns it on by default from 1.48.0. Set it per embed, not in init().
import { LiveboardEmbed } from '@thoughtspot/visual-embed-sdk';
new LiveboardEmbed('#embed', {
liveboardId: '<LIVEBOARD_GUID>',
refreshAuthTokenOnNearExpiry: true, // default from SDK 1.48.0; set per embed
}).render();3. Request a longer token. ThoughtSpot suggests "possibly 20 or 30 minutes, or more" for cookieless auth (token request service), and at least 10 minutes for Spotter embeds.
// Token service (Node/Express). Server only: never ship secret_key to the browser.
// requireLogin is your own auth middleware.
app.get('/api/ts-token', requireLogin, async (req, res) => {
const r = await fetch(`https://${process.env.TS_HOST}/api/rest/2.0/auth/token/full`, {
method: 'POST',
headers: { 'Content-Type': 'application/json', Accept: 'application/json' },
body: JSON.stringify({
username: req.user.tsUsername,
secret_key: process.env.TS_SECRET_KEY,
validity_time_in_sec: 1800, // 30 minutes; the default is 300
}),
});
if (!r.ok) return res.status(502).send('Token request failed');
const { token } = await r.json();
res.json({ token });
});Don't use multi-day tokens: anyone holding one can act as that user until it expires or you revoke it.
How do I check it worked?
Log each getAuthToken call and keep the page open past the token's lifetime. A new token should arrive and the dashboard should keep loading. In the token response, expiration_time_in_millis minus creation_time_in_millis should equal your lifetime (1,800,000 for 30 minutes).
Still failing?
The login page appears instead of a refresh. Set autoLogin: true. disableLoginRedirect: true (SDK 1.9.3+) stops the redirect (EmbedConfig).
A "Duplicate token" alert appears. getAuthToken returned the same token as last time. Return a new one on every call.
Accounts get locked. Users who retry with "an invalid or expired token" "may get locked out of their accounts" (troubleshooting). Return a fresh token each time.
Spotter shows authorization errors on long answers. Use tokens of at least 10 minutes, on SDK 1.45.0+ with ThoughtSpot Cloud 26.2.0.cl+ (embed Spotter).
How do I explain this to my team?
|
Who |
What they'll ask |
What you can tell them |
|
Security |
Where do the credentials live? |
On our server. The browser only holds a short-lived authentication token for one user, and we set how long it lasts. |
|
Engineering lead |
How much do we build and maintain? |
One backend route that returns a token, and init() in the front end. From SDK 1.48.0 on ThoughtSpot Cloud 26.3.0.cl, the SDK calls our route for a new token before the old one expires. |
How can I try this before I commit?
Start a free ThoughtSpot Embedded trial.




