Para configurar novos métodos de autenticação para conectores de dados, vá para Configurações > Integrações > Autenticação e clique em Adicionar token.
Você tem duas abordagens principais para configurar um token: conectar um provedor pré-configurado ou criar um token personalizado:
Conectando um provedor pré-configurado (OAuth)
Oferecemos fluxos OAuth pré-configurados de 3 etapas para provedores suportados (como Salesforce, HubSpot e Attio) para tornar a autenticação rápida e fácil.
Para conectar um desses provedores:
Vá para Configurações > Integrações > Autenticação e clique em Adicionar token.
Selecione o provedor desejado no menu suspenso.
Você será redirecionado para a página de autorização do provedor. Revise as permissões solicitadas e clique em Confirmar (ou Permitir) para autorizar a conexão.
Quando o fluxo OAuth for concluído, seu novo token de acesso aparecerá automaticamente na sua lista de tokens.
Clicar no token recém-criado exibirá sua configuração. Como esta é uma integração pré-configurada, apenas os campos Nome e Descrição são editáveis. Você também verá:
API URL: A URL base para usar ao fazer chamadas API para este provedor em seus conectores de dados. Você pode copiar rapidamente usando o ícone Copiar para a área de transferência.
Escopo: Uma lista somente leitura das permissões concedidas ao token.
Reautenticando um token
Se um token for desativado ou quebrado no lado do provedor, não é necessário excluí-lo e começar de novo. Basta abrir os detalhes do token e clicar no botão Reautenticar no canto superior direito. Isso o levará novamente pelo fluxo OAuth e atualizará automaticamente seu token existente, garantindo que seus conectores de dados conectados continuem funcionando sem atualizações manuais.
Criando um token personalizado
Se você precisar se conectar a um serviço que não está incluído na lista pré-configurada:
Vá para Configurações > Integrações > Autenticação e clique em Adicionar token.
Selecione Personalizado.
Em seguida, selecione o Tipo de token que deseja criar no menu suspenso.
Tokens de texto
Tokens de texto são tokens estáticos. Você pode definir o nome do token, descrição, valor, prefixo do token e a chave para o cabeçalho da requisição que contém o token, que será inserido na requisição do conector de dados.
Tokens de requisição HTTP
Tokens de requisição HTTP são dinâmicos. Você configura uma requisição HTTP para seu Endpoint de Autenticação que atualizará o token quando necessário. Esses tokens devem ser testados na interface de usuário de Token de Autenticação antes de serem salvos. Você pode definir o nome do token, descrição e os campos que afetam a requisição em si. Estes são o método da requisição HTTP, URL, cabeçalhos HTTP e quaisquer pares chave-valor.
Você deve testar o token clicando em Testar requisição e então especificar a localização do token na resposta, o prefixo do token e a chave para o cabeçalho da requisição.
Se um token de requisição HTTP for atribuído a um Conector de Dados, o conector usará o token mais recentemente obtido para suas requisições. Se uma requisição retornar uma resposta 400, 401 ou 403, o token será atualizado enviando uma requisição HTTP para a URL do Endpoint de Autenticação especificada. A requisição original do Conector de Dados será então tentada novamente usando o token recém-obtido.
Tokens de requisição HTTP são atualizados automaticamente pelo Intercom para manter os conectores de dados funcionando. Essas atualizações acontecem em segundo plano sem qualquer ação humana e podem aparecer como atualizadas por “System” ou “Fin” para indicar uma atualização automática.
Nota: Se seu servidor estiver retornando um 200 para uma resposta de acesso negado, não atualizaremos o token. Você precisará atualizar seus servidores para retornar um 400, 401 ou 403 neste caso.
Se houver um problema ao atualizar um token, o problema será registrado na aba "Logs" do conector de dados.
Tokens de requisição OAuth
Requisições OAuth permitem solicitar e atualizar tokens fazendo uma requisição POST com o formato OAuth client credentials grant.
Por favor, forneça o url, client_id, client_secret e o campo opcional scope. Selecione o formato da requisição JSON ou Form Encoded com base na configuração do seu servidor de tokens.
Uma prévia do cabeçalho e corpo da requisição será exibida.
Clique em Testar requisição depois de preencher todos os campos obrigatórios.
O Intercom procurará o token na resposta no caminho access_token.
Salve o token assim que o teste for aprovado.
Semelhante ao token de requisição HTTP, o sistema realizará uma atualização do token se uma requisição do conector de dados receber uma resposta 400, 401 ou 403.
Tokens de requisição OAuth são atualizados automaticamente pelo sistema quando necessário. Essas atualizações não são acionadas por um administrador humano e podem aparecer como atualizadas por “System” ou “Fin” para indicar uma atualização automática.
Tokens de usuário
Tokens de usuário permitem autenticar conectores de dados usando um token definido pelo usuário. Esses tokens são criados e atualizados por sistemas de terceiros. Um dos exemplos mais populares desse tipo de token é o JSON Web Tokens (JWT).
JWT é uma forma segura de verificar a identidade do usuário. Agora você pode usar esse novo tipo de token de autenticação para proteger seus conectores de dados. Isso permite uma comunicação mais flexível e segura entre seus sistemas e o Intercom.
Use o token em um conector de dados
Depois que seu tipo de token for criado:
Vá para Configurações > Integrações > Conectores de dados e abra o conector que deseja configurar.
Selecione a aba API.
Na seção Authentication tokens, selecione seu token no menu suspenso.
Criando e atualizando tokens de usuário
Todo o gerenciamento de tokens de usuário é feito por sistemas de terceiros.
Intercom('boot', {
app_id: 'abc12345',
email: 'john.doe@example.com',
created_at: 1234567890,
name: 'John Doe',
user_id: '9876',
auth_tokens: {
security_token: 'abc...' // JWT
}
});
Esses sistemas de terceiros também são responsáveis por atualizar o token de segurança e atualizá-lo periodicamente.
Intercom('update', {
app_id: 'abc12345',
auth_tokens: {
security_token: 'bcd...' // JWT
}
});
Intercom('setAuthTokens', {
security_token: 'abc...' // JWT
});
# Swift
Intercom.setAuthTokens({
security_token: 'abc...' // JWT
});
# Kotlin
Intercom.client().setAuthTokens({
security_token: 'abc...' // JWT
});
Suporte a múltiplos tokens
Você pode anexar vários tokens a um único Data connector. Cada token anexado deve ser configurado com uma chave de cabeçalho única (por exemplo, Authorization, X-API-Key). Todos os tokens anexados serão enviados com a solicitação.
Essa configuração permite que você acione Data connectors usando esse token - seja através de Workflows ou Fin. O Data connector continuará funcionando mesmo se o valor do token for atualizado, pois será atualizado em tempo real para garantir autenticação ininterrupta.
Para usar um JWT por usuário com um Data connector, crie um token de autenticação ‘User’ e forneça seu valor atual via auth_tokens (por exemplo, Intercom('setAuthTokens')), em vez de depender do Messenger intercom_user_jwt.
Verificação de e-mail com código de uso único (OTP)
Verificação de e-mail para Data connectors com OTP oferece uma etapa adicional de verificação antes que um Data connector seja usado, exigindo que os clientes verifiquem sua identidade por meio de um código único e sensível ao tempo enviado por e-mail.
Esse método adiciona uma camada extra de segurança além dos tokens de autenticação do usuário (por exemplo, JWTs). Quando ativado, os clientes devem completar o processo de verificação por e-mail antes que um Data connector possa prosseguir. Isso ajuda a garantir que apenas usuários autorizados possam realizar operações sensíveis e previne o uso indevido de workflows automatizados.
Autenticação do cliente para data connectors
A autenticação do cliente permite verificar a identidade do cliente antes que um data connector seja executado. Diferente da autenticação por token API (que protege a comunicação servidor a servidor), a autenticação do cliente confirma a identidade do usuário final — garantindo que apenas clientes autorizados possam acionar conectores sensíveis.
As regras de autenticação são configuradas em Configurações > Workspace > Segurança > Autenticação do cliente e se aplicam a todos os data connectors que têm autenticação ativada. As regras podem ser definidas por canal e por público.
Uma regra de fallback cobre todos os canais e públicos não especificados, garantindo que todo conector autenticado esteja sempre protegido.
Novo workspace
Quando um novo workspace é criado, a regra de autenticação de fallback é automaticamente definida para Email OTP. Isso cobre todos os canais e públicos não especificados por uma regra mais específica.
Adicionando uma regra
Quando você cria uma nova regra de canal ou público, um método de autenticação padrão é aplicado com base no tipo de canal:
Canal | Método de verificação padrão |
Messenger (web, iOS, Android) | Segurança do Messenger (JWT) |
Todos os outros canais | Sem verificação (regra de fallback se aplica) |
Métodos de verificação
Dois métodos de verificação estão disponíveis:
Email OTP — envia um código de uso único para o endereço de e-mail do cliente. O cliente deve inserir esse código antes que o conector seja executado. Veja Conectores de dados seguros com código de uso único para detalhes de configuração.
Segurança do Messenger (JWT) — usa sua verificação de identidade existente do Messenger (User token). Requer que a segurança do Messenger com JWTs esteja configurada. Veja User tokens acima.
Dica: A segurança do Messenger (JWT) oferece a garantia de identidade mais forte e é o método recomendado para conversas baseadas no Messenger. Verifica a identidade sem adicionar atrito para seus clientes.
Ativar autenticação em um conector
A autenticação deve ser ativada individualmente para cada data connector onde você deseja que ela seja aplicada:
Vá para Configurações > Integrações > Data connectors e abra o conector.
Selecione a aba Segurança.
Ative a opção Customer authentication.
Complete quaisquer verificações de segurança, depois salve e coloque o conector em funcionamento.
Uma vez ativado, o conector aplica as regras de autenticação do workspace que se aplicam ao canal e público da conversa recebida.
Nota: Se você quiser que um data connector seja executado sem exigir Verificação de Identidade, pode desativar completamente a Customer Authentication. Abra o conector, selecione a aba Segurança e desative a opção Customer authentication.
Verificações de segurança
Quando você salva um data connector, o Intercom automaticamente exibe potenciais riscos de segurança na sua configuração. Eles aparecem como avisos na aba Segurança e devem ser revisados antes de colocar o conector em funcionamento. Cada aviso descreve o risco e fornece uma recomendação sobre como resolvê-lo.
Aviso | O que significa | Como resolver |
Atributos de dados do cliente não são verificados | Atributos de dados do cliente podem ser atualizados pelo Fin sem que o cliente primeiro verifique sua identidade. | Ative a autenticação do cliente para este conector para que as atualizações de atributos estejam vinculadas a uma identidade verificada. |
Dados coletados pelo Fin para este conector precisam ser revisados | O Fin está coletando informações do cliente antes de chamar sua API. Se essa entrada não for validada, seu backend pode processar dados não verificados ou manipulados. | Valide todas as entradas recebidas do Fin no seu backend antes de processá-las ou armazená-las. Não confie em valores fornecidos pelo cliente sem verificações do lado do servidor. |
Workflows usando este data connector precisam ser revisados | Um ou mais workflows usando este conector podem expor dados sensíveis de clientes sem validação adequada no backend. | Revise os workflows sinalizados e adicione validação no backend para evitar que dados sensíveis sejam expostos ou usados indevidamente. |
Um cabeçalho de requisição para este conector de dados precisa ser revisado | Detalhes do cliente (como endereço de e-mail) estão sendo enviados como um cabeçalho de requisição — por exemplo, | Garanta que sua API backend valide o valor do cabeçalho que recebe, em vez de confiar nele como está. |
Nota: O selo "Insecure" exibido em um atributo individual do conector (por exemplo, para um valor coletado pelo Fin que não é verificado) é diferente dos avisos solucionáveis na aba de Segurança acima. É um indicador permanente, por design, para qualquer valor não verificado/inseguro que o Fin coleta — qualquer ação de dispensa na visualização de edição do conector não o remove, e ele reaparecerá mesmo depois que você revisar o atributo e confirmar que é seguro usar. Não é um alerta acionável que você pode resolver ou dispensar permanentemente; ele apenas sinaliza que o valor não foi verificado por meio da autenticação do cliente. Se você quiser que essa classe de atributo pare de ser sinalizada, a única forma é ativar a autenticação do cliente para o conector (veja acima) para que o valor esteja vinculado a uma identidade verificada.
Credenciais
A página de Credenciais (Configurações > Integrações > Credenciais) oferece uma visão centralizada de todas as credenciais de autenticação usadas em seus conectores de dados. A tabela mostra nome, tipo, quem criou e quem atualizou por último — facilitando a auditoria de acesso a sistemas externos.
Lógica
Tokens baseados em texto são simples — o conector de dados usa o valor do token atribuído sempre que testa ou envia uma requisição ao conector de dados ao vivo.
Tokens de Requisição HTTP seguem um fluxo mais complexo. Para testes e conectores de dados ao vivo, o conector de dados usará primeiro o token recuperado mais recentemente. Se a requisição falhar, ele enviará uma requisição de atualização e tentará novamente o conector de dados usando o novo token. Essa tentativa ocorre apenas uma vez para evitar um loop infinito.
Se o conector de dados continuar falhando devido a falhas nas requisições de atualização, ele acionará o disjuntor, assim como qualquer conector de dados que encontre falhas repetidas.
Limitações conhecidas
Atualmente, nem os tokens de autenticação do tipo Texto nem os de Requisição HTTP suportam detalhes diferentes de requisição de autenticação por cliente. Normalmente, isso é solicitado como um fluxo OAuth completo.
Uma vez criado o token de autenticação, não é possível excluí-lo.
Conectores de dados que utilizam o token de aplicativo Stripe autogerado não suportam funcionalidade multi-token porque os cabeçalhos estão bloqueados em estado somente leitura. Para fazer alterações, você deve primeiro remover ou substituir o token Stripe.
Uma vez selecionado um token Stripe, você não pode adicionar novos pares chave-valor à seção de Cabeçalhos HTTP.