Chat Without Logging In Using a Contact Source ID

Let users who are already logged in to your website start chatting with their own user identifier (Source ID), without logging in again. The platform maps this identifier to a contact, and requests wi

When you embed Web Chat in your website, users are often already logged in to your site. This setting lets them start chatting directly with the user identifier from your system, without going through another login screen, while the public chat URL still blocks anonymous access.

MaiAgent calls this identifier the Source ID, and uses this name in both the administration interface and the embed script. When the platform receives a Source ID, it maps it to (or creates) a contact. That user's conversation history is associated with this contact.

1. What this setting solves

Before this setting, you had two choices for login settings:

• Enable login: Users were still asked to log in again, even though the embedding site had already verified their identity.

• Disable login: Anyone could use the public chat URL anonymously.

With this setting enabled, you can achieve both goals: users with a Source ID and a valid signature can chat directly, while all visitors without them are redirected to the login page.

This setting is disabled by default. When disabled, all existing behavior remains unchanged.

2. Enable the setting

Setting location: In the left menu, go to " Customer Service Conversations > Chat Platforms ", select a website-type chat platform, and open the " Login Settings " tab.

1. Select a login source first

This toggle depends on the login settings. You must first select a source (MaiAgent／AD／Keycloak／LINE) under " Login Source ". Until you select one, the toggle is unavailable and the interface displays " Please select a login source first ".

The Login Settings tab, with this toggle disabled by default

2. Enable the toggle

Enable " Allow embedded clients to chat without logging in using Source ID ". The verification method, signing secret, and integration examples appear only after you enable it.

The settings section shown after enabling the toggle; the verification method defaults to "Require signature verification"

3. Select a verification method

Verification method	Description	Use case
Require signature verification (recommended)	The embedded client must include a signature calculated by your backend. Access is granted only after verification succeeds. Only a server holding the secret can start a conversation on behalf of a user.	Production environments
Source ID only	No signature is verified; access is granted when a Source ID is provided.	Testing or closed internal networks

When you select "Source ID only", the Source ID acts as an access pass. If your Source IDs are guessable values such as email addresses, student IDs, or employee IDs, others can impersonate those users to chat and read their conversation history. For scenarios that require verified identities, use signature mode or AD／Keycloak／MaiAgent login instead.

A red risk warning appears when "Source ID only" is selected

4. Obtain the signing secret

After you select signature mode and save the settings, the platform generates a signing secret. In the secret field, you can:

• Click " Show " to view the full secret (masked by default)

• Click " Copy " to share it with your engineer

• Click " Regenerate " to issue a new secret

Store the secret in an environment variable on your server. Never put it in frontend code. Regenerating the secret immediately invalidates the old one. Update your backend at the same time, or all signature verification attempts will fail.

5. Set the signature validity period

Choose 1, 5, or 15 minutes. The default is 5 minutes. Expired or previously used signatures are rejected.

Signing secret, signature validity period, integration examples, and behavior preview

The validity period limits "how long this signature can be used to start a conversation", rather than how long the conversation lasts. Once a user has authenticated, they can chat normally and will not be logged out after 5 minutes.

3. How your engineer integrates it

The " Integration Examples " section in the administration interface includes this chat platform's identifier, so the examples can be copied and used directly. For complete parameter descriptions, verification rules, and troubleshooting, ask your engineer to refer to Web Chat Embedding and SDK · Signature Verification.

1. Calculate the signature on the backend

The signature is HMAC-SHA256(secret, "{chat platform identifier}.{Source ID}.{timestamp}"), passed as a hex string. The timestamp is in Unix seconds (UTC), generated by your backend.

PHP

$ts  = time();
$sig = hash_hmac('sha256', "{$webChatId}.{$sourceId}.{$ts}", $SIGNING_SECRET);

Node

const ts = Math.floor(Date.now() / 1000);
const sig = crypto.createHmac('sha256', SIGNING_SECRET)
  .update(`${webChatId}.${sourceId}.${ts}`).digest('hex');

Python

ts = int(time.time())
sig = hmac.new(SIGNING_SECRET.encode(),
  f"{web_chat_id}.{source_id}.{ts}".encode(), hashlib.sha256).hexdigest()

2. Pass the values to the embed script on the frontend

window.MaiAgent.setupAuth({ sourceId, name, ts, sig });

3. Integration notes

• Generate a new signature for every visit: Each signature can be used successfully only once. The embedded client must not cache signatures.

• Calculate signatures on the backend: Once the secret appears in frontend code, it is effectively public.

• Keep clocks accurate: The system allows 60 seconds of clock skew. Timestamps outside this range are rejected.

• Use the correct chat platform identifier: The signature includes the chat platform identifier. A signature calculated with another chat platform's identifier will not pass verification.

4. Behavior comparison

Incoming request	Result
Includes Source ID ＋ valid signature	Starts chatting directly without a login screen
Includes Source ID with an invalid or expired signature	Rejected
Reuses the same signature	First use succeeds; second use is rejected
No Source ID (including directly opening the public URL)	Redirected to the login page
Verification method is "Source ID only" ＋ includes Source ID	Starts chatting directly without signature verification
This toggle is disabled	Retains the original login settings behavior

All rejection scenarios return the same external response, without revealing the reason for failure or whether a particular Source ID exists. The reason appears only in the signature verification failure log in the administration interface.

5. Signature verification failure log

If you encounter integration issues, click " View Signature Verification Failure Log " in the settings section to see recent failures, so your engineer can troubleshoot independently. The log does not contain secrets or full signatures.

The expanded signature verification failure log

Reason	Common causes
Signature expired	Server clock skew, or the embedded client cached a signature
Timestamp exceeds the allowed future range	Server clock is more than 60 seconds ahead
Signature mismatch (secrets may differ)	The backend secret differs from the one in the administration interface, or the signature string was constructed incorrectly
Missing timestamp or signature	The embedded client did not provide ts or sig
Signature already used	The same signature was sent a second time
Replay prevention cache unavailable	A temporary platform issue; the system rejects access rather than granting it
Source ID maps to multiple contacts	Duplicate contact records with the same Source ID exist on this chat platform

6. Frequently asked questions

Will the user's conversation end when the signature expires?

No. The validity period only limits "how long this signature can be exchanged for an identity". Once the user has authenticated, the conversation duration follows Web Chat's existing mechanisms and is unaffected by the signature validity period.

Can one Source ID map to multiple contacts?

Within a single chat platform, one Source ID maps to only one contact. If the same Source ID is used across multiple chat platforms, each platform has its own contact, with separate conversation histories.

Will enabling this setting affect existing embeds?

This setting is disabled by default, so existing chat platforms retain their behavior. If you enable it and select signature mode, requests without ts and sig will be redirected to the login page. Confirm with your engineer that the embedded client has been updated before enabling it.

Can users continue chatting after logging out of my website?

Users who have already authenticated can continue their current conversation. You control the issuance of signatures: stop issuing new signatures after a user logs out, and they will no longer be able to authenticate again. If you need access to expire immediately on logout, contact us so we can assess an appropriate approach.

Will AI tool calls include the login credentials of a user who enters with a Source ID?

No. "Use the Keycloak login identity for tool calls" applies only to visitors who actually log in with Keycloak. The identity is determined by the organization member bound when the conversation is created, rather than the Source ID provided by the embedded client, so a Source ID cannot be used to impersonate someone else's credentials. If your tools need to identify users, use Keycloak login with that feature, or configure MCP credentials for the contact.