security - español - ¿Cuál es el flujo correcto de OAuth 2.0 para una aplicación móvil?

oauth2 token (5)

Estoy intentando implementar la autorización delegada en una API web para aplicaciones móviles que usan OAuth 2.0. Según la especificación, el flujo de concesión implícito no admite tokens de actualización, lo que significa que una vez que se concede un token de acceso por un período de tiempo específico, el usuario debe otorgar permisos a la aplicación una vez que el token caduque o se revoque. Supongo que este es un buen escenario para algunos códigos JavaScript que se ejecutan en un navegador como se menciona en la especificación. Intento minimizar las veces que el usuario debe otorgar permisos a la aplicación para obtener un token, por lo que parece que el flujo del Código de autorización es una buena opción, ya que admite tokens de actualización. Sin embargo, este flujo parece depender en gran medida de un navegador web para realizar las redirecciones. Me pregunto si este flujo sigue siendo una buena opción para una aplicación móvil si se utiliza un navegador web incorporado. ¿O debería ir con el flujo implícito?

Aclaración: aplicación móvil = aplicación nativa

Como se indica en otros comentarios y en algunas fuentes en línea, implícito es una opción natural para las aplicaciones móviles, sin embargo, la mejor solución no siempre es clara.

Aplicación nativa OAuth2 Mejores prácticas

Independientemente del enfoque que elija (hay algunas concesiones que 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

Implícito

¿Debería usar implícito?

Para citar 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 protegerse mediante 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 autorización otorgue flujo -que puede emitir tokens de actualización- 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 va con el Código de Autorización, entonces un enfoque sería el 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 debajo de: dev.fitbit.com/docs/oauth2

El flujo de concesión del código de autorización se recomienda para las aplicaciones que tienen un servicio web. Este flujo requiere comunicación de servidor a servidor utilizando el secreto de cliente de una aplicación.
Nota: Nunca ponga el secreto de su 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 usar el flujo de Otorgamiento implícito.

Conclusión

La decisión final debe tener en cuenta la experiencia de usuario deseada, pero también su apetito por el riesgo después de realizar una evaluación de riesgos adecuada de sus enfoques preseleccionados y comprender mejor las implicaciones.

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 de primera parte) y en algunos casos puede tener como resultado que se le prohíba utilizar una API como extracto debajo de dev.fitbit.com/docs/oauth2 demuestra

