Emovart Docs
Protected Access

How To Auto Login Users Inside The Emovart Widget

Hand the widget a signed token from your backend so users who are already logged in to your app never see a Emovart login screen.

Last updated on July 9, 2026

The Emovart widget shines inside your product — a help button right where questions come up. But if your help center uses custom backend authentication, showing a login screen inside the widget is friction your users don't deserve: they've already signed in to your app. Auto login fixes that by passing the widget the same signed token your backend already knows how to mint.

Prerequisites

  • Your site uses custom backend authentication — your server can sign JWTs with your site's signing secret.
  • The widget is embedded in your app with the standard snippet.
  • Your frontend can obtain the current user's token from your backend, either templated into the page or fetched from a small endpoint.

Implementation guide

Step 1: Turn on bypass authentication in the widget settings

Open Settings → Help Centers on emovart.studio, select your site, and head to the widget settings. Enable Bypass authentication so the widget accepts tokens instead of presenting its own login.

Bypass authentication toggle
Bypass authentication toggle

Step 2: Pass the token in JavaScript

There are two ways to hand the token over. The simplest is a data-token attribute on the embed snippet, with your backend templating the value in at render time:

<script
  src="https://emovart.studio/helpkit-widget.js"
  data-site="your-slug"
  data-color="#1D4A36"
  data-position="right"
  data-token="<%= emovartToken %>"
  async
></script>

In single-page apps, where a user may sign in without a full page load, call identify() once you have a token:

// fetch a fresh token for the signed-in user, then hand it to the widget
const { token } = await fetch("/api/emovart-token").then((r) => r.json());
EmovartWidget.identify({ token });

Either way, the token must be minted on your server — it's the same HS256 JWT (the user's email signed with your site's secret) described in the custom backend guide.

Step 3: Test the integration

Sign in to your app as a test user and open the widget: articles and search should appear instantly, with no login step. Then load your app in a private window without signing in — the widget should still require authentication, confirming your content stays protected for everyone else.

Best practices

  • Mint tokens only on the server. The signing secret must never appear in frontend code or in the embed snippet itself.
  • Issue a token per user and match its expiry to your app's session length, refreshing it when the session renews.
  • Don't reuse one long-lived token for everyone — each visitor should carry their own.

Troubleshooting

  • The widget still shows a login — confirm the bypass toggle is on, the token hasn't expired, and the secret used to sign it matches the one in the console (regenerating the secret invalidates every previously issued token).
  • The widget doesn't load at all — check that data-site matches your site's slug and look for errors in the browser console.
  • Works for you but not for your users — their tokens are likely signed with a stale secret or an expiry that has already passed; log the token payload server-side to verify what you're issuing.
Was this article helpful?