Tutorial de integración de API 2FA: guía completa para empresas de EE. UU. (2026)

Autenticación de dos factores (2FA) ya no es opcional para ninguna aplicación estadounidense dirigida al consumidor que gestione cuentas de usuario, dinero o datos confidenciales. La buena noticia para los ingenieros: integrar la 2FA a través de un API 2FA moderna lleva horas, no semanas. La pregunta más difícil es qué tipos de factores apoyar, en qué orden y con qué comportamiento alternativo. Esta guía explica paso a paso Integración de API 2FA para empresas estadounidenses en 2026 — la terminología, los tipos de factores, el flujo estándar, los ejemplos de códigos de trabajo y la lista de verificación de producción para la puesta en marcha.

Terminología de 2FA en 90 segundos

• Autenticación de dos factores requiere que el usuario presente dos factores independientes al autenticarse: normalmente algo que sabe (contraseña) y algo que tiene (teléfono, token de hardware, aplicación de autenticación). El factor «tener» es lo que tu API 2FA asas de integración.
• Las categorías de factores aceptadas según el NIST SP 800-63B son: conocimiento (contraseña, PIN), posesión (teléfono, token de hardware, aplicación de autenticación) e inherencia (datos biométricos como huellas dactilares o faciales). Dos factores se refieren a la combinación de dos categorías diferentes: contraseña + OTP de teléfono, contraseña + TOTP, contraseña + clave de hardware, etc.
• Autenticación multifactorial (MFA) es el término más amplio: la misma idea, tres o más factores en lugar de dos. Los términos se usan indistintamente en la mayoría de los textos de los productos.
• Factores de 2FA fuertes frente a factores débiles por NIST SP 800-63B: La OTP de SMS está «restringida» (es aceptable pero no se prefiere por motivos de alta seguridad), la TOTP de las aplicaciones de autenticación está «permitida» y las claves de hardware FIDO2/WebAuthn son «preferidas».

Los tipos de factores de 2FA que implementará

Factor de fricción del usuario Costo por uso Lo mejor para SMS OTP Moderado entre 0,01 y 0,04 Universal predeterminado, bajo riesgo OTP de WhatsApp Moderado bajo bajo 0,005 a 0,02 Audiencias que priorizan los dispositivos móviles OTP de voz Moderado entre 0,02 y 0,05 Accesibilidad, aplicación de autenticación alternativa a TPStrong Medio (configuración) 0 dólares (después de la configuración) Autenticación basada en USB de alta seguridad y que regresan 02 Aplicación: tener usuarios Fido2/PasskeysStrongestLow (después de la configuración) $0 Acciones administrativas de alto riesgo Tokens de hardware (YubiKey) StrongestHigh (compra) Costo de hardware Administrador empresarial, industrias reguladas

Para la mayoría de las aplicaciones para consumidores de EE. UU. en 2026, la opción predeterminada correcta es enviar SMS o WhatsApp OTP al registrarse (compatibilidad universal) y, a continuación, alentar progresivamente a los usuarios a añadir TOTP o claves de acceso para la autenticación continua. La Alianza FIDO publica guías de migración detalladas para hacer que las bases de consumidores opten por las claves de acceso.

El flujo 2FA estándar

El flujo de referencia para la 2FA basada en el riesgo al iniciar sesión:

1. El usuario envía el nombre de usuario y la contraseña.
2. La aplicación autentica la contraseña.
3. La aplicación comprueba las señales de riesgo: coincidencia de huellas dactilares del dispositivo, geolocalización de IP, hora del día, historial de inicio de sesión reciente.
4. Si la puntuación de riesgo está por debajo del umbral, complete el inicio de sesión (omita la 2FA).
5. Si la puntuación de riesgo está por encima del umbral, solicite el segundo factor, que suele ser el método inscrito por el usuario.
6. El usuario introduce OTP, toca la notificación push o presenta la clave de paso.
7. La aplicación valida el segundo factor mediante la API de verificación.
8. En caso de éxito, complete el inicio de sesión y actualice la tienda de señales de riesgo.

No exija la autenticación de dos factores en cada inicio de sesión: eso destruye la conversión. Usa las señales de riesgo para dar un paso adelante solo cuando el riesgo lo justifique y ofrece la opción «confía en este dispositivo» para que los usuarios no vean la autenticación de dos factores en cada sesión desde un dispositivo reconocido.

Ejemplo de código: SMS OTP Second Factor (Node.js)

//Paso 1: Después de la autenticación con contraseña, envíe el desafío 2FA
función asíncrona require2FA (usuario) {
const verificationId = wait axios.post (`$ {API_BASE} /send`, {
Código de país: user.countryCode,
Número de móvil: usuario.número de teléfono,
Tipo de flujo: ['WHATSAPP', 'SMS'],
Tiempo de espera alternativo en segundos: 30,
Longitud máxima: 6,6
}, {
encabezados: {'authToken': API_KEY}
});

//Almacenar el ID de verificación en la sesión
session.pendingVerification = VerificationId.data.VerificationId;
return {challenge: 'OTP_REQUIRED'};
}

