Aclaración: Aplicación móvil = Aplicación nativa
Como se indica en otros comentarios y en algunas fuentes en línea, lo implícito parece un ajuste natural para las aplicaciones móviles, sin embargo, la mejor solución no siempre es clara (y de hecho, lo implícito no se recomienda por las razones que se analizan a continuación).
Prácticas recomendadas de OAuth2 para aplicaciones nativas
Cualquiera que sea el enfoque que elija (hay algunas compensaciones a considerar), debe prestar atención a las mejores prácticas que se describen aquí para las aplicaciones nativas que usan OAuth2: https://tools.ietf.org/html/rfc8252
Considere las siguientes opciones
Implícito
¿Debo usar implícito?
Para citar de la Sección 8.2 https://tools.ietf.org/html/rfc8252#section-8.2
El flujo de autorización de concesión implícita de OAuth 2.0 (definido en la Sección 4.2 de OAuth 2.0 [RFC6749]) generalmente funciona con la práctica de realizar la solicitud de autorización en el navegador y recibir la respuesta de autorización a través de la comunicación entre aplicaciones basada en URI.
Sin embargo, como el flujo implícito no puede ser protegido por PKCE [RFC7636] (que se requiere en la Sección 8.1), NO SE RECOMIENDA el uso del flujo implícito con aplicaciones nativas. .
Los tokens de acceso otorgados a través del flujo implícito tampoco se pueden actualizar sin la interacción del usuario, lo que hace que el flujo de concesión del código de autorización, que puede emitir tokens de actualización, sea la opción más práctica para las autorizaciones de aplicaciones nativas que requieren la actualización de los tokens de acceso.
Código de Autorización
Si opta por el Código de autorización, entonces un enfoque sería utilizar un proxy a través de su propio componente de servidor web que enriquece las solicitudes de token con el secreto del cliente para evitar almacenarlo en la aplicación distribuida en los dispositivos.
Extracto a continuación de: https://dev.fitbit.com/docs/oauth2/
El flujo de concesión del código de autorización se recomienda para aplicaciones que tienen un servicio web. Este flujo requiere una comunicación de servidor a servidor utilizando el secreto de cliente de una aplicación.
Nota: Nunca ponga su secreto de cliente en código distribuido, como aplicaciones descargadas a través de una tienda de aplicaciones o JavaScript del lado del cliente.
Las aplicaciones que no tienen un servicio web deben utilizar el flujo de concesión implícita.
Conclusión
La decisión final debe tener en cuenta su experiencia de usuario deseada, pero también su apetito por el riesgo después de realizar una evaluación de riesgo adecuada de los enfoques seleccionados y comprender mejor las implicaciones.
Una gran lectura está aquí https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
Otro es https://www.oauth.com/oauth2-servers/oauth-native-apps/ que dice
La mejor práctica actual de la industria es utilizar el flujo de autorización mientras se omite el secreto del cliente y utilizar un agente de usuario externo para completar el flujo. Un agente de usuario externo suele ser el navegador nativo del dispositivo (con un dominio de seguridad separado de la aplicación nativa), de modo que la aplicación no puede acceder al almacenamiento de cookies o inspeccionar o modificar el contenido de la página dentro del navegador.
Consideración PKCE
También debe considerar PKCE que se describe aquí https://www.oauth.com/oauth2-servers/pkce/
Específicamente, si también está implementando el servidor de autorización, https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ indica que debe
- Permita que los clientes registren esquemas de URL personalizados para sus URL de redireccionamiento.
- Admite URL de redireccionamiento de IP de bucle invertido con números de puerto arbitrarios para admitir aplicaciones de escritorio.
- No asuma que las aplicaciones nativas pueden guardar un secreto. Exija que todas las aplicaciones declaren si son públicas o confidenciales, y solo emita secretos de cliente para aplicaciones confidenciales.
- Admite la extensión PKCE y requiere que los clientes públicos la utilicen.
- Intente detectar cuándo la interfaz de autorización está integrada en la vista web de una aplicación nativa, en lugar de iniciarse en un navegador del sistema, y rechace esas solicitudes.
Consideración de vistas web
Hay muchos ejemplos en la naturaleza que usan vistas web, es decir, un agente de usuario integrado, pero este enfoque debe evitarse (especialmente cuando la aplicación no es propia) y, en algunos casos, puede resultar en que se le prohíba el uso de una API como extracto abajo de aquí demuestra
Cualquier intento de insertar la página de autenticación de OAuth 2.0 resultará en que tu aplicación sea prohibida en la API de Fitbit.
Por motivos de seguridad, la página de autorización de OAuth 2.0 debe presentarse en una vista de navegador dedicada. Los usuarios de Fitbit solo pueden confirmar que se están autenticando con el sitio original de Fitbit.com si tienen las herramientas proporcionadas por el navegador, como la barra de URL y la información del certificado Transport Layer Security (TLS).
Para las aplicaciones nativas, esto significa que la página de autorización debe abrirse en el navegador predeterminado. Las aplicaciones nativas pueden usar esquemas de URL personalizados como URI de redireccionamiento para redirigir al usuario desde el navegador a la aplicación que solicita permiso.
Las aplicaciones de iOS pueden usar la clase SFSafariViewController en lugar de cambiar la aplicación a Safari. Está prohibido el uso de la clase WKWebView o UIWebView.
Las aplicaciones de Android pueden usar pestañas personalizadas de Chrome en lugar de cambiar la aplicación al navegador predeterminado. Está prohibido el uso de WebView.
Para aclarar aún más, aquí hay una cita de esta sección de un borrador anterior del enlace de mejores prácticas proporcionado anteriormente.
Los agentes de usuario integrados, comúnmente implementados con vistas web, son un método alternativo para autorizar aplicaciones nativas. Sin embargo, por definición, no son seguros para su uso por parte de terceros. Implican que el usuario inicie sesión con sus credenciales de inicio de sesión completas, solo para que se reduzcan a credenciales OAuth menos potentes.
Incluso cuando los utilizan aplicaciones de origen confiables, los agentes de usuario integrados violan el principio de privilegios mínimos al obtener credenciales más poderosas de las que necesitan, lo que potencialmente aumenta la superficie de ataque.
En implementaciones típicas basadas en vista web de agentes de usuario integrados, la aplicación host puede: registrar cada pulsación de tecla ingresada en el formulario para capturar nombres de usuario y contraseñas; enviar formularios automáticamente y omitir el consentimiento del usuario; copiar cookies de sesión y utilizarlas para realizar acciones autenticadas como usuario.
Alentar a los usuarios a ingresar credenciales en una vista web incrustada sin la barra de direcciones habitual y otras características de identidad que tienen los navegadores hace que sea imposible para el usuario saber si están iniciando sesión en el sitio legítimo, e incluso cuando lo están, los capacita que está bien ingresar credenciales sin validar el sitio primero.
Aparte de las preocupaciones de seguridad, las vistas web no comparten el estado de autenticación con otras aplicaciones o el navegador del sistema, lo que requiere que el usuario inicie sesión para cada solicitud de autorización y conduce a una mala experiencia de usuario.
Debido a lo anterior, NO SE RECOMIENDA el uso de agentes de usuario integrados, excepto cuando una aplicación de origen confiable actúa como el agente de usuario externo para otras aplicaciones o proporciona inicio de sesión único para varias aplicaciones de origen.
Los servidores de autorización DEBERÍAN considerar tomar medidas para detectar y bloquear inicios de sesión a través de agentes de usuario integrados que no sean los suyos, siempre que sea posible.
Aquí también se plantean algunos puntos interesantes: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- una