Genesys does not make request to my IDP for authenticated messaging

Web Messaging
1

The authentication is enabled for my deployment ID, and it can be verified by

curl -X POST -H "Content-Type: application/json" \
  -d '{
    "deploymentId": "026894c0-901b-4355-9f80-a6cc1ecd70bf",
    "journeyContext": {
      "customer": {
        "id": "a47a1770-1152-11ef-a9bb-5950e7bbf767",
        "idType": "cookie"
      },
      "customerSession": {
        "id": "a47a1770-1152-11ef-a9bb-5950e7bbf767",
        "type": "web"
      }
    },
    "oauth": {
      "code": "380d0b17-3adc-4037-b3fd-1550ba0a38d3",
      "redirectUri": "https://app.spotnana.com"
    }
  }' \
  https://api.mypurecloud.de/api/v2/webdeployments/token/oauthcodegrantjwtexchange

If you use mock oauth.code, then it returns "Failed to identify user for token", which is expected. If auth is not enabled, you will see "auth not enabled" error message. But when using on production website, with genesys chat app ("https://apps.mypurecloud.de/genesys-bootstrap/genesys.min.js).

I saw no request is made to my IDP (No CloudTrail log to my IDP from Genesys), but if I run above cUrl command manually in terminal, I can see the genesys request to my IDP in CloudTrail log.

I have another deployment ID for dev, not for prod. This deployment will make a success request to my IDP, verified by AWS CloudTrail log.

So what Messenger configuration or deployment in Genesys could impact this behavior? Need some suggestion here.

2

Hi,

Can you elaborate on how you run Messenger ?
Are you using the Genesys widget out of the box or any customization (headless sdk, etc) ?

I suppose you already checked the configuration on Messenger side.
If the api is not invoked, this likely means that no invocation to /authorize was issued.

  • Have you checked the integration configuration ? Is it enabled without errors ?
  • I would first check the console log in the Web browser to see what requests are issued / rejected.
  • How is the prod different from the dev env ?

Please do not write sensitive information like deploymentId, redirect uri or oauth code.
Instead, provide the correlationId / contextId provided in the api response.

Hope this helps,

Regards,
V.P.

3

Hi V.P.

Are you using the Genesys widget out of the box or any customization (headless sdk, etc) ?

The chat widget is run by copy & pasting the generated js code from genesys dashboard, basically running the widget out of box, which load script from here: 'https://apps.mypurecloud.de/genesys-bootstrap/genesys.min.js'

I would first check the console log in the Web browser to see what requests are issued / rejected.

I did, no auth error in browser console log. In chrome inspector->network, no request to https://api.mypurecloud.de/api/v2/webdeployments/token/oauthcodegrantjwtexchange

How is the prod different from the dev env ?

-- Prod and dev uses different deployment ID with different set of OIDC settings
-- Prod and dev uses the same code to launch the chat widget (different deployment ID as variable)
-- Additional steps was added for prod to do database query for more user details and routings, no such steps on dev

Have you checked the integration configuration ? Is it enabled without errors ?

Integration setting mistake is also my guess, but it works correctly before and no change after that.

Question 1:
My guess is user didn't logout last time, but close the browser directly, no
window.Genesys('command', 'Auth.logout');
triggered. Then Genesys kept a corrupted chat status. Then next time user authenticates, Genesys thinks this chat is still going on, no need to authenticate again, then resume previous chat, therefore didn't trigger authentication. As I mentioned before, the issue is no request is made to "oauthcodegrantjwtexchange", then it defaults to unknown, "no name" displayed at agent side, no email from IDP userInfo endpoint, then our routing based on email is wrong.
I used

    AuthProvider.registerCommand('getAuthCode', (e) => {
    ...
    });

for authentication. Do you think it could be an issue here?

Question 2
A Genesys behavior I found in my local dev is that after a success authentication, "oauthcodegrantjwtexchange" will not be called after I reload the page, but chat can resume and show previous chat history. What do you use to identify this user to resume the chat? Journey ID? How do you pass on this id to the newly reloaded page?

4

Hi,

Question 1:
The way you describe the behavior sounds like authentication mode is not enforced.
If Messenger is able to create a user session (since a flow is processing messages), and you don't get any identifier,
then it is likely that the backend service is not expecting an authenticated session either.
When authentication is enabled, this tells the backend service to require a Genesys JWT when starting a user session.
Otherwise session cannot be initiated.

Have you enabled the step-up option in the config ?
(See picture below).

image

This does not enforce authentication at startup but gives the user the ability to upgrade from anonymous session to authenticated session (after the anonymous session has started).
Disabling this option will enforce authentication at session startup.

This is likely your issue.

Question 2:
User session is created by Messenger with a unique identifier.
Messenger stores this info locally (see https://developer.genesys.cloud/commdigital/digital/webmessaging/messengersdk/localStorage#localstorage-creation)
and re-uses it for the next launch until the session is expired or closed.
This goes the same for the authentication. A JWT and a refresh token are generated and saved in browser storage.
JWT is short lived. Refresh token is long lived and used to avoid the user to login again each time.
WebMessaging session will be accessible for the duration of the refresh token.
When the refresh token expires, authentication is required again.
You can control how the tokens are generated by using scopes in the original /authorizaton request.
Not including offline_access will remove the refresh token. Genesys JWT lifetime is mapped on the access token lifetime but capped to 15 minutes max.

Hope this helps,

Regards,

1 Like
5

Very good to know. Thank you!

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.