¿Cómo almaceno la clave y el secreto del consumidor OAuth v1 para un cliente de Twitter de escritorio de código abierto sin revelarlo al usuario?

32

Quiero hacer un cliente de twitter de escritorio abierto y de cliente grueso. Estoy usando .NET como mi idioma y Twitterizer como mi contenedor OAuth / Twitter, y mi aplicación probablemente se lanzará como código abierto.

Para obtener un token OAuth, se requieren cuatro datos:

  1. Token de acceso (nombre de usuario de twitter)
  2. Secreto de acceso (contraseña de twitter)
  3. Clave del consumidor
  4. Secreto del consumidor

Las segundas dos piezas de información no deben compartirse, como una clave privada PGP. Sin embargo, debido a la forma en que está diseñado el flujo de autorización de OAuth, estos deben estar en la aplicación nativa. Incluso si la aplicación no fuera de código abierto y la clave / secreto del consumidor estuviera encriptada, un usuario razonablemente capacitado podría obtener acceso al par clave / secreto del consumidor.

Entonces mi pregunta es, ¿cómo puedo solucionar este problema? ¿Cuál es la estrategia adecuada para que un cliente de Twitter de escritorio proteja su clave y secreto de consumidor?

open-source desktop-application twitter oauth Justin Dearing
fuente
+1 También tengo esta misma preocupación. Sin embargo, la pregunta no es realmente específica para entornos de escritorio o Twitter: creo que este esquema de autenticación es muy común entre los servicios web.
vemv
Debido a que su pregunta puede resumirse en algo como "cómo almacenar datos secretos en un cliente", creo que puede atraer más respuestas si publica una nueva pregunta que es menos específica de Twitter. OMI
Jeff Welling
1
+1 También tengo curiosidad acerca de cuál es la mejor práctica aquí. En mi aplicación Qt, uso OAuth pero solo almaceno los detalles del Consumidor como cadenas (QString) en el binario.
febrero
1
Jeff, es una muy buena posibilidad. Estoy haciendo algo completamente malo con OAuth. Estoy empezando a tener la sensación de que se supone que debo usar el par clave / secreto del consumidor para generar secretos temporales y que tener un servicio web para generar esos secretos en algún lugar es el camino a seguir. Al generalizar esta pregunta más allá de OAuth, se perderán respuestas como esa.
Justin Dearing

Respuestas:

5

Encontré una respuesta que refleja el camino que estaba considerando bajar en hueniverse . El artículo, Más allá del flujo de redireccionamiento web de OAuth , ofrece algunas sugerencias, una de ellas es una url web que representa el proceso de intercambio de tokens. Tengo que encontrar una manera de autenticar adecuadamente que mi aplicación es la que solicita la autenticación en esta página proxy. Sin embargo, eso es posible.

Justin Dearing
fuente
3

Puedo estar equivocado, pero si agrupa las claves con la aplicación de escritorio o móvil, de código abierto o no, es posible acceder a ellas. Si servicios como Twitter y Tumblr nos obligan a usar API solo de OAuth, tenemos dos opciones:

  • configurar un servicio de proxy de autenticación para cada aplicación
  • paquete de llaves con la aplicación

El primero es más difícil y costoso, no necesariamente mantenible para aplicaciones pequeñas y de código abierto. Esto último significa que la aplicación puede y será bloqueada, una vez que los spammers roben las claves. Como Twitter y Tumblr aún no ofrecen una mejor opción, y atornillan a todos los clientes de escritorio, incluidos los de código abierto, existe una propuesta para distribuir las claves "Big Fish" y usarlas como reserva .

Finalmente, hay una opción para obligar a cada usuario a obtener claves API.

sastanin
fuente
3

La Sección 4.6 de RFC 5849 , que define OAuth 1, establece que el secreto del consumidor nunca fue destinado a los consumidores de escritorio, a pesar del uso de Twitter en la práctica. Como Nelson Elhage señaló en " Estimado Twitter ", Twitter puede y termina las claves de consumidor de los clientes de escritorio, siempre que el cliente no sea demasiado grande para fallar. Pero hay dos soluciones para permitir el uso de OAuth 1 en una aplicación de escritorio o móvil.

