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-sdkpackage
- Authentication already implemented in your application
- A backend that can generate a Notiondesk user token
- Your Notiondesk App Secret
How user identification works
The authentication flow is:
- A user signs in to your application
- Your frontend requests a Notiondesk user token from your backend
- Your backend signs a short-lived token for that authenticated user
- Your backend returns the signed token to the browser
- Your website or application passes the token to Notiondesk Messenger
- 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_SECRETYou 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:
| Claim | Description |
|---|---|
type | Token type required by Notiondesk |
iat | Time the token was issued |
exp | Time the token expires |
user_id | Unique identifier for the user in your application |
site_uuid | Identifier 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_IDwith your Messenger ID
YOUR_SIGNED_TOKENwith 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_idfrom 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_idis used instead ofsub
site_uuidmatches the correct Notiondesk site
- The token was signed using an active App Secret
userTokenordata-user-tokenis 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.