//Paso 2: El usuario introduce el código de SMS/WhatsApp
función asíncrona Complete2fa (sesión, UserEnteredCode) {
resultado constante = await axios.post (`$ {API_BASE} /validate`, {
ID de verificación: sesión. Verificación pendiente,
código: UserEnteredCode,
}, {
encabezados: {'authToken': API_KEY}
});

if (result.data.data.VerificationStatus === 'VERIFICADO') {
session.authenticated = true;
Session.pendingVerification = nulo;
return {éxito: verdadero};
} otra cosa {
return {éxito: falso, error: 'INVALID_CODE'};
}
}



El mismo patrón funciona para WhatsApp, voz y correo OTP; la única diferencia es la Tipo de flujo en la llamada de envío.

Ejemplo de código: Inscripción TOTP en la aplicación Authenticator (Python)

# Biblioteca: pyotp (pip instala pyotp qrcode)
importar pyotp
importar qrcode

def enroll_totp (usuario):
# Genera un secreto único por usuario
secreto = pyotp.random_base32 ()

# Guarde el secreto en su registro de usuario (cifrado en reposo)
user.totp_secret = secreto
user.save ()

# Crea la URI otpauth para la aplicación de autenticación
uri = pyotp.totp.totp (secreto) .provisioning_uri (
name=user.email,
issuer_name='Tu aplicación'
)

# Genere un código QR que el usuario escanee con su aplicación de autenticación
qr = qrcode.make (identificador)
devolver qr.get_image ()

def verify_totp (usuario, código_introducido por el usuario):
totp = PyOTP.totp (user.totp_secret)
return totp.verify (user_entered_code, valid_window=1)



La verificación TOTP no requiere una llamada a la API; el código se genera en el lado del cliente a partir de un secreto compartido que almacenaste en el momento de la inscripción, y tú verificas calculando el código esperado y comparándolo. Este es uno de los motivos por los que el TOTP funciona de forma gratuita y por el que es el segundo factor adecuado para los usuarios que regresan con un gran volumen de usuarios.

La autenticación de dos factores basada en el riesgo: cuándo activarla

Las cuatro señales que utiliza cada sistema 2FA moderno para decidir si impugnar:

La huella digital del dispositivo no coincide

‍El usuario inició sesión desde un dispositivo diferente al de sus últimos 30 días de sesión. La señal de máxima confianza: casi siempre se intensifica.

Salto de geolocalización IP

‍Inicie sesión desde un país o región desde el que el usuario nunca haya iniciado sesión antes. Alta confianza: dé un paso adelante.

Anomalía en la hora del día

‍Inicie sesión a una hora inusual para este usuario (por ejemplo, a las 4 de la mañana, cuando el usuario suele iniciar sesión de 9 a. m. a 5 p. m.). Menor nivel de confianza: aumenta si se combina con otra señal.

Umbral de intentos fallidos

‍Varios intentos fallidos de contraseña en los últimos 30 minutos. Da un paso adelante independientemente de otras señales.

La mayoría de las plataformas de identidad (Autor0, Okta, AWS Cognito) incluyen esta lógica basada en el riesgo lista para usar. Si estás sacando la tuya propia, las cuatro señales anteriores cubren aproximadamente el 90% del valor.

La experiencia de usuario de inscripción que realmente funciona

Hay tres patrones que separan una buena inscripción en 2FA de una mala:

No es necesario inscribirse en la autenticación de dos factores al registrarse

‍Impide la conversión de registro. Verifica por teléfono al momento de registrarte (1FA) y, luego, fomenta progresivamente la inscripción en 2FA durante los primeros 30 a 90 días con indicaciones e incentivos suaves. Los usuarios que obtienen primero el valor de tu producto están más dispuestos a invertir en la configuración de seguridad.

Predeterminadamente, primero el factor más fácil

‍SMS TOP es el valor predeterminado universal; todos los usuarios tienen SMS, no se necesita ninguna configuración adicional. Una vez inscritos, pide a los usuarios que añadan un factor más seguro (TOTP, clave de acceso) para «subir de nivel» en la mensajería de seguridad.

Ofrezca siempre códigos de recuperación

‍Cuando un usuario se inscribe en TOTP o en la 2FA con clave de hardware, genere entre 8 y 10 códigos de recuperación de un solo uso que pueda guardar. Sin códigos de recuperación, los usuarios que pierdan su teléfono se quedan bloqueados para siempre, y tu equipo de asistencia se queda con los gastos.

Cumplimiento de 2FA para empresas estadounidenses

