Para configurar nuevos métodos de autenticación para conectores de datos, ve a Configuración > Integraciones > Autenticación y haz clic en Agregar token.
Tienes dos enfoques principales para configurar un token: conectar un proveedor preconfigurado o crear un token personalizado:
Conectando un proveedor preconfigurado (OAuth)
Ofrecemos flujos OAuth de 3 pasos preconfigurados para proveedores compatibles (como Salesforce, HubSpot y Attio) para que la autenticación sea rápida y sencilla.
Para conectar uno de estos proveedores:
Ve a Configuración > Integraciones > Autenticación y haz clic en Agregar token.
Selecciona el proveedor deseado del menú desplegable.
Serás redirigido a la página de autorización del proveedor. Revisa los permisos solicitados y haz clic en Confirmar (o Permitir) para autorizar la conexión.
Una vez completado el flujo OAuth, tu nuevo token de acceso aparecerá automáticamente en tu lista de tokens.
Al hacer clic en tu token recién creado se mostrará su configuración. Como esta es una integración preconfigurada, solo los campos Nombre y Descripción son editables. También verás:
URL de API: La URL base para usar al hacer llamadas API a este proveedor en tus conectores de datos. Puedes copiarla rápidamente usando el ícono Copiar al portapapeles.
Alcance: Una lista de solo lectura de los permisos que se han otorgado al token.
Reautenticando un token
Si un token se desactiva o se rompe en el lado del proveedor, no necesitas eliminarlo y empezar de nuevo. Simplemente abre los detalles del token y haz clic en el botón Reautenticar en la esquina superior derecha. Esto te guiará nuevamente por el flujo OAuth y actualizará automáticamente tu token existente, asegurando que tus conectores de datos conectados sigan funcionando sin actualizaciones manuales.
Creando un token personalizado
Si necesitas conectarte a un servicio que no está incluido en la lista preconfigurada:
Ve a Configuración > Integraciones > Autenticación y haz clic en Agregar token.
Selecciona Personalizado.
Luego selecciona el Tipo de token que quieres crear del menú desplegable.
Tokens de texto
Los tokens de texto son tokens estáticos. Puedes establecer el nombre, descripción, valor, prefijo del token y la clave para el encabezado de la solicitud que contiene el token, que se insertará en la solicitud del conector de datos.
Tokens de solicitud HTTP
Los tokens de solicitud HTTP son dinámicos. Configuras una solicitud HTTP a tu Endpoint de Autenticación que actualizará el token cuando sea necesario. Estos tokens deben probarse desde la interfaz de usuario de Token de Autenticación antes de guardarlos. Puedes establecer el nombre, descripción del token y luego los campos que afectan la solicitud en sí. Estos son el método de solicitud HTTP, URL, encabezados HTTP y cualquier par clave-valor.
Debes probar el token haciendo clic en Probar solicitud y luego especificar la ubicación del token en la respuesta, el prefijo del token y la clave para el encabezado de la solicitud.
Si un token de solicitud HTTP está asignado a un conector de datos, el conector usará el token obtenido más recientemente para sus solicitudes. Si una solicitud devuelve una respuesta 400, 401 o 403, el token se actualizará enviando una solicitud HTTP a la URL del Endpoint de Autenticación especificado. La solicitud original del conector de datos se reintentará usando el token recién obtenido.
Los tokens de solicitud HTTP se actualizan automáticamente por Intercom para mantener los conectores de datos funcionando. Estas actualizaciones ocurren en segundo plano sin acción humana y pueden aparecer como actualizadas por “System” o “Fin” para indicar una actualización automática.
Nota: Si tu servidor devuelve un 200 para una respuesta de acceso denegado, no actualizaremos el token. Necesitarás actualizar tus servidores para que devuelvan un 400, 401 o 403 en este caso.
Si hay un problema al actualizar un token, el problema se registrará en la pestaña "Registros" del conector de datos.
Tokens de solicitud OAuth
Las solicitudes OAuth te permiten solicitar y actualizar tokens haciendo una solicitud POST con formato OAuth client credentials grant.
Por favor proporciona el url, client_id, client_secret y el campo opcional scope. Selecciona el formato de solicitud JSON o Form Encoded según la configuración de tu servidor de tokens.
Se mostrará una vista previa del encabezado y cuerpo de la solicitud.
Haz clic en Probar solicitud después de completar todos los campos requeridos.
Intercom buscará el token en la respuesta en la ruta access_token.
Guarda el token una vez que la prueba haya pasado.
Similar al token de solicitud HTTP, el sistema realizará una actualización del token si una solicitud de conector de datos recibe una respuesta 400, 401 o 403.
Los tokens de solicitud OAuth se actualizan automáticamente por el sistema cuando es necesario. Estas actualizaciones no son activadas por un administrador humano y pueden aparecer como actualizadas por “System” o “Fin” para indicar una actualización automática.
Tokens de usuario
Los tokens de usuario permiten autenticar conectores de datos usando un token definido por el usuario. Estos tokens son creados y actualizados por sistemas de terceros. Uno de los ejemplos más populares de este tipo de token es JSON Web Tokens (JWT).
JWT es una forma segura de verificar la identidad del usuario. Ahora puedes usar este nuevo tipo de token de autenticación para asegurar tus conectores de datos. Esto permite una comunicación más flexible y segura entre tus sistemas e Intercom.
Usa el token en un conector de datos
Una vez que tu tipo de token esté creado:
Ve a Configuración > Integraciones > Conectores de datos y abre el conector que quieres configurar.
Selecciona la pestaña API.
En la sección Authentication tokens, selecciona tu token del menú desplegable.
Creación y actualización de tokens de usuario
La gestión de todos los tokens de usuario la manejan sistemas de terceros.
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
}
});
Estos sistemas de terceros también son responsables de actualizar el security token y refrescarlo periódicamente.
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
});
Soporte multi-token
Puedes adjuntar múltiples tokens a un solo Data connector. Cada token adjunto debe configurarse con una clave de encabezado única (por ejemplo, Authorization, X-API-Key). Todos los tokens adjuntos se enviarán con la solicitud.
Esta configuración te permite activar Data connectors usando ese token, ya sea a través de Workflows o Fin. El Data connector seguirá funcionando incluso si el valor del token se actualiza, ya que se refrescará en tiempo real para asegurar una autenticación ininterrumpida.
Para usar un JWT por usuario con un Data connector, crea un token de autenticación ‘User’ y proporciona su valor actual mediante auth_tokens (por ejemplo, Intercom('setAuthTokens')), en lugar de depender del Messenger intercom_user_jwt.
Verificación de correo electrónico con un código de un solo uso (OTP)
La verificación de correo electrónico para Data connectors con OTP proporciona un paso adicional de verificación antes de usar un Data connector, requiriendo que los clientes verifiquen su identidad mediante un código único y sensible al tiempo enviado por correo electrónico.
Este método añade una capa extra de seguridad además de los tokens de autenticación de usuario (por ejemplo, JWTs). Cuando está habilitado, los clientes deben completar el proceso de verificación por correo electrónico antes de que un Data connector pueda continuar. Esto ayuda a asegurar que solo usuarios autorizados puedan realizar operaciones sensibles y previene el mal uso de workflows automatizados.
Autenticación de clientes para data connectors
La autenticación de clientes te permite verificar la identidad de un cliente antes de que un data connector se ejecute. A diferencia de la autenticación con token API (que asegura la comunicación servidor a servidor), la autenticación de clientes confirma la identidad del usuario final, asegurando que solo clientes autorizados puedan activar conectores sensibles.
Las reglas de autenticación se configuran en Settings > Workspace > Security > Customer authentication y se aplican a todos los data connectors que tengan la autenticación habilitada. Las reglas pueden establecerse por canal y por audiencia.
Una regla de respaldo cubre todos los canales y audiencias no especificados, por lo que cada conector autenticado siempre está protegido.
Nuevo workspace
Cuando se crea un nuevo workspace, la regla de autenticación de respaldo se establece automáticamente en Email OTP. Esto cubre todos los canales y audiencias no especificados por una regla más específica.
Agregar una regla
Cuando creas una nueva regla para canal o audiencia, se aplica un método de autenticación predeterminado basado en el tipo de canal:
Canal | Método de verificación predeterminado |
Messenger (web, iOS, Android) | Messenger security (JWT) |
Todos los demás canales | Sin verificación (se aplica la regla de respaldo) |
Métodos de verificación
Hay dos métodos de verificación disponibles:
Email OTP — envía un código de un solo uso a la dirección de correo electrónico del cliente. El cliente debe ingresar este código antes de que el conector se ejecute. Consulta Secure data connectors with One-Time Passcode para detalles de configuración.
Messenger security (JWT) — utiliza la verificación de identidad existente de Messenger (User token). Requiere que Messenger security con JWTs esté configurado. Consulta User tokens arriba.
Consejo: Messenger security (JWT) ofrece la garantía de identidad más fuerte y es el método recomendado para conversaciones basadas en Messenger. Verifica la identidad sin añadir fricción para tus clientes.
Habilitar autenticación en un conector
La autenticación debe activarse individualmente para cada data connector donde desees que se aplique:
Ve a Settings > Integrations > Data connectors y abre el conector.
Selecciona la pestaña Security.
Activa Customer authentication.
Completa cualquier verificación de seguridad, luego guarda y activa el conector.
Una vez habilitado, el conector aplica las reglas de autenticación del workspace que correspondan al canal y audiencia de la conversación entrante.
Nota: Si quieres que un data connector se ejecute sin requerir verificación de identidad, puedes desactivar completamente Customer Authentication. Abre el conector, selecciona la pestaña Security y desactiva Customer authentication.
Verificaciones de seguridad
Cuando guardas un data connector, Intercom muestra automáticamente posibles riesgos de seguridad en tu configuración. Estos aparecen como advertencias en la pestaña Security y deben revisarse antes de activar el conector. Cada advertencia describe el riesgo y ofrece una recomendación para solucionarlo.
Advertencia | Qué significa | Cómo solucionarlo |
Los atributos de datos del cliente no están verificados | Los atributos de datos del cliente pueden ser actualizados por Fin sin que el cliente verifique primero su identidad. | Habilita la autenticación de clientes para este conector para que las actualizaciones de atributos estén vinculadas a una identidad verificada. |
Los datos recopilados por Fin para este conector necesitan revisión | Fin está recopilando información del cliente antes de llamar a tu API. Si esta entrada no se valida, tu backend puede procesar datos no verificados o manipulados. | Valida todas las entradas recibidas de Fin en tu backend antes de procesarlas o almacenarlas. No confíes en valores proporcionados por el cliente sin verificaciones del lado del servidor. |
Workflows que usan este data connector necesitan revisión | Uno o más workflows que usan este conector pueden exponer datos sensibles de clientes sin una validación adecuada en el backend. | Revise los workflows marcados y agregue validación en el backend para evitar que se expongan o usen indebidamente datos sensibles. |
Se necesita revisar un encabezado de solicitud para este conector de datos | Los detalles del cliente (como la dirección de correo electrónico) se envían como un encabezado de solicitud — por ejemplo, | Asegúrese de que su API backend valide el valor del encabezado que recibe en lugar de confiar en él tal cual. |
Nota: La insignia "Inseguro" que se muestra en un atributo individual del conector (por ejemplo, para un valor recogido por Fin que no está verificado) es diferente de las advertencias resolubles en la pestaña de Seguridad arriba. Es un indicador permanente, por diseño, para cualquier valor no verificado/inseguro que Fin recopila; cualquier acción de descartar en la vista de edición del conector no lo elimina, y reaparecerá incluso después de que haya revisado el atributo y confirmado que es seguro usarlo. No es una alerta accionable que pueda resolver o descartar permanentemente; simplemente señala que el valor no fue verificado mediante autenticación del cliente. Si desea que esta clase de atributo deje de ser marcada, la única forma es habilitar la autenticación del cliente para el conector (ver arriba) para que el valor esté vinculado a una identidad verificada.
Credenciales
La página de Credenciales (Configuración > Integraciones > Credenciales) le ofrece una vista centralizada de todas las credenciales de autenticación usadas en sus conectores de datos. La tabla muestra nombre, tipo, quién la creó y quién la actualizó por última vez, facilitando la auditoría del acceso a sistemas externos.
Lógica
Los tokens basados en texto son sencillos: el conector de datos usa el valor del token asignado cada vez que prueba o envía una solicitud en vivo del conector de datos.
Los tokens de solicitud HTTP siguen un flujo más complejo. Para pruebas y conectores de datos en vivo, el conector de datos usará primero el token recuperado más recientemente. Si la solicitud falla, enviará una solicitud de actualización y luego reintentará el conector de datos usando el nuevo token. Este reintento ocurre solo una vez para evitar un bucle infinito.
Si el conector de datos sigue fallando debido a fallos en las solicitudes de actualización, activará el interruptor de circuito, igual que cualquier conector de datos que encuentre fallos repetidos.
Limitaciones conocidas
Actualmente, ni los tokens de autenticación de Texto ni de Solicitud HTTP soportan diferentes detalles de solicitud de autenticación por cliente. Usualmente esto se solicita como un flujo OAuth completo.
Una vez creado el token de autenticación, no es posible eliminarlo.
Los conectores de datos que utilizan el token de aplicación Stripe autogenerado no soportan funcionalidad multi-token porque los encabezados están bloqueados en un estado de solo lectura. Para hacer cambios, primero debe eliminar o reemplazar el token de Stripe.
Una vez que se selecciona un token de Stripe, no puede agregar nuevos pares clave-valor a la sección de Encabezados HTTP.