> ## Documentation Index > Fetch the complete documentation index at: https://docs.cxp.crescendo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Authenticated chat widgets > Require customer sign-in before web chat, restore a login, and manage chat across tabs. Use an authenticated CXP widget when customers must sign in before they can connect to chat. Your CXP administrator must enable authentication for the published Concierge Agent and allow the exact origin of your website. A draft preview uses the published authentication policy. ## Before you enable authentication Coordinate activation with your CXP operator. You need a supported widget build, a configured customer identity tenant with at least one enabled supported login method, and an approved list of HTTPS website origins. The authentication service and chat runtime must be deployed before publishing the protected configuration. Authentication is optional; existing widgets remain anonymous when the published configuration does not enable it. The widget discovers the authentication service through its chat settings response. You do not need authentication configuration on your website server or a separate widget build for each environment. If service configuration changes, customers may need to sign in again. ## Sign in to chat Select **Log in** in the widget. The popup offers the methods enabled in your configured customer identity tenant: * **Continue with Google** for the tenant's native Google provider. * **Continue with Microsoft** for the native Microsoft provider. * **Continue with SSO** for corporate OIDC or SAML. If several corporate providers are enabled, choose one on the next screen. * **Email → Continue → Password → Sign in** for email/password accounts. Use **Forgot password?** to request reset instructions. Google, Microsoft and SSO open a second window for your identity provider while the Welcome window waits. Finish signing in there; both authentication windows close after success and the widget connects. Email/password stays in Welcome. If the provider window is blocked, allow popups for the sign-in site and try again. If you close it or cancel, return to Welcome and choose a method again. Welcome sign-in window waiting for authentication in a second provider window Customers do not need a CXP account, organization membership or agent role. A corporate provider can admit your entire workforce to chat while CXP access remains limited to your configured CXP users. First-time federated users may chat when the provider admits them. Email/password uses an existing identity account; the popup does not offer account registration. Only enabled supported methods appear. All custom OIDC/SAML configurations, including Google-backed OIDC providers, appear under **SSO** and use their configured provider IDs. Authentication remains within the configured customer tenant and does not create a CXP user. Chat sign-in popup with Google, Microsoft, corporate SSO and email options ## Sign in and resume chat The widget shows **Authentication is required** until you select **Log in** and finish signing in in the popup. Allow popups for your website. Conversation content and startup forms appear only after authentication succeeds. Customer Support widget showing Authentication is required and a Log in button A supported browser can restore the same login and chat after a page reload or browser restart. Restoration requires the same browser profile, website origin, widget configuration and an unexpired login. Clearing site data, private browsing or blocked browser storage can prevent restoration. A login lasts up to seven days; you may need to sign in sooner if access is revoked or configuration changes. If the widget reports that authentication is unavailable, enable browser storage and use a browser that supports Web Locks, then select **Retry**. Anonymous widgets do not require these authentication storage features. If the popup reports that sign-in could not be completed, close it and start a fresh login. For developer troubleshooting, the popup console's **Widget sign-in failed** entry includes a stage and error code that you can share with your CXP operator. Do not share account credentials, tokens or authentication URLs. ## Continue in another tab When another tab takes over the same chat, this tab pauses. Select **Continue in this tab** to use it again. Switching tabs alone does not send a pending message. If the widget says a message was not sent, send it again after continuing. Starting a new chat keeps the same valid login. Another open tab adopts the new chat and remains paused until you choose to continue there. ## Log out Select **Log out** to clear the widget's local authentication and conversation state and request revocation of the login. If local cleanup fails, the widget blocks chat and offers **Retry log out**. Logging out of the widget does not sign you out of the website or your identity provider. Widgets share browser storage for a website origin. Only one authentication scope is retained at a time. Use separate browser profiles for different people on a shared device: existing transcript and context storage is not a privacy boundary between people or simultaneously active tabs. ## Host-page integration A host application may provide a current Firebase ID token before the user selects **Log in**: ```javascript theme={null} const widget = document.querySelector('enegelai-bot'); widget.setAuthenticationToken(firebaseIdToken); ``` CXP verifies this token and its organization before using the existing host session. An absent, invalid or mismatched token falls back to customer sign-in. The setter keeps the token only in memory; it does not initiate login. Pass `null` when your application no longer wants to provide a host token. You can also request logout from the host page: ```javascript theme={null} const result = await widget.logoutAuthentication(); // result.localCleanup: 'complete' | 'incomplete' // result.serverRevocation: 'complete' | 'failed' | 'not_attempted' ``` Available sign-in name and email values enter the widget through ordinary context once on login or restoration. Your existing `setContext` calls remain editable; these values are not an identity assertion for contact matching. Never collect tokens, callback URLs or chat connection URLs in analytics. For support, use the non-secret support reference from widget authentication events.