Búsquedas recientes

No hay búsquedas recientes

Configuración de la autenticación de los usuarios finales para la mensajería

image avatar

Aimee Spanier

Zendesk Documentation Team

Editado 20 mar 2025

3

3

167 comentarios

Fecha
    Más recientes
      image avatar

      Ivan Genchev

      Hello Everyone,

      I would like to share our experience with authenticating users and the disappointment following.

      We are supporting tens of brands and authenticating users who log in in our websites and open a chat (messaging) via the widget. Each of our brands has a unique set of numbers as External ID. Users can register in any of our brands with the same email and they will be generated a different External ID for each Brand. This information is provided to Zendesk and a user is created in Support.

      Sounds simple enough, however, once a user registers in more than 1 of our brands, they are forbidden by Zendesk to initiate a chat in the 2nd, 3rd, or any other brand after the first registration. This is due to the 409 error. The “solution” in the article is to manually or via API, remove the original user so that they can be registered anew and open a chat in the new brand, but this does not help as this would need to happen each time the user tries to open a chat in the original brand or in a new one.

      For some reason, Sunshine Conversations cannot comprehend the same Email, being related to more than one External ID (or, since the External ID is the main identifier, more than 1 External ID cannot be related to the same Email). Which could make sense in some cases, but not for a platform that offers Multi-Brand usage.

      “Solution” 1: To not pass our external IDs as External_ID, but pass the email as an External_ID. In this case, no matter where the user registers/logins, we will pass the same External_ID to Zendesk and there will be no conflict. Sounds good, the first registration is successful. The second registration (to a 2nd Brand) is also successful. However, users can view the history of the first brand in the chat of the second brand. This is absolutely baffling. Why would this even be a feature, why would a user need the history of Brand1 in the chat of Brand2? This can be a huge breach of trust in the customer. The answer to this question is that Sunshine Conversations just works like that..

      “Solution” 2: What we are currently doing: Authenticate users as usual, and create a fallback for when a user encounters the 409 error (registered in more than 1 brand and initiates a chat). The fallback authenticates the user with the External ID, however instead of using the same Email, it creates a new email for them which looks like this: External_ID+Email (ex. 123456789+example@email.com). This is made so that each new registration in another brand will have a different email, so that Zendesk can allow them to be registered anew, instead of blocking them. 
       - So now if 1 user, with the email example@email.com registers in 3 Brands, he will have 3 separate users in Zendesk:
      One as example@email.com , Second as 123456789+example@email.com and Third as 987654321+example@email.com . 
      - Great, at least they can initiate chats now. The issue? Only the original user can be used for email communication, as he is the only one with an actually legit email. So any email sent from/to Brand2 and Brand3 will go to the user for Brand1. Any chat communication will be saved in the interaction history for the respective user, but emails will never be seen as they should.
      - So if the user comes in Brand3 and says “check the email communication”, you cannot simply view the Interaction History, you have to open an entirely separate user and check the email communication there.
      - Sometimes, the original email example@email.com and an email such as 123456789+example@email.com will be added to the same user. In many of these cases, the 123456789+example@email.com is marked as Primary in the user's Zendesk profile. For another unknown reason, Zendesk does not allow us to send emails to the Secondary email, and it is only used for identification. So even if you type out example@email.com in the “Requester field”, it will recognize the user and automatically change the Requester to the primary email 123456789+example@email.com . This is obviously a non-existent email, so the sending will fail. 
       The only solution to this is to go inside the profile of the user, mark the example@email.com as verified and then change it to primary. Only then can an agent send an email to this customer.

      The other “Solution” would be to not authenticate users at all but you can imagine how that is not exactly a solution.

      After thorough communication with Zendesk Support, it seems this is our only workaround which includes all these pain points that force agents to do unnecessary manual work.

      To us this seems as a major flaw for a platform that support multiple brands and I believe a solution to this should be of highest priority. At this point, the platform is basically punishing the customer for having a registration in more than 1 brand with the same email, and any workaround feels unpolished and irritating to agents for the manual steps they need to take.

      I look forward to any feedback or other possible solutions that you may offer.

      Thank you.

       

      0

      image avatar

      Anthony Plaza

      Hello everyone, specific question.
      Was the email authentication issue resolved?
      I send the email, external_id, and other information in my JWT, but I've read all the messages since 2022, and it's April 2025, and I'm not sure whether to add the "email_verified" field since they say it duplicates the number of users.
      Please confirm if this new feature is working correctly.

      0

      image avatar

      John Witt

      8329079355674 I have found that Zendesk requires an email_verified status to see non-public articles. I send the userid of the current user ($AJAX user.me) as the external_id, email_verified true, and the email to create the token. The problem with this is it will always create a new user since external_id doesn't exists, so one workaround is to prepopulate every user's external_id with their user_id before testing Messaging. I prefer make.com and powerautomate, but I assume any integration tool or ZIS could do it. Worst case is you have two users and need to merge.

      0

      image avatar

      Pierre

      Thanks 1263169242090 

      Just to make sure I understand it correctly. 

      Can I pre-populate the external id in zendesk or do I need to do this using an API?

      My assumption is that the bot can automatically recommend articles based on the questions the end user asks. Or do we still need to pre-configure recommended articles for certain questions within the bot?

      Thanks again for your help.

      0

      image avatar

      John Witt

      My articles were private, and the only way around this is to use email, external id, and email_verified=true. However, if you don't pre-populate the external id before doing this, it will create a new user (you'll need to merge or delete the other one).

      0

      image avatar

      Pierre

      1263169242090, thanks for you response. 

      We did get he web widget to work by using the backend service. We use the JWT token as described, but still the bot does not return any useful articles. Only when we make our articles public it works as it should. 

      Is there a setting somewhere in Zendesk that will allow the bot to return articles without us having to make all our articles public facing?

      0

      image avatar

      John Witt

      8329079355674 To properly encode, you need the algorithm of H256, the correct kid (from Account;end user security), and type of JWT. The payload really just needs scope=user and external_id, but I use email, name, and verified. 

      I recommend using one of the JWT encoder/decoders and hardcode the value into the ZE call until you get it working. You might be missing a parm to encode in your encoder. I found I was getting 401 Login issues as I was using the wrong kid to encode.

      0

      image avatar

      Pierre

      Hi,

      We have build our backend service that will generate the JWT tokens. We have followed the instructions as per the steps in this document. 

      We generate a JWT token with the required claims and then use the token in Postman as a Bearer token to test it. But we keep on receiving the status code 401. 

      Is there anything else we should have configured on Zendesk apart from the Signing key in the Messaging section?

      Or should the issuer and audience properties of the JWT token be specific values?

      0

      image avatar

      John Witt

      1265194314089 Did you ever get an answer to this? I am seeing the same. It's almost like I want to add more logic - get the user via email, and if they don't have an external id, then create one using their user id, then send the JWT request. I think the issue is it sees there' no external_id, but can't use the email since it's already in use, and doesn't just assume the one with the correct email address is correct.

      0

      image avatar

      Tamir Bashkin

      Hey, check out this app: https://www.zendesk.com/marketplace/apps/support/1066145/messaging-and-help-center-authentication . It helps authenticate Help Center users on the messaging widget. Highly recommended! :)

       

      0

      Iniciar sesión para dejar un comentario.

      Detalles de la cuenta

      Inicie sesión para ver los detalles

      Inicie sesión para ver los detalles de su cuenta de un vistazo

      Iniciar sesión

      CONTENIDO ADICIONAL