Error message: "text": "{"message":"Failed to identify user for token: 2f24b602eb08bbxxxxxxxxxxxdeploymentId: e578e735-7670-45fb-a337-xxxxxxxxxx","code":"unauthorized","status":401,"contextId":"05583e59-4d14-4236-xxxxxxxxxxxx","details":[],"errors":[]}"
I'm not aware of any integration with ForgeRock but I could be wrong.
Regarding the issue, it occurs when exchanging the code with the auth server.
I could see the following error message: invalid_client (Invalid authentication method for accessing this endpoint.)
So no issue in the snippet but some discrepancy in what is supported by the auth provider and what is used by the openid client.
For example, the client is configured for basic authentication, but client_id and client_secret are provided in the body of the request and NO Basic Authentication header was provided.
Can you check what is expecting the auth server ?
I do not have access to the customer config unfortunately.
Checking logs on auth server could help as well.
Thanks for the update - we've configured the OpenID integration in their org with their discovery URI, client secret and client ID and I can see that it matches to their configuration within forgerock - I will go back to customer and get the logs checked.
Josh, one more hint: please ensure that redirectURI value that is passed from your client into Genesys Cloud is matching the redirectURI value that is defined in your ForgeRock deployment: redirectURI values must match, it's part of OIDC procedures.
Thank you for that - will confirm with the customer.
Can I confirm if the auth script is okay?
Comparing it to the base code it doesn't include nonce, maxage, codeVerifer or ISS - not sure if this is required or if it is varies depending on the auth provider?
Yes, they are tons of extra security parameters
I would suggest to not set them unless you know why.
If set or mismatch, the error is different from the one there is currently. So don't think this is an issue here.
Regarding the script, it looks ok but the redirecturi content which points to the auth server discovery document is weird.
It should be a web site app that the oauth server called upon successful authentication with various extra parameters (including the auth code).
This web site url should be properly registered within the auth server.
However this does not seem to be an issue here since Messenger did the exchange call, so received the callback (redirect uri that was set when calling the initial /authorize).
It would be better to have the same values though.
As a quick overview, login workflow is as follows:
web site will call auth server /authorize with a (registered) redirect_uri.
Upon successful authentication, auth server will do a Http redirect using the redirect_uri to send back exchange code (and possibly other extra parameters, like iss, etc).
Messenger extracts data sent back and calls Genesys auth endpoint to exchange tokens.
Checked again logs and still seeing the same error invalid_client (Invalid authentication method for accessing this endpoint.)
I still think that this article applies.
There's a mismatch in what auth server expects and what the client sends.
Note that you can manually do the exchange token using any http tools like Curl, Postman or Insomnia to find out what of request fails or succeeds.
Looks like there is progress made here Configuration in ForgeRock had to be set to client-secret_basic.
The next question I have is in relation to scopes. Are we expecting to see scopes included in the payload when calling /api/v2/webdeployments/token/oauthcodegrantjwtexchange?
also - would ISS need to be included in the scropt if we can see it in the JWT payload?
Regarding scopes, no they are not part of the payload.
Scopes are specified only once when calling the very first /authorize request.
Once authenticated, scopes are part of the user session and can be retrieved from the auth server.
GET https://<server>/authorize?client_id=cliendId
&response_type=code
&response_mode=fragment
&scope=openid%20profile%20email%20offline_access <==== set requires scopes
&redirect_uri=<redirect url>
Regarding iss, this is a security parameter that needs to be set only if the auth server expects it.
See RFC 9207 - OAuth 2.0 Authorization Server Issuer Identification
In short, your document discovery needs to set this option: authorization_response_iss_parameter_supported
and include the iss parameter when calling the redirect uri.
Don't set iss if this is not the case. Login will fail.
This is a general rule: Don't set a security parameter if it is not expected.
I could see some successful login requests and some errors as well because the same exchange code is being reused several times (it can be used only once).
Can I just confirm what the expected behaviour is in this scenario?
I've logged into the secure portal and have successfully been authenticated. The session is still active and I navigate to a different page (same domain however outside the secure portal) - is it expected that the session remains active? (taking into account the message threading timeline has been set to 5 hours)
Note this customer has two deployments - one for the public facing website and another for the secure portal.
Yes, think so.
Threading time line is different than webmessaging session time life.
This is a bit confusing I know.
Threading timeline is about "when to chunk" conversations (and then restart routing or not, display history, etc).
Thanks as always for that - I see that the web messaging guest session is hard coded to 72 hours according to documentation however below is an example of that not being the case - is the documentation out of date with the new messaging disconnection options for Web Messaging?
I've played with those settings before and we have set it to Display conversation status - but my question is more on the end-user side and how long the transcript in the widget is visible.
In the below screenshot - the end user is able to see previous conversation history from more than 72 hours of inactivity.
When is this completely cleared for the end-user (regardless of the Conversation Disconnect option) ?
Through testing it seems that the chat transcript is still visible for the end-user until they clear local storage or if "Display conversation status and disconnect session" - and they click "Start New"
Glad you find out something.
I don't think indeed there's any mechanism out of the box to remove the transcript from Messenger when conversation is cleared.
Alternatively, there's an option that allows the user to manually clear the screen but that's still manual action.
