Authenticating your customers in Genesys Cloud web messaging with OpenID Connect

A customer signs in to your website at 21:15 to check an order, finds a problem and opens the Messenger to ask about it. In an anonymous session, the first few messages are spent on identification and verification: the agent, or a bot, asks for a name, an email address, an order number and perhaps a security answer, and then checks them against a back-office system. The customer has already proved who they are to your website a minute earlier, yet the contact centre cannot see it.

Authenticated web messaging closes that gap. Genesys Cloud CX lets you restrict Messenger so that only users who have signed in to your website or app can start or resume a web messaging conversation, and it obtains their identity directly from your identity provider through OpenID Connect, the open standard Genesys relies on for this integration. The agent and the Architect flow receive verified details rather than whatever the customer types. The customer starts with their question, not with their credentials, and your contact centre stops collecting personal data it does not need to ask for.

Three parties take part. Your identity provider, the OpenID provider your website already uses for sign-in, authenticates the customer. Genesys Cloud holds an OpenID Connect Messenger Configuration integration that knows your provider's Discovery URI and a client ID and client secret issued by it. In the page, Messenger runs alongside an AuthProvider plugin that your web team writes: a small piece of JavaScript that hands Messenger what it needs from your sign-in process, and that Messenger calls again when it needs a fresh code.

Genesys supports two flows and recommends the authorisation code flow. The customer signs in at your provider, which returns an authorisation code to your redirect URI. The AuthProvider plugin's getAuthCode command resolves with that code and the redirect URI, plus a code verifier if you use PKCE. Genesys Cloud exchanges the code for tokens with your provider, reads the claims from the ID token, and issues a Genesys JWT that starts the authenticated web messaging session. The client secret never touches the page. If you request the offline_access scope, a refresh token is issued as well, and Messenger uses it to obtain a new JWT before asking the plugin to sign the customer in again.

The implicit flow, in which the ID token is returned directly to the browser, is disabled by default and has no refresh token. Genesys describes it as less secure and suitable only when the authorisation code flow is not possible, so our designs use the code flow unless a client's identity platform leaves no alternative. Either way, a failed login returns HTTP 401 with a generic error, and we design the customer experience for that case too.

Configuration follows a clear sequence. First, create or configure a client at your identity provider; Genesys recommends a separate client ID for the Genesys integration, which keeps its redirect URIs, scopes and secret independent of your website's own client. Second, in Genesys Cloud, under Menu > IT and Integrations > Integrations, install and configure the OpenID Connect Messenger Configuration integration with the Discovery URI, the maximum refresh token lifetime, and the client credentials. Third, enable Authentication in your Messenger configuration and select that integration. Finally, assign the configuration to a Messenger deployment, set it to Active and place its snippet on your pages, directly or through a tag manager.

On the page, the AuthProvider plugin is loaded after the Messenger snippet. Its getAuthCode command must always resolve with the latest code, because Messenger can call it repeatedly. Its reAuthenticate command handles the case where the refresh token has expired or is unavailable, and an optional signIn command supports step-up conversations, in which Messenger asks the customer to sign in once it is already running. Logging out through the Auth plugin publishes an event across the browser tabs and devices where the customer is signed in, which lets your site clear its own state at the same moment.

Licences and permissions are stated plainly in the Genesys documentation. Authenticated web messaging requires a Genesys Cloud CX 2, CX 3, CX 4, CX 2 Digital, CX 3 Digital or CX 1 Digital Add-on II licence, all permissions under Web Deployments > Configurations and Web Deployments > Deployments, and an inbound message flow. Scopes deserve thought: openid is required, profile supplies given_name and family_name, email supplies the email address, and Genesys recommends the phone scope for phone_number.

Once the session is authenticated, the inbound message flow can see it. Architect exposes read-only built-in variables: Message.IsAuthenticated is true when authentication was requested for the message as it entered the queue, and Message.Message.senderAddressInfo carries the customer's unique identifier from the sub claim, their email address from the email claim, and their full name built from given_name and family_name. A flow can greet the customer by name, look up their account through a data action using a verified identifier rather than a typed one, branch on whether the session is authenticated, and route accordingly.

For the customer, the benefit is continuity. Genesys documents that authenticated users can resume their existing web messaging conversations in any browser where they sign in, so a conversation started on a laptop at work can continue on a phone at home. For the agent, the conversation arrives with a verified identity instead of a set of claims the customer has typed. That changes the opening of every interaction: the agent can move straight to the order, the claim or the booking, and save step-up verification for the transactions that need it.

Authentication becomes more valuable when Genesys Cloud can connect the conversation to the customer's wider history. Genesys announced identity stitching and journey support for authenticated web messaging in 2025, and its release notes describe the result: administrators can enable the authenticated web messaging channel in single customer view, agents can search for an existing contact in the profile panel or create one and claim the external ID supplied by the OIDC provider, and authenticated web messaging interactions appear in the customer journey alongside other supported channels.

Identity resolution is configured per deployment. On the Identity Resolution page's Web Messenger tab, you turn on identity resolution for the authenticated deployment, keep Merge Contacts on, and select an external source; Genesys uses the external ID from that source to identify the contact. Without an external source, stitching falls back to identifiers such as email or phone number where available, and with authentication off, contacts are stitched by cookie ID only. The Messenger configuration warns administrators that enabling authentication stores personal data on the associated contact, so this is a decision for your data protection officer as well as your architects.

Some organisations still remember authenticated chat as a heavy integration in the web application layer, with the website collecting a login and passing details to Genesys through the API. Web messaging removed most of that work, and the platform has since moved on entirely. Genesys ended support for ACD Web Chat version 2, including Chat Widget versions 1.1 and 2.0, on 11 June 2025, and asked customers to migrate to web messaging and Messenger. Authenticated web messaging appears in Genesys's own web chat to web messaging migration guide as one of the suggested steps.

For organisations planning that work today, the order matters. We start with anonymous Messenger, inbound message flows and routing that are stable in production, then add authentication once the identity provider client, the AuthProvider plugin and the flow logic have been proven together in a test organisation. Where step-up conversations are enabled, Messenger can start before the customer has signed in and ask them to sign in later through the AuthProvider plugin, so general questions and account questions can share one deployment.

Authenticated web messaging sits where three teams meet: your identity team, your web team and your contact centre. That is where projects stall, so we bring the parts together. In Discover and Define, our Senior Business Consultant maps which journeys need a verified identity, which can stay anonymous and what agents should see, and captures the data protection decisions on contact records and retention. In Design, the Solution Architect documents the OIDC client, scopes, claims, redirect URIs and token lifetimes in an Interface Control Document, so your identity and web teams build to the same contract as our Genesys Cloud configuration.

Our Senior Developers then build the inbound message flows, identity resolution settings and, where you want it, the AuthProvider plugin itself, to the Senior Platform Practice Lead's engineering standards with four-eyes review. Our Systems Integration Tester proves the paths that matter in real life: a first sign-in, an expired refresh token, a step-up mid-conversation, a sign-out in another tab, a provider outage and a customer with no email claim. All of this is delivered remotely, and support afterwards follows your Genesys Cloud CX consumption and support model.