Labs4Change

Embedding Omni Analytics: How Signed-URL Embeds Actually Work

David Badovinac

The architecture of secure Omni embeds — per-user signed URLs, server-side secrets, and user attributes for row-level security — walked through with Hawkfry Group's open-source omni-embed-demo.

Customer-facing analytics is where BI platforms earn their keep — and where security mistakes become breaches. Embedding Omni into your product is architecturally simple, but the simplicity depends on getting one thing exactly right: the embed URL is a credential, and it must be minted server-side, per user, per session.

The fastest way to understand the pattern is to run it. Hawkfry Group maintains omni-embed-demo — an open-source Node.js/Next.js reference app that demonstrates secure multi-user Omni embedding with the official Omni SDK. We partner with Hawkfry on Omni work, and this demo is what we point engineering teams at before they write a line of embed code. (Note the repo's own caveat: it's a learning and testing reference, not a production app to deploy as-is.)


The architecture in one paragraph

Your server holds the Omni embed secret. When an authenticated user opens the analytics page, a server-side route uses the Omni SDK to generate a unique, signed URL for that user and that dashboard, embedding their identity and user attributes into the signature. The client receives only the signed URL and renders it in an iframe. The secret never leaves the server; the user can only ever see what their signature says they can.

Four principles fall out of this, and the demo is organized around them:

  1. One embed URL per user — never share or cache signed URLs across users
  2. Server-side URL generation — secrets stay out of the client bundle, always
  3. User-specific permissions — user attributes ride along in the signature and drive row-level security
  4. Auth integration — embed URLs are generated from your app's session, so your auth system remains the single source of truth

Where the Omni-specific code lives

The demo separates boilerplate from the parts you'll actually adapt — three files carry all the Omni logic:

FileRole
src/lib/omni-embed.tsWraps the Omni SDK to generate secure signed links
src/pages/api/embed-url.tsServer-side API route that mints signed URLs per request
src/components/OmniEmbed.tsxReact component that renders the signed URL in an iframe

Everything else is standard Next.js. That's the right amount of surface area: an embed integration should be a thin, auditable layer, not a framework.

Running it

git clone https://github.com/Hawkfry-Group/omni-embed-demo.git
cd omni-embed-demo
npm install
cp .env.example .env    # add your Omni embed secret + organization name
npm run dev

Configuration is two steps: the .env gets your 32-character embed secret and org (standard *.embed-omniapp.co domains and vanity domains are both supported), and src/config/demo-ids.ts gets your real dashboard/workbook IDs, connection ID, and optionally a custom theme ID. Then switch between the demo users in the UI and watch the same dashboard render differently per user — that's user attributes flowing through the signature into row-level security.

The part teams get wrong

The embed iframe is the last step of your security story, not the first. What a user sees inside an embedded dashboard is decided by the same layered access model that governs internal users — connection restrictions, access_filters keyed on user attributes, and required_access_grants. We broke that model down in Omni access management explained.

The embed-specific rule: the user attributes you sign into the URL are the user attributes RLS will trust. Generate them from your application's authenticated session, never from client input, and treat any attribute you didn't validate server-side as attacker-controlled.

Comparing platforms: Looker's embed SDK is more mature — we said as much in our honest comparison — but Omni's embedding surface is evolving fast, and the signed-URL-plus-attributes model shown here is already enough for real multi-tenant products.

Beyond the demo

For production you'll add your own session handling, URL refresh, error states, and monitoring — and you'll want scripted control of the platform side (provisioning embed users, syncing attributes). That's omni-user-manager and the official Omni CLI territory. The full community resource map lives in Hawkfry's omni-resources and our own Omni resource guide.

Get the LookML Best Practices Guide + AI Skill

Embedding starts with a clean model. Get our guide with 6 production patterns that keep multi-tenant analytics safe.


Labs4Change partners with Hawkfry Group on Omni implementations, including embedded analytics builds. Book a free strategy call to scope your customer-facing analytics.

Keep reading