Algunas cosas han cambiado en el mundo desde que escribí esta respuesta, y he escrito un artículo que puede ayudar con algo de esto: Aplicaciones móviles y Flujo implícito de OAuth – Justin Richer – Medio. He dejado la respuesta original sin editar a continuación porque no es un mal consejo.
Hay algunas cosas clave para recordar al trabajar con OAuth en una aplicación móvil que no se aplican tan fácilmente a otras plataformas. Este consejo es adicional a las consideraciones de seguridad y al modelo de amenaza que contienen los RFC.
Primero, cada copia de su aplicación tendrá el mismo código, por lo que no puede enviar con un secreto de cliente (ya que estaría fácilmente disponible para cualquier persona con un descompilador o la capacidad de aprovechar la pila de red en el dispositivo). Puede usar un cliente público, sin secreto de cliente, o usar el Registro de cliente dinámico de OAuth. Este protocolo le permitirá conectarse a un nuevo servidor de autorización y recibir una identificación y un secreto para cada copia del cliente, lo que le permite distinguir las copias del cliente. También protege contra las aplicaciones que suplantan su aplicación, ya que no podrán presentar el secreto del cliente.
- ¿Cuáles son algunas de las características que le gustaría ver en una aplicación de mensajería?
- ¿Cuáles son algunas aplicaciones de viaje útiles en India?
- ¿Cuáles son algunas de las pequeñas y medianas empresas de desarrollo de aplicaciones de telefonía móvil?
- ¿Cuáles son buenas maneras de compartir archivos grandes con clientes empresariales detrás de una seguridad estricta que no permite la mayoría de las aplicaciones y sitios web para compartir archivos?
- ¿Cuáles son algunas buenas aplicaciones de Anime?
Lo que me lleva a mi segundo punto: el almacenamiento. Debe poder almacenar elementos de tiempo de ejecución como tokens en un almacenamiento seguro en su plataforma, para asegurarse de que otras aplicaciones no puedan tomarlos después de que su aplicación haga el trabajo duro de obtener el token. Por supuesto, de todos modos querrá almacenar todos sus datos de usuario en un almacenamiento seguro.
También está el problema de cómo abrir un navegador. Generalmente tiene dos opciones: usar una vista web incrustada o usar el navegador del sistema. Las especificaciones recomiendan que utilice el navegador del sistema por varias razones. El usuario puede tener sus sesiones y credenciales almacenadas en caché y todo tipo de otras cosas útiles cuando utilice el navegador del sistema; será un entorno familiar. Además, es más seguro para usted y para el usuario, ya que su aplicación nunca estará expuesta a las credenciales del usuario.
Y finalmente está la cuestión de qué flujo usar y cómo devolver la información a su aplicación desde el navegador. Es mejor usar el flujo del código de autorización, especialmente cuando se combina con algún tipo de registro dinámico, ya que autentica cada copia de la aplicación por separado y protege contra algunos tipos de robo de credenciales en vuelo. Además, también puede obtener un token de actualización de larga duración, lo que significa que no necesitará volver a solicitar al usuario. El flujo implícito parece más simple en la superficie, pero en realidad solo está destinado a compartir sesiones en el navegador. La mayoría de las aplicaciones nativas utilizan algún tipo de esquema URI personalizado para recuperar el código de autenticación en la aplicación, así que “myapp: // oauth? Code = foo & state = 234i”. Tenga en cuenta que todavía desea utilizar el parámetro ‘estado’ para proteger su aplicación de la fijación de la sesión, lo que significa que deberá generar una cadena aleatoria segura y almacenarla en algún lugar antes de llamar al navegador para que pueda retirarla cuando el El navegador vuelve.