Varios marcos regulatorios de EE. UU. ahora exigen o recomiendan encarecidamente la 2FA:

• PCI DSS requiere MFA para todos los entornos de acceso a los datos de los titulares de tarjetas. SMS OTP cumple los requisitos.
• Regla de seguridad HIPAA requiere la «autenticación de persona o entidad», que se interpreta en sentido amplio para incluir la MFA para sistemas con PHI.
• NIST 800-171//CMMC exige la MFA para los sistemas de contratistas federales que manejan información controlada no clasificada.
• Leyes de privacidad de datos a nivel estatal (CCPA/CPRA, NY SHIELD, etc.) incluyen cada vez más la MFA como una «medida de seguridad razonable».
• Compañías de ciberseguros exigen cada vez más la inscripción en el MFA como requisito previo para la cobertura y como requisito para obtener descuentos.

Para la mayoría de las aplicaciones de consumo de EE. UU. SMS OTP a través de una API de verificación compatible con TCPA se reúne con el bar. Nuestra guía de TCPA cubre los detalles de cumplimiento específicos de SMS.

Lista de verificación de producción para el despliegue de 2FA

Doce objetos antes de voltear la bandera de función:

1. Normalización del número de teléfono con libphonenumber en la entrada
2. Envío OTP multicanal (WhatsApp + SMS + voz alternativa) para la verificación de primer factor
3. Soporte TOTP a través de una biblioteca estándar (pyotp, otplib)
4. Códigos de recuperación generados en el momento de la inscripción, almacenados mediante hash
5. Lógica de activación basada en el riesgo (dispositivo, IP, hora, señales de intentos fallidos)
6. La opción «Confiar en este dispositivo» permite omitir la autenticación de dos factores en los dispositivos reconocidos
7. Límite de frecuencia de intentos de 2FA (máximo 5 por sesión)
8. Registro de auditoría de cada desafío y resultado de la 2FA (retención de 4 años para la defensa de la TCPA)
9. Flujo de recuperación de la cuenta cuando el usuario pierde el acceso a todos los factores
10. Prueba A/B de registro: ¿la exigencia de 2FA al registrarse afecta a la conversión?
11. Manual de soporte al cliente: cómo verificar la identidad y volver a habilitar a un usuario bloqueado
12. Supervisión de la tasa de desafíos, la tasa de éxito y el uso de canales alternativos de 2FA

Preguntas frecuentes

¿Debo solicitar la autenticación de dos factores al registrarme o de forma progresiva?‍

Para la mayoría de las aplicaciones de consumo, de forma progresiva. Verifica que el teléfono al registrarte (1FA) no sea fraudulento ni accesible, y luego solicita a los usuarios que habiliten la 2FA durante los primeros 30 a 90 días con la mensajería de seguridad. Por lo general, forzar la autenticación de dos factores al registrarse reduce la conversión entre un 5 y un 15%, con pocos beneficios de seguridad, ya que los estafadores que borran la verificación telefónica suelen tener éxito 2FA basada en SMS-OTP también.

¿Cuál es el impacto en la conversión de añadir la autenticación de dos factores al iniciar sesión?‍

La autenticación de dos factores basada en el riesgo (que solo se cuestiona cuando las señales de riesgo lo justifican) suele tener un impacto de conversión casi nulo para los usuarios legítimos (menos del 5% de los inicios de sesión activan el desafío y la fricción es de 10 a 30 segundos). La 2FA universal en cada inicio de sesión destruye las conversiones (una caída del 5 al 15% en las sesiones activas). Implemente siempre en función del riesgo, nunca de forma universal.

¿Cómo puedo migrar mi base de usuarios de SMS 2FA a claves de acceso?‍

Arco plurianual, voluntario al principio. Añade la posibilidad de usar claves de paso junto con los SMS, pide a los usuarios que añadan una clave de paso en los momentos de mayor interacción y ofrece la opción de usar solo una clave de paso como el nivel más seguro. Una vez que la adopción de claves de acceso alcance aproximadamente el 30%, plantéate convertirla en la opción predeterminada para los nuevos registros. Obligar a los usuarios existentes a usar solo la clave de paso reduce el éxito del inicio de sesión mientras los usuarios descubren el nuevo flujo. La guía de adopción de la Alianza FIDO cubre el manual de estrategias.

Envíe la autenticación de dos factores en un solo Sprint

La 2FA solía ser un proyecto de un cuarto de duración. Con un API de verificación moderna, es una integración de un solo sprint. VerifyNow para EE. UU. incluye SMS y WhatsApp OTP para el factor predeterminado universal, además de compatibilidad con TOTP para una mejora de alta seguridad; todo ello desde un único punto final REST con valores predeterminados compatibles con TCPA y 10 DLC gestionados internamente. Créditos de prueba gratuitos, no se requiere tarjeta de crédito.