Authenticating end users in messaging for the Web Widget and mobile SDK

Return to top

86 Comments

  • Thomas Verschoren
    Community Moderator

    The Developer Documentation links to https://developer.zendesk.com/documentation/zendesk-web-widget-sdks/sdks/web/sdk_api_reference/#authentication which currently does not exist.

    Hw do we use the zE Javascript object to enable the JWT call?

    zE('messenger', ...);

    0
  • Mick O'Donnell
    Zendesk Product Manager

    Hi Thomas! Apologies for the delay, the developer documentation has now been updated.

    1
  • Thomas Verschoren
    Community Moderator

    Awesome, appreciate it!

    0
  • Alex

    Hi team,

    It looks like we've managed to implement authentication for messaging since the end-user is not prompted to provide their name and email address.
    BUT in the user profile, the email field is still empty.

    Here is the code that we use to generate the token:

    import jwt
    secret = "******************************************************************************"
    
    token = jwt.encode({'external_id': "123456aa",
            'email': "some@email.com",
            'ext': "1674836085",
            'name': "Jon Watson 1985",
            'scope': "user"
        },
    secret,
    algorithm='HS256',
    headers={'alg': "HS256", 'typ': "JWT", 'kid': "app_61f2c451a3844800edf1e7d3"})
    
    
    print("------")
    print(token)
    print("------")
    print(jwt.decode(token, secret, algorithms=["HS256"]))
    print("------")

    eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6ImFwcF82MWYyYzQ1MWEzODQ0ODAwZWRmMWU3ZDMifQ.eyJleHRlcm5hbF9pZCI6IjEyMzQ1NmFhIiwiZW1haWwiOiJzb21lQGVtYWlsLmNvbSIsImV4dCI6IjE2NzQ4MzYwODUiLCJuYW1lIjoiSm9uIFdhdHNvbiAxOTg1Iiwic2NvcGUiOiJ1c2VyIn0.RcOsjkbcil5YcmBnZpzsC3do0Q7nYY9-S_P_d-8rJ5Y

    Thank you!

    1
  • Alex

    Also, the user id is not displayed in the custom ticket field.

    0
  • Mick O'Donnell
    Zendesk Product Manager

    HI Alex, this is a currently limitation of the product. We working on an improvement to Agent Workspace to add this information in the near future.

    1
  • Kevin Konings

    Hello!

    We have been waiting for this feature, as we intend to use it to link Zendesk Messaging users to users in our app, so we can e.g. show additional information to our team through a Zendesk app or similar means. For this link, we are trying to use the external ID, which would be our app user ID.

    However, we have not been able to achieve that so far:

    • when a user creates their first ticket and has not existed in Zendesk before, there seems no way to access their external ID through the API as far as I can tell (the field external_id was always null in our tests when I call /api/v2/users/{ZENDESK_USER_ID} for the newly created Zendesk Messaging user). The email address is null as well, despite being submitted as part of the JWT.
    • when we instead create a user before their first usage of Zendesk Messaging and upon registration in our app through the API, and set both the external_id and their email, and then authenticate with a user using these same values in the JWT as external ID and email address, a completely new user is created instead of Zendesk authenticating that user as the one we previously created.

    Especially the latter behaviour seems like it goes beyond being a limitation - effectively Zendesk seems to create two users using the same email address. This doesn't seem like it would be an issue exclusive to our workflow, but instead also creating users that e.g. have handed in tickets before using that email address.

    So my questions are:

    • should the external_id be accessible through the API, or can we create a user beforehand with a specific external ID? If not, is this on your roadmap?
    • is that behaviour regarding creating more than one user with the same email address intended, or part of the current limitations? If so, what would be the recommended approach in dealing with this?
    10
  • Jorge Paez

    Hi team, is there an estimated timeframe to release the Restricted Articles Access in Messaging for authenticated users?

    • Restricted Guide articles. Guide articles that require authentication will not be available to users initially, even if they are authenticated. We will make additional improvements to the messaging product to enable users to view Guide articles that require user authentication. Articles that do not require user authentication are not impacted.
    2
  • Clayful

    Hey Kevin Konings wondering if you ever heard back about your second point there?

    We're running up against the same problem which defeats the purpose of authenticating the user if we're not able to attach them to the existing user and map their history accordingly. Is this a known limitation or a bug?

     

     

    1
  • Kevin Konings

    Hey Clayful, sadly nothing yet, I've messaged Support a few days ago and they told me they'll come back to me.

    I 100% agree with you, this is not really authentication if it doesn't authenticate as the same user our agents already interacted with in previous tickets.

    1
  • Santiago Gandolfo
    Community Moderator

    Hey Kevin Konings, have you received any news?

    0
  • Matt Harrell

    To add to this shortcoming from Ken Millar, if our agents can't see the email address of the end user it severely slows them down from doing effective troubleshooting on our internal staff dashbaord to track information about the user. 

    A timeline of these enhancements would be really appreciate ZD team. Thanks! 

    3
  • Jen Cole

    We haven't implemented this yet. When you say it doesn't bring over the email address of the customer on the ticket, what information does it bring over? Or is the user information just blank? I'd love to see a screenshot of the whole ticket if someone would like to share. Is there a way to merge the user or add the customer's user info to that ticket? Just curious on what you all are using as a work around until Zendesk fixes this limitation? Your comments make me hesitant to implement this feature even though we have been looking forward to it. Thanks for your help!

    4
  • Clayful

    Hey Jen,

    Frankly - it's a mess 😅

    We're using the SFDC ID as the external field which for some reason ends up getting populated as the Web User ID (but doesn't get recognized as the external ID or tied to the existing user) - screenshot below. 

    This is good news because at least we *can* actually then merge the user with the existing user by searching for this ID --  so It really only affects the agents the first time the user chats in. For subsequent chats once they're merged, the original user is now the one that pops up. Great.

     

    The issue is now the bot behavior is EXTREMELY wonky! It is quite unclear when the bot starts the convo vs when it doesn't and what messages happen if you're within business hours or not. Some of the bugginess gets resolved if you open the chat in a new window or refresh -- but of course this is not a great look for our users. This is now our biggest issue since the email issue above can be "hacked" around and dealt with internally while this is just a terrible experience for our end users... 

    I'm also awaiting a response from the support team so will comment on here once I hear back! 

    3
  • Kevin Konings

    Hey Jen Cole,

    when we tried to implement this feature two weeks ago, users were created only with the name submitted through the JWT. Neither the email address nor the external ID we submitted were visible in the agent interface nor through the User API. Here's a screenshot of how it looks like (so basically only the name is filled out):

    Our plan was to fill user information when users sign up in our app, and then authenticate these users in Zendesk Messaging through their external ID or email address. However, the user created here already had an end user with the same email address and external ID they used for authentication, and Messaging still created a new user instead.

    I haven't gotten feedback from Zendesk yet on my questions above, and hope this Mesaging behaviour is not intended because the way it is makes the feature pretty much useless to us.

    3
  • Tim O'Mahony

    We're seeing the exact same thing as Kevin Konings and this is really preventing us from moving to messaging. It's likely without a fix we'll go with chat here. 

    The second issue we're seeing is even if you use the created user, it ends up creating a further duplicate user. 

    3
  • Jen Cole

    Thank you Ken Millar and Maria Barrera! That was very helpful. Looks like we will need to wait to implement this when the email address/user information can be authenticated and then brought over into the ticket created. 

    Mick O'Donnell, will we be notified when the feature is updated with the user information/email address of the user is brought over into the ticket creation?

    We receive tickets through the messaging channel inside and outside of business hours. If the ticket comes through as a web user and possibly a user's name, but no email address, then it would be pretty hard to track down the correct user without the email address as well (for those tickets that come in outside business hours). Email addresses are our unique identifier for customers and needed to link all user data together. We are very anxious for the update to this feature so we can implement it. Thanks! 

    1
  • Ovidiu Varo

    Hello guys,

    We are having a similar issue regarding authentication. We are using loginUser(jwt) and the only data saved and retrieved on successCallback is the external_id.

    Note that the jwt contains also a name and an email.

    1
  • Prakruti Hindia
    Zendesk Product Manager

    Thank you all for writing in and providing feedback. We want to provide more visibility into our future improvements. 

    Our plan is to surface external_id and name as part of User profile. They are critical for identifying your customers. This is planned to be rolled out in early Q2. Displaying email will follow soon.

    In the short term, we will be displaying external_id in the conversation. This will be rolled out in a couple of weeks. 

    We will drop an update in the Release Notes as well as on this thread once it is rolled out. 

    - Prakruti

    1
  • Kevin Konings

    Hey Prakruti Hindia

    thanks for the feedback!

    What about the issue of creating duplicate users with the same email that me and others are facing? Is this a bug right now or will this also be part of these improvements in early Q2?

    Best

    1
  • Flash Coffee Marketing Team

    Hello Prakruti Hindia,

    I want to ask a question. Is it possible to put tags on the payload when we generate the JWT token and be visible on Agent Workspace?
    If it's not possible. Do you have any workaround how to send tags on Agent Workspace via Zendesk Messaging (Flow Builder)? so we don't need to input the value that we need manually from the ticket fields

    Thank you

    0
  • Joshua Lam

    Hi,

    Will there be an expiry if we don't pass in `exp` in the JWT payload? If so, what will be the duration?

    Thanks!

    0
  • Prakruti Hindia
    Zendesk Product Manager

     

    What about the issue of creating duplicate users with the same email that me and others are facing? Is this a bug right now or will this also be part of these improvements in early Q2?

    We will be merging users , if there are users already existing in the system with same external id. This will be part of the improvements coming early Q2. 

    I have also requested other Product Managers to respond to questions on tags and expiry. They will be responding soon. 

    - Prakruti

    0
  • Prakruti Hindia
    Zendesk Product Manager

    Important update: We have rolled out a small fix which will surface external id when agent hovers over the authentication badge. 

    We will continue to focus on associating external_id with the User profile.

    2
  • Thomas Verschoren
    Community Moderator

    That's nice!

    0
  • Mick O'Donnell
    Zendesk Product Manager

    Hi Joshua!

    In response to this question: "Will there be an expiry if we don't pass in `exp` in the JWT payload? If so, what will be the duration?", no expiry is set if you don't provide one in the JWT. So you need to think about the value that makes sense for your security policy. 

    0
  • Mick O'Donnell
    Zendesk Product Manager

    Hi Flash Coffee!

    Currently it's not possible to insert additional claims in the JWT payload, and use this data is other parts of the system, but we are currently exploring options to allow customers to achieve this. The JWT itself may useful for client-side contextual data, but this is likely to be just one part of the solution. Today, you need to input the values that you need manually, sorry.

    0
  • Abe

    Hi Zendesk team,

    What is the proper value to use for the `kid` property in the JWT header?  Is it the App ID, Client ID, or none of these?

    Thanks --

    Abe

    Edit: I got an answer to this question here: https://support.zendesk.com/hc/en-us/community/posts/4421945067546-Having-issue-when-trying-to-authenticate-/comments/4446353121434#community_comment_4446353121434

    0
  • Santiago Gandolfo
    Community Moderator

    Hi Prakruti Hindia,

    Has the new fix that you mentioned made it so that when the user sends a message from the widget and their external_id is set in the JWT, if there already existed a user with that same external_id then it wouldn't create a new one and instead asign that ticket to that "old" user?

    Cheers,

    Santiago

    3
  • Joshua Lam

    Will there be any issues if we call loginUser when the user has already been authenticated? We are seeing a large number of 400/401 errors from the loginUser calls but see that end users are showing as authenticated on the Zendesk/agent side

    1

Please sign in to leave a comment.

Powered by Zendesk