¿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?

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?

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.

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.

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".

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;)

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.