La autenticación de dos factores puede parecer un proceso muy banal por parte del usuario. Muchos están acostumbrados desde hace tiempo a que, al utilizar muchas aplicaciones, no baste con introducir una combinación conocida de nombre de usuario y contraseña. Se introduce un factor de verificación adicional para aumentar la seguridad y evitar el acceso no autorizado. En la mayoría de los casos, se trata de un código único que puede recibirse por correo electrónico o por SMS.
En este tutorial, aprenderemos cómo se puede implementar la autenticación de dos factores en AppMaster. Como ejemplo, se utilizará el envío del código al correo. Analizaremos qué módulos hay que conectar, qué configuraciones realizar, qué proceso de negocio crear y cómo comprobar el resultado final en la práctica.
Primero, echemos un vistazo al plan general. ¿Qué pasos hay que implementar en nuestro proceso de negocio?
- Verificación del inicio de sesión (asegurarse de que el usuario está realmente registrado).
- Comprobación de que la contraseña es correcta.
- Envío de un código de confirmación por correo o SMS.
- Comprobación de la pertinencia del código.
- Comprobación de la exactitud del código.
- Сompletar la autenticación.
Etapa preparatoria
Incluso antes de empezar a diseñar la autenticación de dos factores, en la fase de registro del usuario, hay que asegurarse de que
- Los datos del usuario deben contener un correo electrónico. Se utilizará para enviar el código de verificación. El correo electrónico se utiliza a menudo como inicio de sesión, y vamos a ver un ejemplo de ello.
- El nombre de usuario es único. No pueden existir dos usuarios diferentes con el mismo nombre de usuario en el sistema.
Para la comodidad de resolver estas (y muchas otras) tareas, el Auth se instala por defecto en cada proyecto de AppMaster. Contiene los modelos de base de datos necesarios, los bloques de procesos de negocio y los puntos finales para su uso.
Verificación del inicio de sesión
El inicio de sesión, la contraseña y el código de verificación se utilizan como parámetros de entrada del proceso empresarial. Pero en la primera etapa, sólo necesitamos un inicio de sesión. Nos ayudaría a asegurarnos de que este usuario existe. Se ha registrado, y la información sobre él se almacena en la base de datos.
Para ello, el bloque DB: Search User busca un usuario con el nombre de usuario indicado en la base de datos. Asegúrese de establecer el parámetro SearchExact = True para buscar una coincidencia exacta.
Los datos recibidos se pasan al bloque Array Element con el índice 0 (el conteo comienza desde cero, y el único valor encontrado siempre corresponderá al índice 0 de la matriz).
El bloque Is Null bloque comprueba si se ha encontrado realmente el usuario. Y en función del resultado (True/False), el bloque If-Else interrumpirá el proceso de negocio con un mensaje de error (Raise Error ) o lo dirigirá más allá.
Comprobación de la contraseña
En esta etapa, es necesario asegurarse de que la contraseña del usuario se introduce correctamente.
Y aquí, es esencial entender que las contraseñas no se almacenan explícitamente en la base de datos. La función Bcrypt las convierte en hash, y sólo el hash resultante se almacena en la base de datos. Por lo tanto, aunque supongamos que se produzca una fuga de datos, los atacantes seguirán sin poder encontrar las contraseñas de los usuarios; están encriptadas de forma segura.
Por esta razón, no se puede simplemente obtener la contraseña de la base de datos y compararla con la contraseña introducida. Es necesario obtener el hash de la contraseña y utilizarlo para la comparación. Para resolver este problema, se utiliza el Auth: Probe Password se utiliza el bloque Como parámetros de entrada, toma la contraseña introducida por el usuario (password) y el hash de la contraseña almacenado en la base de datos (hashed_password) y lo convierte al tipo de datos String (el To String bloque).
En función del resultado, como en el paso anterior, utilizando el If-Else bloque, mostramos un mensaje de error (Raise Error Message = Password is wrong) o dirigimos el proceso a la siguiente etapa.
Extensión del modelo de usuario
Para el siguiente paso, es necesario hacer un pequeño cambio en el modelo de usuario y añadir información sobre el código que debe ser confirmado.
En general, el modelo User contiene inicialmente campos que pueden ser utilizados para esta tarea - Confirmed, Confirmation code, Confirmation code expires at. Pero en este ejemplo, supondremos que estos campos se utilizan sólo para el registro y la verificación inicial de la cuenta.
Para una mayor claridad del proceso, vamos a crear un modelo separado twofa (two-factor authentication), asociar el modelo User con él (relación 1 a 1, has one), y añadir un campo - code ( tipoString ).
Preparación para el envío de correos electrónicos
Para enviar correos electrónicos con códigos de confirmación, hay que preparar los preliminares. Una de las opciones más accesibles es utilizar el módulo Custom SMTP que hay que instalar y configurar.
Cuando se utiliza Gmail, la mayoría de las configuraciones ya están establecidas por defecto, y es necesario añadir el nombre de usuario y la contraseña. Si utiliza otros servidores de correo, le será útil consultar su documentación para obtener los datos necesarios.
En este caso, es posible que tengas que cambiar ligeramente la configuración de seguridad del servidor de correo. Por ejemplo, Gmail puede bloquear por defecto las conexiones que utilizan aplicaciones de terceros, por lo que es necesario eliminar esta restricción en la configuración.
Envío de un código de verificación
Hemos comprobado el nombre de usuario y la contraseña y hemos completado todos los preparativos necesarios, así que ahora puedes proceder a enviar una carta con un código de confirmación.
El bloque Custom SMTP: Send Email bloque utiliza una matriz de direcciones como destino. Por lo tanto, aunque necesite enviar una carta a una sola dirección, ésta debe ser añadida al array. Para ello, se utiliza el Append Array se utiliza el bloque.
El siguiente paso es generar un código de verificación. El bloque Random string es adecuado para ello. Enviaremos un código formado por 6 números aleatorios y haremos los ajustes adecuados. Length = 6, With 0-9 = True, todos los demás parámetros = False.
A continuación, hay que crear el texto de la carta. Para ello, utilice el bloque Concat Strings para añadir un texto explicativo al código generado (First = Verification code: ), convertir el resultado al tipo de datos Text (To Text ), y conecte el resultado al parámetro body del bloque de envío de correo electrónico.
Para el envío final, sólo queda especificar el asunto de la carta (subject) y el remitente (from_name).
Pero no basta con enviar el código, sino que hay que almacenarlo en los datos del usuario. Al fin y al cabo, hay que verificar su exactitud cuando el usuario recibe el código y lo devuelve como confirmación.
Para ello, utilizaremos el modelo twofa, que prudentemente hemos creado antes. Si se trata del primer envío de código, hay que crearlo con información sobre el usuario al que pertenece. En caso de reutilización, es necesario parchear la entrada existente, indicando su ID y el nuevo código.
El último paso de la etapa es utilizar el bloque Raise Error para devolver un mensaje sobre el envío del código al correo electrónico.
Comprobación de la relevancia del código
Merece la pena cuidar la seguridad adicional y proteger el código de una enumeración banal. Sería conveniente limitar el número de intentos de entrada, su frecuencia y la duración del código presentado. No analizaremos todos estos ejemplos; los requisitos de seguridad son individuales para cada proyecto y pueden incluir muchas condiciones diferentes. Nos limitamos a comprobar la pertinencia del código por su período de validez.
Utilicemos el bloque Current date & time para obtener la hora actual. Conéctelo al parámetro B del bloque Date & time difference bloque. Utilizaremos el campo UpdatedAt del modelo twofa como parámetro A.
Como resultado, obtenemos Time span - la diferencia entre dos puntos temporales. Sólo queda comprobar si esta diferencia supera un determinado valor seleccionado. En nuestro ejemplo, se trata de 5 minutos, que estableceremos como valor estático B del Greater bloque.
El bloque If-Else utilizará el resultado de la comparación para seguir guiando el proceso. Si True (la diferencia supera los 5 minutos), el proceso volverá al paso de envío de la carta; el usuario recibirá un código actualizado. En el caso de que False (el código está fresco y actualizado), se podrá proceder a la comprobación de este código.
Revisión del código
La etapa final de la autenticación es la comprobación del código recibido.
El bloque Equal debe validar que el código introducido por el usuario coincide con el código almacenado en el modelo twofa asociado al usuario. Si no es así y el código se especifica de forma incorrecta (If-Else -> False), deberá mostrar un mensaje de error (Raise Error, Message = Code is wrong). Si la comparación confirma la coincidencia, se puede pasar a la etapa final de autenticación.
Para ello, utilizamos el bloque Auth: Authentication y obtenemos información sobre el usuario con su token de autorización. Los pasamos al End bloque como resultado de una autenticación exitosa.
Creación de un punto final
El proceso de negocio se ha creado pero aún no está disponible para su uso. Es necesario crear un endpoint que ejecute este proceso de negocio.
Una solución razonable sería utilizar el endpoint de autenticación por defecto (POST /Auth). Bastará con sustituir su proceso de negocio e instalar el que se acaba de crear. De este modo, se desactivará la autenticación simple y en su lugar se utilizará la autenticación de dos factores.
Publicación y prueba
Esto completa la creación de la autenticación de dos factores. Puede publicar el resultado y comprobarlo en acción. Para ello, es conveniente utilizar Swagger, al que se accede haciendo clic en el nombre del plan de despliegue en la sección Project API del botón Preview.
Sólo queda buscar el endpoint deseado en la lista, introducir los datos del usuario e iniciar la ejecución con el botón Execute. Si se encuentra algún error durante la prueba, entonces vuelva al proceso de negocio y haga los cambios necesarios.
