Response path — Tableau → Backend → Web frontend → User: a single-use dashboard URL, rendered in the browser.
- User — works inside the client’s web app; never sees an external login.
- Web frontend — the client’s on-brand UI; holds no secrets.
- Auth0 (identity) — verifies the user in the background via API; no hosted login page.
- Backend — the trusted middleman; validates the session, checks permissions, requests access.
- Tableau — serves the dashboards; only ever talks to the backend.
Custom authentication flow with no external login screen. All identity and token exchange happens server-side. The user and web frontend never talk to Tableau directly.
The challenge we faced
When a client came to us to embed analytics inside their product, the requirement sounded simple: show Tableau dashboards inside the app. The reality was anything but.
Every standard Tableau SSO path forced users through a separate Microsoft login screen, right in the middle of a product that had been carefully designed to feel like one seamless experience. A user would be working inside the application, click through to a dashboard, and suddenly hit a generic blue Microsoft sign-in page that had nothing to do with the brand they thought they were using.
For the client, that broke the whole promise of the product. The analytics were meant to feel native. Instead, the login flow announced, at exactly the wrong moment, that this part was someone else's software.
What we actually needed
After several rounds of workshops with the client's engineering team, the non-negotiables were clear.
- No second login screen. Users should never leave the application.
- No third-party branding. The experience must match the client's product, not Microsoft's.
- Full control of the look and feel, end to end.
- A true single sign-on experience: log in once, reach everything, Tableau included.
Why we ruled out traditional SSO
Standard Tableau SSO leans on redirects. The whole model assumes users are comfortable bouncing between login screens, which is fine for internal tools where everyone already knows the drill. For a customer-facing product, it's a broken experience.
Two problems made it a non-starter:
- Out of flow — Users were pushed out of the flow they were in, then back again.
- Disconnected hand-off — The hand-off felt clunky and disconnected, exactly the seam we were hired to remove.
So we made the call early: drop the redirect model entirely. We treated identity as something we own and verify quietly in the background, so the user only ever interacts with the client's application. Everything else happens where they can't see it.
Our solution architecture
The solution looks more complex under the hood, but that complexity is exactly what makes it invisible to the end user. All the orchestration happens server-side.
- User layer — the person using the app; never sees an external login.
- Frontend — the client's application UI; stays on-brand at all times.
- Identity (Auth0) — verifies who the user is, silently.
- Backend — the trusted middleman that talks to Auth0 and Tableau.
- Tableau — serves the dashboards, and only ever talks to our backend.
How we built it — the real implementation
Owning the login UI
We built the entire login interface from scratch, embedded directly in the application. No Auth0 hosted pages, no redirects. Our own UI talks to Auth0's authentication API in the background.
Key insight
Users never know Auth0 exists. Every interaction stays on-brand, with no redirect and no loss of context.
Managing sessions our way
Once the user is authenticated, we issue a token that proves the session is valid, and our backend takes over completely. We manage sessions with short-lived, signed tokens rather than long-lived credentials.
Key insight
The token says who the user is and what they're allowed to do, and nothing more. It expires in minutes, so a leaked token is close to worthless.
The Tableau integration piece
Tableau dashboards are private by design, and that's a good thing. We needed a way for authenticated users to reach them without ever handing Tableau a raw credential. Tableau talks only to our backend, which acts as a trusted intermediary.
Key insight
Tableau never faces the end user. It only ever trusts our backend, so there's no path for a user to reach it directly.
Embedding dashboards securely
On the backend, each request runs a strict sequence: confirm the session is valid, check the user's permission for that specific dashboard, apply row-level security rules for their role, generate a short-lived Tableau token (valid 5–10 minutes), and send that single-use URL to the frontend.
Key insight
The frontend receives one scoped, short-lived URL for one dashboard. Click a link and it loads, with no waiting and no visible authentication. It just works.
Security was our top priority
A seamless experience is worthless if it's insecure. From day one, the architecture was built to keep the security boundary where it belongs.
- Secrets stay on the backend — all sensitive logic, tokens, and authentication live server-side, never exposed to the browser.
- Short-lived tokens — every Tableau token expires in minutes, so intercepting one buys an attacker almost nothing.
- Defence in depth — the server validates every request independently; the frontend is never trusted to police itself.
- Least privilege — users get access only to the dashboards their role allows, enforced at query time, not hidden in the UI.
- Everything encrypted — HTTPS end to end, with no sensitive data in the browser.
- Minimal attack surface — by keeping identity out of the frontend entirely, we shrank the number of places a vulnerability could hide.
What this achieved
When the dust settled, the difference was night and day.
For your users
One login, one seamless experience. No second sign-in, no Microsoft screen, no sense of leaving the product.
For your engineering team
A clean, standards-based authentication layer that's simple to extend. Adding a new dashboard or a new permission rule doesn't mean reworking the flow.
For security and compliance
Full visibility into who accessed what, centralized permission management, and an attack surface deliberately kept small.
When you probably shouldn't do this
This approach isn't right for every situation. If any of these describe you, standard federated SSO is the better call.
- Internal tools only — if your users are all staff who already live in Azure AD or Okta, a standard SAML/OIDC hand-off is simpler and perfectly fine.
- Strict federation mandates — some organisations require identity to flow through approved providers. Respect that; don't build custom.
- Cross-application SSO across many apps — if you need one login shared across a whole suite, federated SSO is built for exactly that.
- Limited need to customise — if the standard login experience is acceptable for your users, there's no reason to build something bespoke.
Key lessons from building this
- Separate concerns cleanly — using Auth0 for identity while owning the experience ourselves gave us the best of both: proven security, and full control of the flow.
- Security and UX aren't opposites — done right, a seamless experience quietly improves security. Users aren't forced to make choices that create risk.
- The backend is the security boundary — the frontend is never trusted with anything sensitive. All critical decisions happen server-side.
- Good authentication is invisible — if a user is thinking about authentication, something has gone wrong. The goal is for it to disappear.
Things to consider before building this
- Backend infrastructure matters — you need solid session and token handling. This isn't something you can half-do.
- Token refresh logic — handle it carefully, or users hit friction the exact moment they shouldn't.
- Error handling — Auth0 and Tableau both fail sometimes. Plan for it, so a hiccup degrades gracefully instead of breaking the experience.
- Monitoring — set up proper tracing for authentication and token usage, so you can catch problems before users do.
- Compliance requirements — confirm your industry's rules before you start; they may shape the whole design.
Wrapping up
When we started this project, most teams would have accepted the trade-off: a slightly awkward login screen in exchange for working analytics. We didn't think that trade was necessary, and it turned out it wasn't.
By owning the identity experience while leaning on Auth0 and Tableau for what they do best, we removed the false choice between security and user experience. The result is a system that's genuinely seamless and genuinely secure, and it holds up in production.
That, more than any single piece of technology, is what made the difference here.