En resumen: se utilizan client_id y client_secret para autenticar APP .
username y password se usan para autenticar < fuerte> user .
También significa protección de doble capa.
La especificación dice:
el cliente DEBE autenticar con el servidor de autorización como se describe en Sección 3.2.1 .
La autenticación de un cliente se realiza utilizando un valor de client_id y client_secret .
En realidad, el último párrafo de la sección 3.2.1 dice
Un cliente público al que no se le emitió una contraseña de cliente PUEDE usar el parámetro de solicitud client_id para identificarse a sí mismo cuando envía solicitudes al punto final del token (por ejemplo, con el fin de proporcionar contexto de usuario final, estadísticas de uso del cliente).
Sin embargo, sólo puede.
Pero Google proporciona un client_id y un client_secret en la consola para desarrolladores cuando se intenta utilizar una API.
Si desea utilizar Resource Owner Password Credentials para una API o una autorización web, puede proporcionar una página de registro para que sus clientes se registren. (Recomiendo el uso de flujo de credenciales de cliente para API)
Si desea utilizar Resource Owner Password Credentials para una aplicación móvil, puede dar un estándar estándar como client_id como AwesomeAPP y un client_secret como Bl**123_Blabla .
O puede usar AwesomeAPP_v1.0 como client_id para hacer un seguimiento de cuánta gente usa qué versión de la aplicación, aunque no sea la mejor manera. Pero puedes.
Espero que esto ayude ...