Back4App + Incognia: Protección de inicios de sesión de aplicaciones

Los datos de ubicación son poderosos y es sorprendente la cantidad de aplicaciones diferentes que existen: desde medios, participación, investigación de mercado, movilidad urbana, etc. Pero, ¿alguna vez ha considerado cómo la tecnología de ubicación precisa puede permitir nuevas estrategias dinámicas para hacer que las aplicaciones sean más seguras y al mismo tiempo eliminar la fricción del proceso de autenticación? Es a partir de las respuestas a esta pregunta que se creó Incognia.

Incognia construyó una plataforma de identidad basada en la ubicación para proteger a los usuarios de la aplicación y, al mismo tiempo, reducir la fricción, al eliminar la necesidad de contraseñas y otras formas de autenticación. Hasta ahora, Incognia se implementó en más de 100 millones de dispositivos y permite la autenticación sin fricciones en más del 90% de los casos.

Cada persona tiene un patrón de comportamiento de ubicación único, como una huella digital de ubicación, que Incognia usa como identidad privada para proteger las cuentas de usuario en aplicaciones móviles. Según el comportamiento de ubicación único del usuario, algunas ubicaciones son muy frecuentadas por ese usuario y dispositivo.

Las ubicaciones más frecuentes se clasifican como ubicaciones de confianza del usuario, que forman parte de la rutina del usuario, como la dirección de su casa y la dirección del trabajo. Con esta información, Incognia puede identificar escenarios de autenticación de bajo riesgo. Cuando Incognia detecta que un usuario se encuentra en una ubicación confiable, existe una mayor probabilidad de que la transacción sea legítima y tenga un menor riesgo de fraude, lo que ofrece la oportunidad de requerir menos fricciones.

Con esta solución, puede realizar una autenticación sin contraseña para cualquier transacción o inicio de sesión relevante haciendo coincidir la ubicación histórica de los usuarios con la del dispositivo que se está utilizando actualmente sin la necesidad de pasos de alta fricción como reconocimiento facial u OTP.

Protección de inicios de sesión de aplicaciones

En este tutorial, aprenderá cómo integrar la API de transacciones de Incognia para mejorar el reconocimiento de los usuarios confiables al iniciar sesión sin agregar fricción a la experiencia del usuario. Podrá aprobar automáticamente los intentos de inicio de sesión confiables, activar la autenticación escalonada y bloquear los inicios de sesión sospechosos.

Requisitos

  • Una cuenta de Incognia. Regístrese aquí si no tiene una cuenta. 
  • Una aplicación con el SDK de Incognia inicializado. Siga la guía de introducción al SDK para esto. 
  • Credenciales de API para poder realizar solicitudes a las API Incognia. 

Paso a paso

  • Configuración de la identificación de usuario en la aplicación

Para verificar un intento de inicio de sesión, Incognia necesita vincular un dispositivo y un identificador de cuenta único. El ID de cuenta se utiliza para este propósito.  

Esta asociación debe ocurrir en dos momentos:

1. Siempre que la aplicación se inicialice

Esto cubre el escenario en el que la aplicación se actualiza con el SDK de Incognia y el usuario ya ha iniciado sesión. La aplicación Application.onCreate () en Android y la aplicación [AppDelegate application:didFinishLaunchingWithOptions:] en iOS son buenos lugares para hacer esto.

Si el ID de cuenta no está disponible en esas ubicaciones, es importante reenviar el valor al SDK de Incognia tan pronto como esté disponible. La acción importante aquí es llamar a setUserId siempre que la aplicación se inicialice, por lo que se garantiza que siempre sepamos que un usuario específico está asociado con un dispositivo específico.    

2. Siempre que el usuario inicie y cierre sesión

Es necesario llamar al método setUserId cuando el usuario finaliza el inicio de sesión y clearUserId cuando el usuario cierrala sesión. Esto generalmente se hace en la devolución de llamada de estas dos acciones.    

view rawsetUserId.txt hosted with ❤ by GitHub

ALERTA: Si bien datos como el correo electrónico y los números de teléfono son ejemplos de identificadores, su uso en el SDK está prohibido. Considere el uso de información no personal, como UUID y Hashing para generar y configurar de forma segura la ID de usuario. 

  • Reenvío de la ID de instalación del dispositivo a su servidor

