secreto de cliente en OAuth 2.0

Para usar la API de Google Drive, tengo que jugar con la autenticación usando OAuth2.0. Y tengo algunas preguntas sobre esto.

1. La identificación del cliente y el secreto del cliente se utilizan para identificar cuál es mi aplicación. Pero deben estar codificados si se trata de una aplicación cliente. Entonces, todos pueden descompilar mi aplicación y extraerla del código fuente. ¿Significa que una mala aplicación puede pretender ser una buena aplicación usando la identificación del cliente y el secreto de la buena aplicación? Entonces, ¿el usuario estaría mostrando una pantalla que solicita otorgar permiso a una buena aplicación a pesar de que en realidad es solicitada por una mala aplicación? Si es así, ¿qué debo hacer? ¿O en realidad no debería preocuparme por esto?

2. En la aplicación móvil, podemos incrustar una vista web en nuestra aplicación. Y es fácil extraer el campo de contraseña en la vista web porque la aplicación que solicita permiso es en realidad un "navegador". Entonces, ¿OAuth en la aplicación móvil no tiene el beneficio de que la aplicación cliente no tiene acceso a la credencial de usuario del proveedor de servicios?

Comencé a escribir un comentario a su pregunta, pero luego descubrí que hay mucho que decir, así que aquí están mis puntos de vista sobre el tema en la respuesta.

1. Sí, existe una posibilidad real para esto y hubo algunos exploits basados ​​en esto. La sugerencia es no mantener la aplicación en secreto en su aplicación, incluso hay una parte en la especificación de que las aplicaciones distribuidas no deben usar este token. Ahora puede preguntar, pero XYZ lo requiere para funcionar. En ese caso, no están implementando la especificación correctamente y no debería A usar ese servicio (no es probable) o B intentar asegurar el token usando algunos métodos de ofuscación para hacer más difícil encontrar o usar su servidor como proxy.

   Por ejemplo, hubo algunos errores en la biblioteca de Facebook para Android donde se filtraban tokens a los registros, puede obtener más información al respecto aquí http://attack-secure.com/all-your-facebook-access-tokens-are-belong -a-nosotros y aquí https://www.youtube.com/watch?v=twyL7Uxe6sk . En general, tenga mucho cuidado con el uso de bibliotecas de terceros (en realidad, tiene sentido común, pero si el secuestro de tokens es su gran preocupación, agregue otro extra a la precaución).

2. He estado despotricando sobre el punto 2 durante bastante tiempo. Incluso he realizado algunas soluciones en mis aplicaciones para modificar las páginas de consentimiento (por ejemplo, cambiar el zoom y el diseño para que se ajusten a la aplicación), pero no hubo nada que me impidiera leer los valores de los campos dentro de la vista web con nombre de usuario y contraseña. Por lo tanto, estoy totalmente de acuerdo con su segundo punto y lo encuentro un gran "error" en las especificaciones de OAuth. El hecho de que "La aplicación no tiene acceso a las credenciales de los usuarios" en la especificación es solo un sueño y les da a los usuarios una falsa sensación de seguridad ... También creo que la gente suele sospechar cuando la aplicación les pide sus credenciales de Facebook, Twitter, Dropbox u otras. Dudo que mucha gente común lea las especificaciones de OAuth y diga "Ahora estoy a salvo", sino que usa el sentido común y, en general, no usa aplicaciones en las que no confía.

Tenía la misma pregunta que la pregunta 1 aquí, e investigué un poco yo mismo recientemente, y mi conclusión es que está bien no mantener en secreto el "secreto del cliente". El tipo de clientes que no mantienen la confidencialidad del secreto del cliente se denomina "cliente público" en la especificación OAuth2. Los siguientes hechos previenen la posibilidad de que alguien malintencionado pueda obtener el código de autorización y luego acceder al token.

1. El cliente debe obtener el código de autorización directamente del usuario, no del servicio.

Incluso si el usuario indica al servicio que confía en el cliente, el cliente no puede obtener el código de autorización del servicio simplemente mostrando la identificación y el secreto del cliente. En cambio, el cliente debe obtener el código de autorización directamente del usuario. (Esto generalmente se hace mediante la redirección de URL, de la que hablaré más adelante). Por lo tanto, para el cliente malintencionado, no es suficiente conocer la identificación / secreto del cliente en el que confía el usuario. Tiene que involucrar o engañar al usuario de alguna manera para darle el código de autorización, lo que debería ser más difícil que solo saber la identificación / secreto del cliente.

2. La URL de redireccionamiento está registrada con la identificación / secreto del cliente.

Supongamos que el cliente malicioso de alguna manera logró involucrar al usuario y hacer que haga clic en el botón "Autorizar esta aplicación" en la página de servicio. Esto activará la respuesta de redireccionamiento de URL desde el servicio al navegador del usuario con el código de autorización. Luego, el código de autorización se enviará desde el navegador del usuario a la URL de redireccionamiento, y se supone que el cliente debe estar escuchando la URL de redireccionamiento para recibir el código de autorización. (La URL de redireccionamiento también puede ser localhost, y supuse que esta es una forma típica en la que un "cliente público" recibe un código de autorización). Dado que esta URL de redireccionamiento está registrada en el servicio con la identificación / secreto del cliente, el cliente malicioso no tener una forma de controlar dónde se da el código de autorización.

Respondiendo a la segunda pregunta: las API de Google por motivos de seguridad exigen que la autenticación / inicio de sesión no se pueda realizar dentro de la aplicación en sí (como las vistas web no están permitidas) y debe realizarse fuera de la aplicación mediante el navegador para una mayor seguridad, que se explica a continuación: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html