OAuth2: concesión de credenciales de contraseña del propietario del recurso

Estas son realmente dos preguntas.

¿Cómo puedo garantizar que las solicitudes de fuentes que afirman ser esta aplicación cliente pueden ser confiables?

No puedes. El especificación dice :

  

El tipo de concesión de credenciales de contraseña del propietario del recurso es adecuado para   casos donde el propietario del recurso tiene una relación de confianza con el   cliente [...]

El propietario del recurso (también conocido como usuario) debe decidir si confía en el cliente, no en el servidor de autorización. Si el usuario decide confiar tanto en una aplicación de terceros que ingresa su contraseña simple, no podrá detectar automáticamente si la aplicación de terceros es confiable.

¿Qué les impide a los clientes realizar solicitudes de autenticación a ese punto final con el ID de cliente? Consideraría asignar al cliente un cliente_secret, pero parece que ganó. No resuelva el problema porque un usuario podría encontrarlo en la aplicación.

OAuth2 distingue entre clientes confidenciales y públicos . Los clientes confidenciales son "capaces de mantener la confidencialidad de sus credenciales" , por ejemplo, una aplicación web que accede a otra en el lado del servidor.

Las aplicaciones nativas (como una aplicación de Android) se mencionan explícitamente como clientes públicos:

  

Una aplicación nativa es un cliente público instalado y ejecutado en el   Dispositivo utilizado por el propietario del recurso. Los datos del protocolo y las credenciales son   Accesible para el propietario del recurso. Se asume que cualquier cliente   Las credenciales de autenticación incluidas en la aplicación pueden ser   extraído. [...]

Por lo tanto, un secreto de cliente no agregará seguridad a una aplicación nativa en la mayoría de los casos de uso.

¿Cómo puedo garantizar que las solicitudes de fuentes que afirman ser esta aplicación cliente pueden ser confiables?

No puedes.

Para citar otro SO respuesta :

  

La cuestión es que, en dispositivos móviles, la aplicación ya es confiable, una vez que el usuario ha instalado la aplicación, ha elegido confiar en ella. Finalmente, no creo que sea posible proteger completamente a los usuarios de un una vez que hayan decidido confiar en ella instalándola.

¿Qué les impide a los clientes realizar solicitudes de autenticación a ese punto final con el ID de cliente?

Nada.

Solo puede centrarse en proteger el nombre de usuario / contraseña de sus usuarios, por ejemplo:

• no los almacene dentro de su aplicación.
• eduque a sus usuarios con explicaciones claras sobre dónde obtener sus aplicaciones oficiales y por qué no deben confiar en ninguna otra aplicación que solicite sus credenciales.

Una pequeña explicación:

Para acceder a los recursos, una aplicación necesita obtener un token de acceso (y, finalmente, un token de actualización opcional).

Para obtener el token de acceso, se debe enviar una primera solicitud, incluido el nombre de usuario y la contraseña, al punto final. Nota: el client_id y el client_secret solo son obligatorios para los clientes confidenciales o para cualquier cliente que haya recibido las credenciales del cliente.

Por lo tanto, la aplicación malintencionada no puede acceder a ningún recurso hasta que obtiene el nombre de usuario y la contraseña, de lo contrario no podrá obtener un token de acceso. Incluso si utiliza la identidad de su aplicación oficial.

El ejemplo proporcionado es realmente un ejemplo realmente malo por la razón exacta que mencionó: un atacante puede simplemente extraer el secreto del cliente y hacerse pasar por el cliente.

La seguridad de esta concesión se basa en qué tan bien puede protegerse el secreto del cliente. Además, depende de qué tan bien se pueda proteger el canal, de manera que un atacante no pueda crear un hombre en el medio y extraer el secreto de la solicitud. Si puedes proteger ambos, entonces estás en un lugar bastante bueno, pero eso es realmente difícil de hacer para las aplicaciones móviles.

Para responder a tu pregunta: realmente no puedes. Puede mitigar algunos de estos problemas:

• usar ID de cliente y secretos únicos para cada instancia de la aplicación, pero eso complica seriamente la administración
• o puede almacenar los secretos en una ferretería de confianza, pero el protocolo requiere el secreto textual
• o puede modificar el protocolo para usar un identificador de cliente basado en token, como usar un token JWT o SAML firmado por el secreto del cliente, de esa manera se pasa una aserción de corta duración firmada por el secreto en lugar del secreto, etc.

Agregue todos esos elementos y tendrá una forma bastante sólida de identificar al cliente, pero ciertamente no es infalible y tiene sus inconvenientes: la capacidad de administración es un PITA, ¿cómo hace el intercambio secreto inicial ?, etc.