Caroline Kello

Unfortunately, this would not resolve the issue. 

There are two scenarios here:

• First, let's say name@domain.com is an agent in your system. If someone using their own Entra instance were to create a record with that email address and try to log in, we couldn't limit the person logging in to just end user permissions. It would mean either downgrading the agent record to an end user (which would undoubtedly be disruptive) or creating a new record, and we only allow one user with each email address to exist within an account.
• Second, even if the existing user is already an end user, we can't allow a takeover situation like this to occur — just because the user isn't an agent doesn't mean the data they have access to isn't private. In some cases they could have a long history of tickets, attachments, or custom objects, which the attacker could now access. The attacker could also use their authenticated status to submit tickets, spoofing the identity of your customer in a very believable way.

We are not set up today to combine our identity model with Microsoft's in this way. There is work we need to do before we can treat the true identifier of an Entra user — their Entra-specific ID — as their identity rather than their email.

Thank you again for your engagement and questions. As more folks may see this thread we do want to remind everyone that if you have any questions about configuring your account or using our features to keep your account secure, you can always reach out to our customer support team or your account team for help. We sincerely appreciate your continued feedback and insights for how we can improve our product offerings.

Hello, Caroline from the Zendesk Product Team 👋 The security of your Zendesk account and personal information is of the utmost importance to us here. Thank you for sharing your concerns. We wanted to take a moment to share more details about our decision and update you on our plans. 

In May 2023 a security vulnerability was addressed which could have potentially allowed an attacker to sign in as a Zendesk agent. There was no evidence that this vulnerability was exploited. The fix required linking Microsoft Entra ID tenants to the Microsoft sign-in settings for team members or enabling SAML-based SSO with the Entra ID tenant. That’s the behavior you see today in Admin Center under Account > Security > Team member authentication > External authentication. 

The fix additionally prevents end users from signing in using Microsoft authentication with Entra ID, resulting in them only being able to sign in with their personal Microsoft accounts. 

The vulnerability was a result of Microsoft allowing Microsoft account owners and administrators to set emails to an arbitrary value without any uniqueness, validation or verification. In contrast, Zendesk requires unique emails as identifiers for users and expects the Identity Provider (the Entra ID tenant in this case) to verify users' emails. Accounts have to be linked to a specific Entra ID tenant to ensure you are only working with trusted partners or your own directories.

There’s a possible path forward that we are exploring that would allow Zendesk admins to link Microsoft Entra ID to the Microsoft sign-in settings for end users (same as it works for team members today), but that’s not currently on our 2025 roadmap. Still, this potential future path wouldn’t allow for end users to sign in with any Microsoft business account because of the contradictions above on email uniqueness and verification. 

Thank you again for raising your concerns. We have documented this feedback for us to use in the future however at this time there are no plans to change this course of action, and we are continuously dedicated to providing customers like you the highest level of protection. There are a few open posts with this request, please head over here to continue the conversation and provide more feedback.  Thank you for sharing your concern and for continuing to be a valuable Zendesk customer. 

Hello everyone, Caroline from the Zendesk Product Team👋 The security of your Zendesk account and personal information is of the utmost importance to us here. Thank you for sharing your concerns. We wanted to take a moment to share more details about our decision and update you on our plans. 

In May 2023 a security vulnerability was addressed which could have potentially allowed an attacker to sign in as a Zendesk agent. There was no evidence that this vulnerability was exploited. The fix required linking Microsoft Entra ID tenants to the Microsoft sign-in settings for team members or enabling SAML-based SSO with the Entra ID tenant. That’s the behavior you see today in Admin Center under Account > Security > Team member authentication > External authentication. 

The fix additionally prevents end users from signing in using Microsoft authentication with Entra ID, resulting in them only being able to sign in with their personal Microsoft accounts. 

The vulnerability was a result of Microsoft allowing Microsoft account owners and administrators to set emails to an arbitrary value without any uniqueness, validation or verification. In contrast, Zendesk requires unique emails as identifiers for users and expects the Identity Provider (the Entra ID tenant in this case) to verify users' emails. Accounts have to be linked to a specific Entra ID tenant to ensure you are only working with trusted partners or your own directories.

