Data do anúncio | Início da implementação | Fim da implementação |
27 de agosto de 2024 | 27 de agosto de 2024 | 17 de fevereiro de 2025 |
Em concordância com as práticas recomendadas do OAuth 2.0, a Zendesk não aceitará mais concessões implícitas e de senha para tokens de acesso a partir de 17 de fevereiro de 2025, apenas para o Zendesk Support. Essa remoção não se aplica ao Chat, Sell ou Sunshine.
Recomenda-se que os clientes mudem para o Fluxo do código de autorização ou tokens da API assim que possível devido à insegurança dos tipos de concessão mais antigos.
Este anúncio inclui os seguintes tópicos:
O que está mudando?
Em 17 de fevereiro de 2025, a Zendesk deixará de aceitar o uso de concessões implícita e de senha como tipos de concessão válidos para a obtenção de um token de acesso. Os clientes terão que migrar para o tipo de concessão Fluxo de código de autorização ou tokens da API. A partir de hoje, qualquer pessoa que desejar usar o OAuth 2.0 para autenticar chamadas à API pode usar apenas o tipo de concessão Fluxo de código de autorização.
Por que a Zendesk está fazendo essa alteração?
De acordo com as práticas recomendadas do OAuth 2.0, as concessões implícita e de credenciais de senha do responsável pelo recurso (senha) agora são consideradas inseguras e não são permitidas pela prática recomendada de segurança do OAuth 2.0.
A concessão implícita era recomendada porque retornava diretamente o token de acesso sem precisar de uma etapa extra de código de autorização. Essa ação era necessária para clientes OAuth públicos que não podiam armazenar com segurança o client_secret. Esse método agora é desaconselhado devido a riscos de segurança, pois envia tokens de acesso por redirecionamentos HTTP sem confirmação do cliente. Ele foi substituído pela Concessão de Código de Autorização com Chave de Prova para Troca de Código (PKCE), que é mais segura. A concessão de senha é um método desatualizado para obtenção de token de acesso através do uso das credenciais de um usuário. Esse método agora é desaconselhado porque requer que o aplicativo de cliente manipule a senha do usuário e a envie para o servidor de autorização, o que resulta em uma maior superfície de ataque. Além disso, ele também não é compatível com a autenticação de dois fatores.
O que devo fazer?
Se estiver usando a Concessão implícita, você precisa:
- Atualizar sua chamada atual para o ponto de extremidade
/oauth/authorizations/new
e usarresponse_type: code
em vez deresponse_type: token
e incluir os parâmetrosredirect_uri
estate
se ainda não estiverem presentes. Se estiver usando um cliente público, inclua também os parâmetroscode_challenge
ecode_challenge_method
. Consulte Geração do valor code_challenge para obter mais informações sobre como gerar umcode_challenge
. - Atualizar ou implementar um novo ponto de extremidade de retorno de chamada em seu cliente OAuth. Consulte os detalhes da implementação da concessão de código de autorização em Uso da autenticação OAuth com seu aplicativo e Uso de PKCE para tornar os tokens de acesso do OAuth do Zendesk mais seguros para obter mais informações. Para clientes públicos ou se estiver incluindo um
code_challenge
na chamada/oauth/authorizations/new
, certifique-se de incluir ocode_verifier
ao chamar o ponto de extremidade/oauth/tokens
. - Atualize seu cliente em
/admin/apps-integrations/apis/zendesk-api/oauth_clients
na Central de administração para incluir a URI de redirecionamento nova/atualizada, caso ela ainda não esteja presente. - Depois de testado e validado, aconselhamos atualizar o Tipo de cliente em
/admin/apps-integrations/apis/zendesk-api/oauth_clients
na Central de administração como público ou confidencial para que possamos oferecer o mais alto nível de segurança.
Se estiver usando a concessão de senha, precisará usar um token da API .
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.