Cualquier intento de insertar la página de autenticación de OAuth 2.0 dará lugar a que su aplicación se excluya de 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 genuino de Fitbit.com si tienen las herramientas provistas por el navegador, como la barra de URL y la información del certificado de Seguridad de la capa de transporte (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 redirigir los URI para redirigir al usuario desde el navegador a la aplicación que solicita el permiso.
Las aplicaciones iOS pueden usar la clase SFSafariViewController en lugar de la aplicación que cambia a Safari. El uso de la clase WKWebView o UIWebView está prohibido.
Las aplicaciones de Android pueden usar pestañas personalizadas de Chrome en lugar de que la aplicación cambie al navegador predeterminado. El uso de WebView está prohibido.

Para mayor aclaración, aquí hay una cita de esta sección de un borrador anterior del enlace de mejores prácticas proporcionado anteriormente

Los usuarios-agentes integrados, comúnmente implementados con vistas web, son un método alternativo para autorizar aplicaciones nativas. Sin embargo, son inseguros para ser utilizados por terceros por definición. Implican que el usuario inicie sesión con sus credenciales de inicio de sesión completas, solo para tenerlas reducidas a credenciales de OAuth menos poderosas.
Incluso cuando son utilizados por aplicaciones de confianza, los usuarios-agentes incorporados violan el principio de privilegio mínimo al obtener credenciales más poderosas de las que necesitan, lo que puede aumentar la superficie de ataque.
En implementaciones típicas basadas en la vista web de agentes de usuario integrados, la aplicación host puede: registrar cada pulsación de tecla introducida en el formulario para capturar nombres de usuario y contraseñas; enviar automáticamente formularios y eludir el consentimiento del usuario; copie las cookies de sesión y úselas para realizar acciones autenticadas como usuario.
Animar 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 entrena que está bien ingresar credenciales sin primero validar el sitio.
Además 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 genere una experiencia de usuario deficiente.
Debido a lo anterior, NO SE RECOMIENDA el uso de agentes de usuario integrados, excepto cuando una aplicación de confianza actúa como el agente de usuario externo para otras aplicaciones o proporciona un inicio de sesión único para varias aplicaciones de primera.
Los servidores de autorización DEBEN considerar tomar medidas para detectar y bloquear los inicios de sesión a través de agentes de usuario integrados que no son los suyos, siempre que sea posible.

La experiencia de usuario más sencilla para la autenticación y la más fácil de implementar es insertar una vista web en su aplicación. Procese las respuestas recibidas por la vista web desde el punto de autenticación y detecte el error (cancelación del usuario) o la aprobación (y extraiga el token de los parámetros de consulta de url). Y creo que realmente puedes hacer eso en todas las plataformas. He hecho esto con éxito para lo siguiente: iOS, Android, Mac, Windows 8.1 aplicaciones de Windows, Windows 8.1 de la aplicación. Lo hice para los siguientes servicios: dropbox, google drive, onedrive, box, basecamp. Para las plataformas que no son Windows, estaba usando Xamarin, que supuestamente no expone todas las API específicas de la plataforma, pero sí expone lo suficiente para que esto sea posible. Entonces, es una solución bastante accesible, incluso desde una perspectiva multiplataforma, y no tiene que preocuparse por la interfaz de usuario del formulario de autenticación.

Lamentablemente, no creo que haya una respuesta clara a esta pregunta. Sin embargo, estas son las opciones que he identificado:

Si está bien preguntarle al usuario sus credenciales, entonces use las credenciales de la contraseña del propietario del recurso . Sin embargo, esto puede no ser posible por algunas razones, a saber
- Las políticas de usabilidad o seguridad prohíben la inserción de la contraseña directamente en la aplicación
- El proceso de autenticación se delega en un proveedor de identidad externo y se debe realizar a través de un flujo basado en redirección HTTP (por ejemplo, OpenID, SAMLP o WS-Federation)
Si se requiere el uso de un flujo basado en navegador, entonces use el flujo de código de autorización . Aquí, la definición de redirect_uri es un desafío importante, para el cual existen las siguientes opciones:
- Utilice la técnica descrita en https://developers.google.com/accounts/docs/OAuth2InstalledApp , donde un redirect_uri especial (por ejemplo, urn:ietf:wg:oauth:2.0:oob ) indica al punto final de la autorización que muestre el código de autorización en lugar de redireccionando a la aplicación del cliente. El usuario puede copiar este código manualmente o la aplicación puede intentar obtenerlo del título del documento HTML.
- Use un servidor localhost en el dispositivo (la administración del puerto puede no ser fácil).
- Utilice un esquema de URI personalizado (por ejemplo, myapp://... ) que cuando se desreferencia desencadena un "controlador" registrado (los detalles dependen de la plataforma móvil).
- Si está disponible, use una "vista web" especial, como WebAuthenticationBroker en Windows 8, para controlar y acceder a las respuestas de redireccionamiento HTTP.

Espero que esto ayude

Pedro

Usar una vista web en su aplicación móvil debería ser una forma asequible de implementar el protocolo OAuth2.0 en la plataforma Android.

En cuanto al campo redirect_uri, creo que http://localhost es una buena opción y no es necesario que onPageStarted un servidor HTTP dentro de tu aplicación, porque puedes anular la implementación de la función onPageStarted en la clase WebViewClient y dejar de cargar la página web desde http://localhost después de comprobar el parámetro url .

public void onPageStarted(final WebView webView, final String url, final Bitmap favicon) {}

TL; DR: utilice la concesión del código de autorización con PKCE

1. Tipo de subvención implícito

El tipo de subvención implícito es bastante popular entre las aplicaciones móviles. Pero no estaba destinado a ser usado así. Hay problemas de seguridad en torno a la redirección. Justin Richer dice :

El problema surge cuando se da cuenta de que, a diferencia de una URL de servidor remoto, no existe una forma confiable de garantizar que se respete la vinculación entre un URI de redirección determinado y una aplicación móvil específica. Cualquier aplicación del dispositivo puede intentar insertarse en el proceso de redirección y hacer que sirva al URI de redirección. Y adivina qué: si has utilizado el flujo implícito en tu aplicación nativa, entonces le has entregado al atacante tu token de acceso. No hay recuperación desde ese punto; tienen el token y pueden usarlo.

Y junto con el hecho de que no le permite actualizar el token de acceso, mejor evitarlo.

2. Tipo de concesión del código de autorización

La concesión del código de autorización requiere un secreto del cliente. Pero no debe almacenar información confidencial en el código fuente de su aplicación móvil. La gente puede extraerlos. Para no exponer el secreto del cliente, debe ejecutar un servidor como intermediario a medida que Facebook escribe :

Recomendamos que los tokens de acceso a la aplicación solo se utilicen directamente desde los servidores de su aplicación para proporcionar la mejor seguridad. Para las aplicaciones nativas, sugerimos que la aplicación se comunique con su propio servidor y luego el servidor realiza las solicitudes de la API a Facebook utilizando el token de acceso a la aplicación.

No es una solución ideal, pero hay una forma nueva y mejor de hacer OAuth en dispositivos móviles: clave de prueba para el intercambio de código

3. Tipo de concesión de código de autorización con PKCE (clave de prueba para el intercambio de código)

Fuera de las limitaciones, se creó una nueva técnica que le permite usar el Código de autorización sin un secreto de cliente. Puede leer el RFC 7636 completo o esta breve introducción .

PKCE (RFC 7636) es una técnica para proteger a clientes públicos que no usan un secreto de cliente.
Es utilizado principalmente por aplicaciones nativas y móviles, pero la técnica también se puede aplicar a cualquier cliente público. Requiere soporte adicional del servidor de autorización, por lo que solo es compatible con ciertos proveedores.

de PKCE