There’s a possible path forward that we are exploring that would allow Zendesk admins to link Microsoft Entra ID to the Microsoft sign-in settings for end users (same as it works for team members today), but that’s not currently on our 2025 roadmap. Still, this potential future path wouldn’t allow for end users to sign in with any Microsoft business account because of the contradictions above on email uniqueness and verification. 

Thank you again for raising your concerns. We have documented this feedback for us to use in the future however at this time there are no plans to change this course of action, and we are continuously dedicated to providing customers like you the highest level of protection. Thank you for sharing your concern and for continuing to be a valuable Zendesk customer. 

Hello everyone, Caroline from the Zendesk Product Team 👋 The security of your Zendesk account and personal information is of the utmost importance to us here. Thank you for sharing your concerns. We wanted to take a moment to share more details about our decision and update you on our plans. 

In May 2023 a security vulnerability was addressed which could have potentially allowed an attacker to sign in as a Zendesk agent. There was no evidence that this vulnerability was exploited. The fix required linking Microsoft Entra ID tenants to the Microsoft sign-in settings for team members or enabling SAML-based SSO with the Entra ID tenant. That’s the behavior you see today in Admin Center under Account > Security > Team member authentication > External authentication. 

The fix additionally prevents end users from signing in using Microsoft authentication with Entra ID, resulting in them only being able to sign in with their personal Microsoft accounts. 

The vulnerability was a result of Microsoft allowing Microsoft account owners and administrators to set emails to an arbitrary value without any uniqueness, validation or verification. In contrast, Zendesk requires unique emails as identifiers for users and expects the Identity Provider (the Entra ID tenant in this case) to verify users' emails. Accounts have to be linked to a specific Entra ID tenant to ensure you are only working with trusted partners or your own directories.

There’s a possible path forward that we are exploring that would allow Zendesk admins to link Microsoft Entra ID to the Microsoft sign-in settings for end users (same as it works for team members today), but that’s not currently on our 2025 roadmap. Still, this potential future path wouldn’t allow for end users to sign in with any Microsoft business account because of the contradictions above on email uniqueness and verification. 

Thank you again for raising your concerns. We have documented this feedback for us to use in the future however at this time there are no plans to change this course of action, and we are continuously dedicated to providing customers like you the highest level of protection. There are a few open posts with this request, please head over here to continue the conversation and provide more feedback. Thank you for sharing your concern and for continuing to be a valuable Zendesk customer. 

Gotcha, thanks for the additional details! If I'm understanding it correctly it's more that you want to put in an additional layer of friction or verification, and maybe even justification, as to why this is an Expedited Order? Like “Tell me why an Expedited Order is required”. Or is there something specific that a 2FA prompt would achieve here that I might be missing?

Hey Paul, could you give some more detail on how you see this workflow playing out? Would be great if you could step me through what you'd like to see here. Thanks. 

A partir de hoje, a Zendesk está adicionando suporte ao tipo de concessão de credenciais de cliente para clientes OAuth confidenciais. 

Este anúncio inclui os seguintes tópicos:

• O que mudará?
• Por que a Zendesk está fazendo essa alteração?
• O que preciso fazer?

O que mudará?

O tipo de concessão de credenciais do cliente agora está disponível, permitindo que os aplicativos solicitem um token de acesso para acessar seus próprios recursos sem precisar de autenticação do usuário.

O fluxo é iniciado passando um parâmetro client_secret válido para o ponto de extremidade /oauth/tokens com grant_type: client_credentials para gerar um novo token de acesso OAuth . Isso significa que agora você pode gerar um novo token de acesso OAuth especificamente para seu aplicativo, permitindo que você interaja com as APIs do Zendesk de maneira mais eficiente.

Esse tipo de concessão é exclusivo para clientes OAuth confidenciais, garantindo que os segredos confidenciais dos clientes sejam gerenciados com segurança.

Por que a Zendesk está fazendo essa alteração?

Essa atualização nos alinha ainda mais com os padrões OAuth 2.0, fornecendo aos clientes uma autenticação de API mais robusta e flexível. 

O que devo fazer?

Esse tipo de concessão está disponível para você adotar, se desejar. Saiba mais sobre o uso de OAuth com seu aplicativo.