El SDK de Incognia recopila datos de ubicación y dispositivos para crear un perfil de comportamiento para los usuarios móviles. Estos datos se etiquetan con un identificador llamado ID de instalación, que el SDK genera automáticamente.

Para verificar un intento de inicio de sesión, Incognia necesita recibir un ID de instalación para identificar el dispositivo desde el cual se origina el inicio de sesión. Dado que su servidor solicitará la API de Incognia para evaluar el riesgo de este inicio de sesión, necesita recibir esta información de su aplicación móvil.

El ID de instalación se puede enviar a su servidor de dos formas.

  • Opción 1: enviar el ID de instalación como encabezado

Antes de enviar una solicitud de inicio de sesión desde su aplicación móvil a su servidor, llame a Incognia.getInstallationId y establezca su valor como encabezado de la solicitud. Le recomendamos que elija un nombre claro para este encabezado, como Incognia-Installation-ID, para que pueda identificarlo fácilmente en el lado del servidor.  

Esta opción tiene un beneficio claro si su aplicación usará más de una solución de Incognia porque no necesitará cambiar las propiedades de cada solicitud, como registro, inicio de sesión, pago, cambio de contraseña, etc.

Kotlin

view rawIncognia-Kotlin.kt hosted with ❤ by GitHub

Java

Swift

Objective-C

  • Opción 2: enviar el ID de instalación en el cuerpo de la solicitud

Antes de enviar la solicitud de inicio de sesión desde su aplicación móvil a su servidor, llame a Incognia.getInstallationId y envíelo como información adicional sobre este inicio de sesión. Le sugerimos que elija un nombre claro para esta propiedad como Incognia-Installation-ID, para que pueda identificarla fácilmente en el lado del servidor.

Manejo de la solicitud de inicio de sesión del usuario

Cuando su servidor recibe una solicitud de inicio de sesión, puede utilizar la inteligencia de Incognia para evaluar el riesgo de este intento de inicio de sesión dentro de este ciclo de solicitud/respuesta.

Para evaluar este riesgo de intento de inicio de sesión, su servidor solicitará la API de transacciones informando que se realizó un intento de inicio de sesión junto con su ID de instalación y el ID de cuenta de la cuenta a la que el dispositivo está intentando acceder. 

Una implementación de muestra de un controlador/manejador

Consideremos un ejemplo de un backend con el controlador a continuación:

Debe autenticarse cuando utilice la API de Incognia. Para obtener detalles sobre la autenticación, consulte Autenticación en las API de Incognia.

Teniendo en cuenta que la lógica de autenticación está implementada, puede agregar solicitudes de evaluación de riesgos a su controlador de inicio de sesión:

# incognia/api.rb

Uso de la evaluación de riesgos de Incognia

Cuando su servidor realiza una solicitud al punto final de la API de transacciones, recibirá una respuesta como la siguiente:

La respuesta contiene la identificación de la entidad creada (en este caso, un inicio de sesión), la evaluación de riesgo proporcionada por Incognia en función del comportamiento del dispositivo y la evidencia que respalda esta evaluación. Puede obtener más información sobre todos los dato

La evaluación devuelta se puede utilizar con otros datos relacionados con el riesgo, como en un motor de riesgo, para decidir si se debe aceptar este inicio de sesión. Las evaluaciones de riesgo de Incognia incluyen:

  • riesgo_alto: el inicio de sesión realizado por el dispositivo puede ser fraudulento y le recomendamos que tome acciones preventivas en estos escenarios, como requerir una autenticación adicional o simplemente bloquear este intento de inicio de sesión;
  • riesgo_bajo: el inicio de sesión realizado por el dispositivo parece ser seguro de aceptar;
  • riesgo_desconocido: no podemos proporcionar una evaluación precisa en el momento de la solicitud. Debe requerir autenticación adicional (por ejemplo, 2FA).

Para finalizar

Después de estos pasos, su aplicación está lista para reconocer a los usuarios confiables al iniciar sesión sin fricciones y evitando la apropiación de cuentas.


Leave a reply

Your email address will not be published.