"Failed to identify user for token" for Genesys prod development config for authenticated messaging

Web Messaging
1 
{
  "message": "Failed to identify user for token: c062d4f61bfddd0611ba4a3de5e488be deploymentId: afead3f5-70e7-4730-ae2e-1b70a9e46f0a",
  "code": "unauthorized",
  "status": 401,
  "contextId": "995eebaf-47f8-47c4-9094-9abe1be8a2b7",
  "details": [],
  "errors": []
}

I got above error when calling "https://api.mypurecloud.de/api/v2/webdeployments/token/oauthcodegrantjwtexchange" to exchange authCode for token for production Genesys cloud deployment.
Here are 2 important facts:

  1. But this request is a success for dev deployment ID. The following difference between dev and prod are carefully examined and they are all correct: client id, client secret, deployment id, and discovery URI

  2. I use curl to make request for production Genesys development and it is a success. In CURL request, I didn't provide journeyContext in POST json payload. If I do, this request will fail.

curl -X POST -H "Content-Type: application/json" \
  -d '{
    "deploymentId": "afead3f5-70e7-4730-ae2e-1b70a9e46f0a",
      "oauth": {
          "code": "0ac6db5f-52ff-42c1-88b0-18d9e095abc8",
          "redirectUri": "https://stage-app.spotnana.com/"
      }}' \
    https://api.mypurecloud.de/api/v2/webdeployments/token/oauthcodegrantjwtexchange

Above CURL will successfully return jwt token for production since I didn't put journeyContext in payload. If I do, the request will fail with the error above.

What do you think could be problem?
A related thread is here, but this bug seems solved: Integrate Messenger with Okta for identity management - #6 by vpirat

2

Hi,

Can you tell which provider you are working with ?
JourneyContext payload is not involved in the authorization phase itself. It's "just" contextual data.

Could you provide and example (contexId) of a failing request in prod and a successful one in prod ?

Regards,
V.P.

1 Like
3

Any JourneyContext in the payload will result the token exchange failure. There is no specific one.

For example, this payload result failure:

{
  "deploymentId": "afead3f5-70e7-4730-ae2e-1b70a9e46f0a",
  "oauth": {
    "code": "8e352b1e-da38-4d06-9691-d89402442d52",
    "redirectUri": "https://stage-app.spotnana.com"
  },
  "journeyContext": {
    "customer": {
      "id": "d5f271c5-9f3b-4e0d-9b33-e58a4eb252e1",
      "idType": "cookie"
    },
    "customerSession": {
      "id": "f4eb10b0-1170-11ef-a3cc-85f888b40ba1",
      "type": "web"
    }
  }
}

Here is the response:

{
    "message": "Failed to identify user for token: 0aa359ab764a1b05a8e2c1b6a06f3eca deploymentId: afead3f5-70e7-4730-ae2e-1b70a9e46f0a",
    "code": "unauthorized",
    "status": 401,
    "contextId": "952661b6-4661-4924-be0a-c9719b344a10",
    "details": [],
    "errors": []
}

Is it my IDP issue? Is there other Genesys flow after the token exchange will result in this failure? I am using AWS Cognito as IDP. Here is my discovery URL: https://cognito-idp.us-west-2.amazonaws.com/us-west-2_hi8Rvgc0Y/.well-known/openid-configuration

4

Thanks for your feedback.

I could see the following error from your last test on code exchange: unauthorized_client which means from AWS doc:

Client is not allowed for code grant flow or for refreshing tokens.

See Token endpoint - Amazon Cognito

So there's either a config issue on IDP side in prod, either an issue in the /authorization request (parameter mismatch, wrong parameter, etc).

  • Check that the Authorization Code grant type is configured in the Cognito application.
  • Make sure the redirect_uri is exactly the same as the one registered in Cognito.
  • Check if requested scopes are configured and supported

The best approach here is to try to test manually the code exchange with Cognito using the http endpoint listed in the discovery document.

POST /token
Content-Type: application/x-www-form-urlencoded
authorization: Basic base64(<clientId>:<secret>)

grant_type=authorization_code&redirect_uri=<redirect_uri>&code=<exchange_code>

See OpenID doc

You may want also check logs on AWS side.

As stated previously, Journey payload is not involved in the authorization process. Including it or not should not matter.

By googling a bit, I could see that some people struggled a bit with redirect_uri:

Hope this helps,

Regards,
V.P.

5

Hi,

Have you been able to sort this out ?

Regards,
V.P.

6

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