Em caso de dúvidas ou comentários a respeito deste anúncio, visite nosso fórum da comunidade, onde coletamos e gerenciamos o feedback dos clientes sobre os produtos. Para obter assistência geral com seus produtos Zendesk, entre em contato com o Suporte ao cliente Zendesk.

Como anunciado anteriormente, a Zendesk deixará de aceitar e-mail e senha como método de autenticação para solicitações de API em 31 de dezembro de 2025 para todos os clientes. Se você está usando esse método ativamente hoje, deve mudar para o uso de tokens da API ou OAuth antes de 31 de dezembro de 2025 para evitar qualquer impacto devido a essa remoção.

Este artigo contém os seguintes tópicos:

• Por que a Zendesk está fazendo essa alteração?
• Há alternativas disponíveis?
• O que devo fazer?

Por que a Zendesk está fazendo essa alteração?

A segurança de sua conta é a nossa principal prioridade. A capacidade de autenticar solicitações de API com um e-mail e senha é inerentemente insegura, pois as senhas podem ser comprometidas e reutilizadas, e esse método não está mais alinhado com as práticas recomendadas modernas de autenticação de API. Impedir o uso do mesmo e-mail e senha para acesso à API mitiga o risco de acesso não autorizado e alterações em sua conta caso suas credenciais sejam comprometidas.

Há alternativas disponíveis?

Sim. A alternativa mais simples é usar um token da API. Você só precisa atualizar sua solicitação para usar o seguinte formato:

{email_address}/token:{api_token}

Cada token da API pode ser utilizado por qualquer usuário verificado na conta e não está associado a um usuário específico. As permissões são limitadas pela função de usuário associada ao endereço de e-mail fornecido. Saiba mais sobre o gerenciamento de acesso ao token da API.

O Zendesk também oferece suporte a fluxos de autorização OAuth. O OAuth fornece uma maneira segura de seu aplicativo acessar os dados do Zendesk. Para usar a autenticação OAuth, você precisa registrar seu aplicativo no Zendesk. Também é necessário adicionar alguns recursos ao seu aplicativo para dar suporte ao fluxo de autorização OAuth. Saiba mais sobre o uso de OAuth com seu aplicativo e como trabalhar com OAuth.

Saiba mais sobre Noções básicas sobre as diferenças entre tokens da API e tokens de acesso OAuth.

O que devo fazer?

Se tiver a configuração Acesso por senha para APIs ativada, mas não estiver usando o recurso, você pode desativar a configuração com segurança. Você pode encontrá-lo no Centro de administração em configurações de APIs e integrações > > Zendesk API > > Senha de acesso. Após a desativação, a configuração será removida da página.

Uso de tokens da API

Usar tokens da API é a alternativa mais simples e, na maioria dos casos, a pessoa associada ao endereço de e-mail que está sendo usado para a autenticação da API deve ser capaz de substituir a senha por um token em seu aplicativo fazendo o seguinte:

1. Na Central de Administração, clique em Apps e integrações na barra lateral, depois selecione APIs > Zendesk API > Configurações.
2. Ative o acesso por token se ainda não estiver ativado e clique em Adicionar token da API.

3. Clique em Copiar para copiar o token da API.
   

4. Navegue até seu aplicativo. 
5. Substitua a senha pelo token da API usando o seguinte formato:

   {email_address}/token:{api_token}

6. Após a atualização de seus aplicativos, volte para a Central de administração > Aplicativos e integrações > APIs > API do Zendesk > Configurações e desative Acesso por senha.

Uso de tokens de acesso OAuth

Você pode autenticar solicitações de API usando um token de acesso OAuth como token do portador no cabeçalho de autorização da solicitação. Saiba mais sobre como trabalhar com OAuth. Se seu aplicativo requer que os usuários concedam acesso ao seu aplicativo, você pode implementar o fluxo de concessão de código de autorização OAuth.

Em caso de dúvidas ou comentários a respeito deste anúncio, visite nosso fórum da comunidade, onde coletamos e gerenciamos o feedback dos clientes sobre os produtos. Para obter assistência geral com seus produtos Zendesk, entre em contato com o Suporte ao cliente Zendesk.

It's covered in this FAQ: 24 hours.

Hey Murph Murphy,

This doesn't align with the expected behavior, and we're not able to recreate what you're seeing either. If you could please contact our Customer Support so that we can figure out what's going on here. 

Thanks, Caroline