Josh_Civitareale | 2023-08-08 06:32:30 UTC | #1
Hi, we are currently looking to use Authenticated Web Messaging for one of our customers. They are using Forgerock in conjunction with OpenID (which has been set up already) however they are getting an identity error when trying to run the authenticated web messaging code found here: https://developer.genesys.cloud/commdigital/digital/webmessaging/messengersdk/authenticatedMessenger
Error:
Request URL:
https://api.mypurecloud.com.au/api/v2/webdeployments/token/oauthcodegrantjwtexchange
Request payload:
{"deploymentId":"e578e735-7670-45fb-a337-be111658ab17","oauth":{"code":"lyZQje1zseU58mD1JhNEJBWSkqU","redirectUri":https://dev-api.telstrasuper.com.au/api/IdentityMgmt/openidconnect/getauthorisecode},"journeyContext":{"customer":{"id":"eaf332b5-2d60-4a58-835f-cc0ea8f2cae4","idType":"cookie"},"customerSession":{"id":"b60729b8-24ba-467d-9572-59c565f355e6","type":"web"}}}
Response payload:
{
"message": "Failed to identify user for token: 04dd016be93dc0ad47ac1da855e92fcc deploymentId: e578e735-7670-45fb-a337-be111658ab17",
"code": "unauthorized",
"status": 401,
"contextId": "eadb6e51-1629-4161-afac-9c393dc9f6c8",
"details": [],
"errors": []
}
I've attached an image of the code snippet used by the customer
Just wanting to know if anyone else has used Forgerock before for authentication and can spot if anything is missing?
Josh_Civitareale | 2023-08-08 06:40:20 UTC | #2
Additionally the customer has provided these logs
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\":[]}"
vpirat | 2023-08-08 13:33:45 UTC | #3
Hi Josh,
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 clientid and clientsecret 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.
Let us know.
Best regards, V.P.
Josh_Civitareale | 2023-08-08 23:06:40 UTC | #4
Hey V.P.
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.
Angelo_Cicchitto | 2023-08-09 10:59:33 UTC | #5
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.
Josh_Civitareale | 2023-08-09 22:27:33 UTC | #6
Hey Angelo,
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?
vpirat | 2023-08-10 10:36:12 UTC | #7
Hi Josh,
Yes, they are tons of extra security parameters :slight_smile: 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) redirecturi. Upon successful authentication, auth server will do a Http redirect using the redirecturi 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.
Searching in Forgerock faq, I could find this article which looks like close to this issue: https://backstage.forgerock.com/knowledge/kb/article/a27814899
Hope this helps,
Regards, V.P.
Josh_Civitareale | 2023-08-15 00:57:14 UTC | #8
Hey VP - the customer has updated the redirectURI now - "https://dev-api.telstrasuper.com.au/api/IdentityMgmt/openidconnect/getauthorisecode"
But still getting a 401 on the code exchange https://api.mypurecloud.com.au/api/v2/webdeployments/token/oauthcodegrantjwtexchange
I noticed someone had a similar issue on the forums with OKTA - https://developer.genesys.cloud/forum/t/integrate-messenger-with-okta-for-identity-management/18881/3 but a fix was put in (not sure if that was for the API as a whole or just for OKTA integrations)
vpirat | 2023-08-15 09:50:42 UTC | #9
Hi Josh,
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.
1- Request a code exchange using /authorize endpoint Example: GET https://openam-telstrasuper-aus-dev.id.forgerock.io:443/am/oauth2/alpha/authorize?client_id=cliendId &response_type=code &responsemode=fragment &scope=openid%20profile%20email%20offlineaccess &redirect_uri=https://dev-api.telstrasuper.com.au/api/IdentityMgmt/openidconnect/getauthorisecode
2- Request code exchange: Extract the code from the previous call and invoke url: POST https://openam-telstrasuper-aus-dev.id.forgerock.io:443/am/oauth2/alpha/access_token
Headers: authorization: Basic base64(\<clientId>:\<clientSecret>) Content-Type: application/x-www-form-urlencoded accept: application/json
FORM Urlencoded: granttype: authorizationcode redirect_uri: https://dev-api.telstrasuper.com.au/api/IdentityMgmt/openidconnect/getauthorisecode code: \<code>
If this fails, try again with clientId and secretId within the body, not as a header.
The article in the forum you are referring to was indeed a validation issue on our side but has been fixed since then.
Hope this helps.
Regards, V.P.
Josh_Civitareale | 2023-08-16 06:02:10 UTC | #10
Hey VP - thanks for that.
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?
vpirat | 2023-08-16 06:56:42 UTC | #11
Hi Josh,
Nice to hear about the progress.
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 &responsetype=code &responsemode=fragment &scope=openid%20profile%20email%20offlineaccess <==== set requires scopes &redirecturi=\<redirect url>
Regarding iss, this is a security parameter that needs to be set only if the auth server expects it. See https://datatracker.ietf.org/doc/html/rfc9207 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).
Hope this helps.
V.P.
Josh_Civitareale | 2023-08-16 06:58:20 UTC | #12
Yep - we were successful! Now to testing :slight_smile:
Thank you for your help :)
Josh_Civitareale | 2023-08-23 07:29:40 UTC | #13
Hi V.P.
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.
vpirat | 2023-08-23 09:27:20 UTC | #14
Hi Josh,
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).
See https://help.mypurecloud.com/faqs/is-the-web-messaging-guest-session-duration-related-to-threading-timeline/
Regards, V.P.
Josh_Civitareale | 2023-08-24 23:29:22 UTC | #15
Hey V.P.
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?
Additionally in the developer centre this article says it stays in local storage up to a year or if the user manually deletes it
https://developer.genesys.cloud/commdigital/digital/webmessaging/messengersdk/localStorage
vpirat | 2023-08-28 09:19:24 UTC | #16
Hi Josh,
You are referring to disconnect actions that can be configured to allow a manual session disconnection (rather than time-based). So yes, 72 hours still apply but agent or end-user may close earlier the session. See https://developer.genesys.cloud/commdigital/digital/webmessaging/websocketapi#conversation-disconnect
In Messenger configuration:
Regards, V.P.
Josh_Civitareale | 2023-08-28 21:43:52 UTC | #17
Thanks for that V.P
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"
Thanks, Josh
Josh_Civitareale | 2023-08-29 06:27:30 UTC | #18
Actually V.P - think i found my solution here
https://developer.genesys.cloud/forum/t/web-messaging-clear-local-storage-on-browser-close-but-not-refresh-open-new-tab/14257
vpirat | 2023-08-29 10:09:14 UTC | #19
Hi Josh,
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.
Don't hesitate to push new ideas or vote on existing ones if you don't find what you need. https://genesyscloud.ideas.aha.io/ideas
Regards, V.P.
Josh_Civitareale | 2023-08-29 22:54:40 UTC | #20
Hey VP is that manual clear enabled yet or still in beta?
vpirat | 2023-08-30 17:47:21 UTC | #21
Still in Beta. Should be released in September...
Watch this thread: https://genesyscloud.ideas.aha.io/ideas/DIG-I-118
V.P.
Josh_Civitareale | 2023-08-31 00:17:19 UTC | #22
Thanks for that V.P
It looks like the solution here doesn't fully complete the job https://developer.genesys.cloud/forum/t/web-messaging-clear-local-storage-on-browser-close-but-not-refresh-open-new-tab/14257
If the customer is halfway through the session with the bot it will clear the history in the window but the session is still active
gcmcopn gcmcsessionActive
are the local storage items being cleared
Is there any other items on the list here that would successfully clear the whole session for the customer or is that not possible
https://developer.genesys.cloud/commdigital/digital/webmessaging/messengersdk/localStorage
vpirat | 2023-08-31 07:10:36 UTC | #23
Hi Josh,
I think deleting _actmu key should prevent the user from accessing again the session. To be tested.
Regards, V.P.
Angelo_Cicchitto | 2023-08-31 08:08:43 UTC | #24
@Josh_Civitareale we recommend using the new Clear function that is in Beta right now, not sure if you applied for Beta enrollment: that is the solution here.
Josh_Civitareale | 2023-08-31 23:14:29 UTC | #25
I saw that - we haven't applied but that still requires manual intervention from the end user. This customer is looking at clearing it automatically from a security perspective.
V.P I will test the _actmu - thanks for that
Angelo_Cicchitto | 2023-09-01 04:52:26 UTC | #26
We don't recommend operating with and deleting browser storage variables directly: it's something we don't test & support. Can you summarize what you are trying to achieve (beyond authentication)?
Josh_Civitareale | 2023-09-01 04:56:19 UTC | #27
Hey Angelo,
Appreciate your support (as it is beyond authentication and let me know if you need me to create a new post)
The customer is wanting to clear the chat history and start a new session for the end user after a set period of time (5 hours) due to security reasons for shared devices.
Angelo_Cicchitto | 2023-09-04 11:58:34 UTC | #28
For the interim you could check timestamp of latest message fetched, and react upon that on client with new Clear operation. The productized solution will be included in this Idea once accepted > https://genesyscloud.ideas.aha.io/ideas/DXWMM-I-7
system | 2023-10-04 11:59:19 UTC | #29
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 21312