Tengo una aplicación Electron que requiere acceso a los usuarios de Google Drive y quiero implementar la funcionalidad de API sin tener que exponer el secreto del cliente. Según tengo entendido, esto es imposible de hacer en ciertos escenarios como aplicaciones móviles, pero ¿cuál es la forma correcta de hacerlo en una aplicación local?
Al intentar seguir las instrucciones de OAuth de la aplicación web de Google, parece que no puede usar este método en una aplicación local. Al intentar configurar el proceso OAuth de esta manera, ni siquiera le permite incluir localhost en la lista blanca como un dominio para autenticar a los usuarios (lo que interrumpe el proceso ya que esta es una aplicación local que se ejecuta en Electron). Agregue a eso este documento que publicó Google y también parece que no puede engañar al proceso de autenticación para pensar que no se está ejecutando en localhost, y tampoco puede ejecutar Node.js en el navegador (estoy usando Electron así que esto es imposible de hacer).
Luego traté de seguir su flujo de trabajo de aplicaciones móviles y de escritorio que parecía prometedor. El problema surge cuando necesita intercambiar el código de autorización para actualizar y acceder a los tokens . Esto nuevamente requiere que muestre su secreto de cliente en su aplicación principal. Luego pensé en dividir esto y hacer algo localmente y luego tener un servidor de autenticación que mantuviera el secreto del cliente e intercambió el código de autorización del cliente y devolvió una actualización y un token de acceso. Mirando el diagrama que proporciona Google para visualizar este proceso, muestra claramente que su aplicación necesita hacer ambas partes del proceso de autorización para que esa idea también se descartara.
Una aplicación que personalmente uso y miré fue rclone y, por lo que parece, solo enumeran su ID de cliente y su secreto directamente en su código . El secreto del cliente está encriptado, pero si sigue el flujo de trabajo, se revela con una clave que también se almacena localmente en la aplicación . Por lo tanto, su texto sin formato está oscurecido, pero no hay nada que impida que alguien obtenga el secreto del cliente modificando ligeramente el código.
También debo mencionar que esta aplicación está en un repositorio público en GitHub y permanecerá así.
Esta es la primera vez que uso OAuth, por lo que es posible que esté malinterpretando algo, pero traté de seguir la documentación lo más de cerca que pude y no puedo quitarme la sensación de que estoy pasando por alto una parte de este proceso.
Y si la única forma de resolver este problema es exponer tanto la identificación como el secreto del cliente, ¿hay alguna forma de que esto pueda comprometer los datos de los usuarios? Dado que la API de Google Drive es de uso gratuito, no me importa si otros usan parte de mi cuota. Estoy más preocupado por la seguridad.
Para clientes públicos como las aplicaciones de escritorio que está desarrollando, deberá usar el flujo PKCE. Tiene razón en que la documentación de Google parece estar fuera de lugar aquí: no debería necesitar pasar el client_secret como parte del intercambio de código de autorización.
Eso está respaldado por la documentación aquí: https://www.oauth.com/oauth2-servers/pkce/authorization-code-exchange/
Es posible que Google requiera el client_secret , pero no trata el parámetro como un "secreto" real para clientes públicos, sino como un identificador adicional que no es confidencial y no es suficiente por sí solo para hacer algo en nombre de su aplicación. La sección 8.5 de la especificación dice:
Los secretos que se incluyen de forma estática como parte de una aplicación distribuida a varios usuarios no deben tratarse como secretos confidenciales, ya que un usuario puede inspeccionar su copia y conocer el secreto compartido. Por esta razón, y las establecidas en la Sección 5.3.1 de [RFC6819], NO SE RECOMIENDA que los servidores de autorización requieran la autenticación del cliente de los clientes de aplicaciones nativas públicas mediante un secreto compartido, ya que esto tiene poco valor más allá de la identificación del cliente que ya se proporciona. por el parámetro de solicitud "client_id".
Los servidores de autorización que todavía requieren un secreto compartido incluido de forma estática para los clientes de aplicaciones nativas DEBEN tratar al cliente como un cliente público (como se define en la Sección 2.1 de OAuth 2.0 [RFC6749]) y no aceptar el secreto como prueba de la identidad del cliente. Sin medidas adicionales, dichos clientes están sujetos a suplantación de identidad (consulte la Sección 8.6).
También puede buscar proveedores de servicios OAuth independientes, como Xkit , donde trabajo. Eso le permitiría mantener la confidencialidad del secreto mientras sigue pasando por un flujo de OAuth.