1) Hay dos partes para su problema:
1.1) Registrar un usuario para usar la aplicación / sitio por primera vez
1.2) Los detalles de autenticación / inicio de sesión necesarios cada vez que abren la aplicación.
2) Supongo que el esquema “Número de teléfono / Código de verificación de SMS” que describe arriba es solo para el # 1.1 anterior, es decir, para uso de registro único
2.1) Por lo general, no requeriría que un usuario realice este proceso todo lo que inicie sesión (es decir, el punto 1.2 anterior)
2.2) Si es solo para el registro, entonces el esquema que describa es posible
2.2.1) pero no es fácil de desarrollar adecuadamente. Ver # 4 a continuación
3) En términos de # 1.2: Autenticación estándar / Inicio de sesión
3.1) Piensa en la experiencia del usuario (UX). La mayoría de las aplicaciones móviles una vez registradas permitirán que el usuario regrese sin necesidad de autenticarse
3.1.1) Durante el registro (es decir, el n. ° 2 anterior), la aplicación almacenaba una identificación única en el teléfono que identifica al usuario cada vez que abre la aplicación
3.2) Las aplicaciones que utilizan este enfoque se basan en el hecho de que la mayoría de los usuarios protegen sus teléfonos y no permiten que otras personas accedan fácilmente a ellos.
- ¿Cómo es la estructura de fondo de una aplicación compleja como Instagram?
- ¿Cuál es la ventaja de poder usar WP-API?
- ¿Cómo se ve el panel de administración / backend para un sitio como classpass?
- ¿Cuál es la tecnología que debo usar para hacer una aplicación de chat en tiempo real en código nativo?
- ¿Cómo crear un servicio de backend web para usar en mi aplicación móvil? No quiero pagar servicios como Parse. ¿Podría usar el framework Django?
4) Ataques de número de teléfono no válidos
4.1) Como ya ha resaltado. Los piratas informáticos (por varias razones) podrían apuntar al esquema de registro descrito en el n. ° 2 anterior
4.2) Necesitaría una cantidad de SecurityCounterMeasure (s) para protegerse contra estos ataques. Estos tendrían que incluir cosas como:
4.2.1 ) Prevenir ataques automatizados contra el mecanismo
4.2.1.1) Usar algo como un mecanismo Captcha
4.2.2 ) Limite el número de intentos inválidos que pueden ocurrir desde una CallingIPAddress particular
4.2.2.1) Si se excede el límite, bloquee esa CallingIPAddress por un período
4.2.3 ) Proteger contra un ataque DDOS masivo
4.2.3.1) es decir, suspender los registros por un período si # 4.2.2 está sucediendo para múltiples CallingIPAddress (s).
4.2.4 ) Limite la cantidad de código de verificación que se puede enviar al mismo número de teléfono en un período determinado.
5) Manejo de reinscripción
5.1) También necesitaría proporcionar funciones para permitir que un usuario se vuelva a registrar cuando cambian / pierden teléfonos
5.2) Asegúrese de permitir solo la aplicación en un teléfono para un número de teléfono determinado.
5.2.1) Cuando vuelva a registrarse con un PhoneNumber ya usado, desactive cualquier UniqueID anterior asociado con este PhoneNumber. Ver # 3.1.1 arriba.