Identify logged-in users in Notiondesk Messenger

Securely identify authenticated users in Notiondesk Messenger using short-lived user tokens generated by your backend.

5 min read

Notiondesk Messenger can identify users who are signed in to your application.

Identification uses a short-lived user token generated by your backend. Your frontend passes this token to the Notiondesk Messenger SDK when Messenger is initialized.

This prevents sensitive authentication credentials from being exposed in browser code.

Before you start

You need:

  • Notiondesk Messenger installed with the @notiondesk-so/messenger-js-sdk package
  • Authentication already implemented in your application
  • A backend that can generate a Notiondesk user token
  • Your Notiondesk App Secret
Never expose your Notiondesk App Secret in frontend JavaScript, React components, environment variables shipped to the browser, or public repositories.

How user identification works

The authentication flow is:

  1. A user signs in to your application
  1. Your frontend requests a Notiondesk user token from your backend
  1. Your backend signs a short-lived token for that authenticated user
  1. Your backend returns the signed token to the browser
  1. Your website or application passes the token to Notiondesk Messenger
  1. Messenger recognizes the visitor as the corresponding user

Your backend should determine the user's identity from your authenticated application session. Do not trust a user ID supplied directly by the browser.

Step 1: Create an App Secret

Go to Settings โ†’ Access in Notiondesk and create an App Secret.

Store the secret in a server-side environment variable, for example:

NOTIONDESK_APP_SECRET
The App Secret is shown only once when it is created. Copy and securely store it when it appears.

You can manage and rotate your App Secrets from Settings โ†’ Access.

Never add the App Secret to:

  • Frontend JavaScript
  • React or Vue client components
  • Public environment variables
  • Browser bundles
  • Public repositories

Step 2: Sign a user token on your backend

Generate the user token from your backend after your application has authenticated the current user.

Notiondesk user tokens use HS256 and must contain these claims:

ClaimDescription
typeToken type required by Notiondesk
iatTime the token was issued
expTime the token expires
user_idUnique identifier for the user in your application
site_uuidIdentifier for your Notiondesk site

Use user_id as the user identifier. Do not use sub instead of user_id.

You can also provide user information such as:

  • email
  • name

Keep tokens short-lived and generate them only on your server.

Notiondesk provides language-specific signing examples in your Messenger setup for languages such as Node.js, Python, PHP, and Ruby. Use the example provided in your Notiondesk dashboard rather than signing tokens in browser code.

Step 3: Pass the token to Messenger

Once your backend has generated the token, pass it to your Messenger installation.

Standard website installation

If you installed Messenger using the standard script, provide the signed token with data-user-token:

<script
  async
  src="https://static.notiondesk.help/messenger/widget.js"
  data-messenger-id="YOUR_MESSENGER_ID"
  data-user-token="YOUR_SIGNED_TOKEN">
</script>

Replace:

  • YOUR_MESSENGER_ID with your Messenger ID
  • YOUR_SIGNED_TOKEN with the token generated by your backend for the current user

Do not hardcode a user's token into a static website template. The token should be generated for the current authenticated user.

JavaScript / TypeScript SDK

Fetch the signed token from your backend and pass it to initNotiondesk:

import { initNotiondesk } from "@notiondesk-so/messenger-js-sdk";

const userToken = await fetch("/api/notiondesk-token").then((response) =>
  response.ok ? response.text() : null,
);

const notiondesk = await initNotiondesk({
  messengerId: "YOUR_MESSENGER_ID",
  userToken,
});

The /api/notiondesk-token endpoint is an example. Use the backend route that matches your application.

React and Next.js

Pass the signed token to NotiondeskProvider:

<NotiondeskProvider
  messengerId="YOUR_MESSENGER_ID"
  userToken={userToken}
>
  {children}
</NotiondeskProvider>

The token can be fetched from your backend after the user has authenticated.

The Notiondesk App Secret must never be available to the client component.

Step 4: Validate the token

Before going live, use the token validation tool available in your Notiondesk Messenger setup.

Paste a token that your backend has just generated.

Notiondesk checks the token against your active App Secrets and shows the user information that Messenger can read from it.

The token used for validation is checked but not stored.

Validation is useful for detecting:

  • Missing required claims
  • An incorrect user_id
  • An incorrect site_uuid
  • Expired tokens
  • Tokens signed with the wrong secret
  • Invalid signatures

Refresh a user token

User tokens should be short-lived.

If your application receives a refreshed token while Messenger is already initialized, update the Messenger configuration:

notiondesk.updateConfig({
  userToken: refreshedUserToken,
});

You do not need to create another Messenger instance just to update the user token.

Handle logout

Clear the identified user when someone logs out of your application.

You can remove the current token:

notiondesk.updateConfig({
  userToken: null,
});

Or destroy the Messenger instance entirely:

notiondesk.destroy();

Make sure the previous user's identity is cleared before another user starts a session on the same browser.

Load Messenger only for authenticated users

Identifying a user and deciding whether Messenger should be available are separate concerns.

If Messenger should only load for signed-in users, keep that permission check inside your application.

For example, with React:

<NotiondeskProvider
  messengerId="YOUR_MESSENGER_ID"
  enabled={currentUser.isAuthenticated}
  userToken={userToken}
>
  {children}
</NotiondeskProvider>

Anonymous Messenger usage can remain enabled if your support experience should be available to both visitors and signed-in customers.

Security best practices

When identifying users in Notiondesk Messenger:

  • Keep your App Secret on the server
  • Sign tokens only on your backend
  • Use HS256
  • Include all required claims
  • Determine user_id from your authenticated server-side session
  • Keep tokens short-lived
  • Never hardcode user tokens into frontend code
  • Refresh tokens when necessary
  • Clear the current token when a user logs out
  • Rotate your App Secret if you believe it has been exposed

Troubleshooting

Messenger does not recognize the user

Check that:

  • The token was generated by your backend
  • The token has not expired
  • All required claims are present
  • user_id is used instead of sub
  • site_uuid matches the correct Notiondesk site
  • The token was signed using an active App Secret
  • userToken or data-user-token is passed to Messenger

Use the token validator in your Notiondesk Messenger setup to inspect what Messenger can read from the token.

The token is rejected

Verify the token was signed using HS256 and contains:

  • type
  • iat
  • exp
  • user_id
  • site_uuid

Also confirm that the App Secret used to sign the token is still active.

Messenger still shows the previous user

Clear the user token when the current user logs out:

notiondesk.updateConfig({
  userToken: null,
});

If your application switches directly between accounts, you can also destroy and reinitialize Messenger.

Was this page helpful?