ok just reading more carefully the Matthew's post and it seems still some issue to resolve . Let's continue to be in touch
Original Message:
Sent: 02-06-2026 03:35
From: Frederic Thomas
Subject: Unexpected Long-Lived JWT After Refresh in Genesys Web Messaging SDK with Salesforce OAuth Provider
Hi @Matthew Pfluger, @Vineet Kakroo
Thanks both to follow up on this thread. I am happy to hear issues are fixed on all side
I hope your E2E tests will be successful
regards
------------------------------
Frederic Thomas
Senior Manager, Development
Original Message:
Sent: 02-06-2026 03:12
From: Vineet Kakroo
Subject: Unexpected Long-Lived JWT After Refresh in Genesys Web Messaging SDK with Salesforce OAuth Provider
Hi @Matthew Pfluger,
Great to know its been fixed for you too.
Yes we had raised a ticket with Genesys support in September-25 and finally they managed to fix it after a few iterations/delays, and deployed the fix on 3/4 Feb 26. We have started to test this end-to-end and initial tests showed its been fixed.
It would be good for someone else to also check this, who has had this issue before.
Regards
Vineet
------------------------------
Vineet Kakroo
Senior Technical Consultant
Original Message:
Sent: 02-05-2026 21:16
From: Matthew Pfluger
Subject: Unexpected Long-Lived JWT After Refresh in Genesys Web Messaging SDK with Salesforce OAuth Provider
I wanted to post an update to anyone else who finds this message in the future (and to @Vineet Kakroo specifically). As of today, I'm no longer experiencing the long-lived token. I'm unclear of the exact date, but with a recent update made by the Genesys team, the issue is resolved.
Here's how I tested the fix:
- Get an Auth Code from the OAuth Authorization Server.
- Invoke the Token Exchange API endpoint to obtain a JWT and Refresh Token. Verify the endpoint returns a valid, non-expired JWT.
- Invoke the Refresh Token API endpoint. Verify the endpoint returns the same JWT (since it shouldn't be expired yet).
- Wait at least 15 minutes for the JWT to expire.
- Invoke the Refresh Token API endpoint again. Verify the endpoint returns a different, valid, non-expired JWT.
- Verify the second JWT's expiration time is a reasonable and expired duration.
In my case, the second JTW expired after 900 seconds. As such, I can confirm the issue is resolved.
That being said...
I had a call with Genesys engineers today to discuss this long-lived token issue within the context of a project that used the Web Messaging SDK. I told them I was managing the token refresh within my code because the SDK doesn't invoke the `refreshToken` endpoint and keep the JWT valid. They told me that the SDK is managing the JWT refresh correctly. However, I can confirm that the SDK still is not invoking the `refreshToken` endpoint to keep the token alive.
In our situation, the SDK gets the Auth Code via a full page redirect (both the `getAuthCode` and `reAuthenticate` functions). I designed the script to retrieve the Auth Code from the redirect URL and resolve the `getAuthCode` function with the code. That causes the SDK to invoke the `oauthcodegrantjwtexchange` endpoint which works fine. Then, imagine the User either doesn't interact with the Messenger widget until the token expires OR the User has an active chat session (which uses the Web Socket) open until the token expires.
When the User either starts a new chat or deletes the current chat, then the SDK will attempt to use that JWT. Finding that the JWT is expired, the SDK then invokes the `getAuthCode` function again. Since this function causes a full page reload, the User experiences another delay while the site reloads. This is an unnecessary action by the SDK. It could (and should) be simply refreshing the token.
I understand this last report is not the topic of this thread, but it is related. I'll post this report in a few other related threads I'm following.
------------------------------
Matthew Pfluger
Original Message:
Sent: 11-08-2025 08:34
From: Matthew Pfluger
Subject: Unexpected Long-Lived JWT After Refresh in Genesys Web Messaging SDK with Salesforce OAuth Provider
Understood, sorry about that! Thanks for chiming in, and we look forward to seeing a resolution on this issue. Have a great weekend!
------------------------------
Matthew Pfluger
Original Message:
Sent: 11-07-2025 16:01
From: Jacob Shaw
Subject: Unexpected Long-Lived JWT After Refresh in Genesys Web Messaging SDK with Salesforce OAuth Provider
Hi Matthew, I retracted my response because I posted it before I saw the replies to the original post. I retracted it because I didn't add much helpful to the discussion, only that this is a potential bug based on the documentation, which states that the JWT will have a TTL of 15 minutes, or the age of the access token, whichever is smaller. The solution as per our policies is to continue to work with Care to get this resolved, since it is a potential bug, and we are limited on how much we can investigate customer data/configuration on this forum.
------------------------------
Jacob Shaw
Sr. Software Engineer
Original Message:
Sent: 11-07-2025 15:41
From: Matthew Pfluger
Subject: Unexpected Long-Lived JWT After Refresh in Genesys Web Messaging SDK with Salesforce OAuth Provider
I'm sorry, I don't see your message. Will you please repost?
------------------------------
Matthew Pfluger
Original Message:
Sent: 11-07-2025 15:35
From: Jacob Shaw
Subject: Unexpected Long-Lived JWT After Refresh in Genesys Web Messaging SDK with Salesforce OAuth Provider
------------------------------
Jacob Shaw
Sr. Software Engineer
Original Message:
Sent: 11-03-2025 17:19
From: Matthew Pfluger
Subject: Unexpected Long-Lived JWT After Refresh in Genesys Web Messaging SDK with Salesforce OAuth Provider
We're integrating the Genesys Web Messaging SDK into a Salesforce Community Portal (Experience Cloud) that requires authentication. The portal itself serves as our web app, and Salesforce is also acting as our OAuth provider.
The integration is functioning through a Genesys OIDC-type integration, and initial authentication works correctly. However, when we attempt to refresh the access token, the second JWT returned by Genesys Cloud is valid but has a time-to-live (TTL) that far exceeds expected limits, causing API rejections and a re-authentication loop in the widget.
Note: I apologize for the length and formality of this post. It's a complicated issue which has stymied us for more than a week now. I'll try to distill it to the basics!
Setup Summary
1. Salesforce OAuth Client Configuration
App Type: External Client App
Flows Enabled: Authorization Code and Credentials Flow
Scopes:
openid, id, profile, email, address, phone
offline_access, refresh_token
Token Settings:
Session Timeout: 14 minutes (configured)
No PKCE, No JWT-based access tokens, and No custom claims or audiences configured.
Callback URLs validated and confirmed multiple times.
2. Genesys Cloud Integration
Integration Type: OpenID Connect (OIDC)
Authorization Server URL: Salesforce well-known OIDC endpoint
Refresh Token Duration: 900 minutes (15 hours)
Client ID/Secret: Matches Salesforce external client app configuration
3. Genesys Cloud Messenger Configuration
Within Genesys Cloud Admin → Messenger Configurations, we created a dedicated configuration for our Salesforce-based deployment. The setup is kept simple to minimize variables during authentication testing.
Channel Setup
Channel Type: Web Messaging
Version: Draft (not yet deployed to production)
Language: English (default and only supported language)
Messaging Behavior
Humanize Conversation: Disabled
Clear Conversation: Enabled
Conversation Disconnect: Display conversation status and disconnect session
Rich Text Formatting: Enabled
Typing Indicators: Enabled (both agent and end-user)
Attachments: Disabled
Automatic Start: Disabled
Authentication
Authentication Enabled: ✅ Yes
Integration Type: OpenID Connect Messenger Configuration (points to our OIDC integration tied to Salesforce)
Upgrade Anonymous to Authenticated Conversation: Disabled
Notifications: Disabled
This configuration ensures authentication is handled exclusively through the OIDC flow and that no secondary conversation or attachment features interfere with token refresh testing.
4. SalesForce Portal Configuration
The portal is an LWR (Build Your Own) template in Salesforce Experience Cloud.
We've added the Web Messaging SDK snippet to the portal's <head> tag for initialization and authentication.
The SDK successfully exchanges the Salesforce authorization code for a valid JWT through Genesys Cloud's /token endpoint.
Problem Description
The first JWT returned by Genesys Cloud (after exchanging the Salesforce authorization code) is valid and has the expected 2-minute TTL, matching our Salesforce configuration.
After that token expires, the SDK invokes the refresh token command.
Genesys Cloud returns a new JWT that appears valid but has a TTL between ~50,000 and 90,000 seconds (roughly 14–25 hours).
This token fails validation against Genesys Cloud APIs (which enforce a maximum of 900 seconds / 15 minutes TTL), causing the Web Messenger widget to enter a re-authentication loop.
Once in this state, the SDK keeps receiving the same long-lived JWT with each refresh, preventing recovery until the refresh token is revoked or the session is reset.
We've replicated the exact same workflow using Auth0 as the OAuth provider, and the problem does not occur - the JWTs issued through Genesys Cloud respect the expected TTL from Auth0 every time.
Example JWT
Troubleshooting Steps Attempted
Validated all callback URLs and scope configurations in both Salesforce and Genesys Cloud.
Re-issued client credentials and re-authenticated.
Shortened and lengthened session timeouts in Salesforce.
Adjusted refresh token lifetime in Genesys Cloud integration (no change).
Attempted forced logout and SDK re-init; token still re-issued with incorrect TTL.
Confirmed the problem only occurs when the refresh flow is used; initial code exchange works fine.
Request for Help
Has anyone seen this behavior where Genesys Cloud issues a JWT with an excessively long TTL after exchanging a Salesforce refresh token?
Is there any known incompatibility or additional configuration required on the Salesforce side for OIDC refresh flows?
Does Genesys Cloud interpret Salesforce's exp or iat differently when calculating TTL during refresh?
Any recommended debugging steps or logs we can capture to confirm the root cause?
Thanks in advance for your assistance!
#WebMessaging
------------------------------
Matthew Pfluger
------------------------------