Si le pide al usuario que ingrese un nombre de usuario y una contraseña cada vez que la aplicación necesite hacer una llamada a la API, tendrán un mal momento y dejarán de usarla. Especialmente si surge una situación en la que una sola "acción" desde su perspectiva inicia múltiples llamadas a la API que necesitarían autenticación por separado. Eso simplemente no es viable. Esa no es la única manera en que "
La alternativa es tener el nombre de usuario y la contraseña del usuario almacenados en su dispositivo, por lo que la aplicación no tiene que preguntar para enviar la solicitud. El usuario no puede distinguir la diferencia entre la aplicación que posee un token arbitrario que permite el acceso en comparación con el nombre de usuario y la contraseña que permite el acceso, así que eso es bueno. Desafortunadamente, también hay algunas fallas en eso, y esas fallas son más relevantes para la seguridad.
Primero, a menos que su aplicación realice un cifrado interno, el nombre de usuario y la contraseña terminan efectivamente almacenados uno al lado del otro en texto plano. Incluso si hay encriptación, la clave de encriptación tiene que ser almacenada cerca de lo que está encriptando, lo que no es mucho mejor. No puedo decir con precisión cuánta vulnerabilidad es esto, y es probable que un token sea igual de vulnerable, pero es probable que un atacante que adquiera un solo token sea menos dañino que uno que obtenga el nombre de usuario completo y la contraseña.
En segundo lugar, como usted sabe, se espera que los tokens caduquen con una frecuencia relativamente alta en comparación con los nombres de usuario y las contraseñas. Por la forma en que está redactada su pregunta, parece que está considerando el nombre de usuario y la contraseña en cada solicitud, ya que el "nivel más alto" de tokens expira rápidamente, pero en realidad es lo contrario: sin token entre, el nombre de usuario y la contraseña se convierten en el token y solo caducan cuando se cambia. Eso hace que la aplicación sea algo más vulnerable a los ataques de reproducción, y hace que sea mucho más incómodo para el usuario si alguna vez implementa controles para detectar comportamientos maliciosos: con un token, puede vencer el token inmediatamente, pero un usuario real puede proporcionar un nombre de usuario y una contraseña para obtén uno nuevo mientras un atacante que obtuvo solo el token está bloqueado. Un usuario que ingresa sus credenciales de vez en cuando es bastante menor, pero forzar el restablecimiento de contraseñas aleatorias es mucho más oneroso y se apoya mucho en una función de restablecimiento seguro de contraseñas.
Por último, el nombre de usuario y la contraseña se transmitirían con mucha más frecuencia. Idealmente, la conexión segura es perfecta y eso no es un problema, pero en la práctica hay algunas vulnerabilidades que son más susceptibles de ser explotadas. Por ejemplo, la vulnerabilidad de CRIME explotó el tamaño de los mensajes enviados para filtrar partes de información, pero requería que exista un valor constante en muchos mensajes. Esa vulnerabilidad exacta probablemente esté parcheada, pero podrían existir otras similares en el futuro y, si sus solicitudes son un tanto filtradas, tener siempre un nombre de usuario y una contraseña en ellos permitirá a la información de un ataque reunir esa información durante mucho tiempo, en comparación con un token que tiene menos impacto al filtrar y limita el tiempo que tiene un atacante para obtenerlo.
Todo eso podría no sumar un compromiso de seguridad grande , pero no me arriesgaría.