Una forma es proxy del protocolo de Twitter completo a través de un servidor que usted opera. De esta manera, el secreto del consumidor permanece en su servidor. Esta es la solución recomendada por Dick Hardt , editor de la especificación OAuth 1. Esta solución alternativa no aborda el costo de operar este servidor.

La otra forma, como se sugiere en una publicación de Raffi Krikorian al grupo de Google de charlas de desarrollo de Twitter y una publicación de Chris Steipp en una lista de correo de Wikipedia, es "hacer que cada usuario registre su copia de su aplicación de escritorio como su propio consumidor". Luego, el usuario copiará y pegará la clave de consumidor recién registrada y el secreto del consumidor en su aplicación. El manual de su aplicación deberá incluir instrucciones detalladas sobre cómo registrar una nueva aplicación en el sitio de desarrolladores de Twitter. Esta limitación oficial tiene algunos problemas prácticos:

  • Su cliente enfrentará una desventaja de usabilidad en comparación con clientes propietarios conocidos.
  • El formulario para crear una nueva aplicación no parece ofrecer una forma de rellenar previamente los campos obligatorios. Esto significa que tendrá que actualizar el tutorial de registro en su manual cada vez que Twitter cambie el procedimiento para registrar una aplicación.
  • El acuerdo de desarrollador requiere que los usuarios sean mayores de edad para firmar un contrato vinculante. Esto significa que un usuario de su aplicación de entre 13 y 17 años debe hacer que un padre acepte el acuerdo en nombre del usuario.
  • La Política de Desarrolladores de Twitter prohíbe las aplicaciones de registro masivo y la "ocupación de nombres", que define como "enviar múltiples aplicaciones con la misma función bajo diferentes nombres". No conozco ningún precedente sobre si Twitter ha tratado a los usuarios no relacionados que han registrado copias separadas de una aplicación como "ocupantes ilegales de nombres".
Damian Yerrick
fuente
-2

Voy a responder, pero tenga en cuenta que no me he ocupado de esto yo mismo, estoy dejando de lado las mejores prácticas y la experiencia relevante existente;

No me preocuparía demasiado por eso. Si su cliente es de código abierto, tendrá acceso a la fuente de todos modos, e intentar controlar lo que hace con su programa va en contra de la naturaleza del código abierto de todos modos (aunque lo importante es que lo que está tratando de hacer no lo hace ).

Si alguien tiene suficiente conocimiento para depurar su programa y extraer su clave, es probable que sepa cómo hacer más que eso y que muy bien podría estar perdiendo el tiempo tratando de bloquear aún más.

Como precaución, cambiaría las claves de vez en cuando (si es posible), pero si todo lo que pueden hacer es fingir que es su programa, eso no me parece demasiado serio.

Divulgación completa, no estoy familiarizado con la API de Twitters, la API de twitterizer, los requisitos adicionales, o cualquier otra cosa que dije que suena cuestionable;)

Jeff Welling
fuente
44
No se trata de tratar de controlar con lo que hacen con el programa, se trata de personas que se tergiversan. La clave y el secreto del consumidor es cómo le digo a Twitter "esta aplicación vino por mí" al igual que un certificado SSL proporciona confianza. Nunca distribuiría un certificado SSL con una aplicación web que escribí. Si las personas modifican mi aplicación, deberían solicitar su propia clave / secreto de consumidor y registrarse como el autor de la aplicación de Twitter para su compilación.
Justin Dearing
Excelente punto, tenía una sospecha furtiva para eso era la clave del consumidor, pero no estaba seguro. En ese caso, para ser honesto, yo no creo que es una manera de proteger su aplicación. Para mí, esto parece que Twitter eligió ese método para que las aplicaciones móviles puedan escribirse pero las de escritorio no; las plataformas móviles están bloqueadas en gran medida. En este caso, la mejor manera de ir a IMO es poner la clave en un archivo o variable por separado que no se libera con el código fuente. Que yo sepa, esto no va en contra de la GPL. Sin embargo, me encantaría que me demuestren que estoy equivocado en todo esto ...
Jeff Welling
-4

La clave y el secreto del consumidor están vinculados a la aplicación y no al usuario. Con esta información, el proveedor de OAuth sabe con qué aplicación se trata. El resto, el token de acceso y el secreto se obtendrán después de completar los primeros pasos.

Consulte esta publicación de blog para obtener más información, ya que muestra cómo funciona el protocolo.

Yblih
fuente