Como armazeno a chave e o segredo do consumidor OAuth v1 para um cliente Twitter de desktop de código aberto sem revelá-la ao usuário?

Quero criar um cliente de Twitter de cliente espesso, desktop e de código aberto. Por acaso, estou usando o .NET como idioma e o Twitterizer como meu invólucro OAuth / Twitter, e meu aplicativo provavelmente será lançado como código aberto.

Para obter um token OAuth, são necessárias quatro informações:

1. Token de acesso (nome de usuário do twitter)
2. Segredo de acesso (senha do twitter)
3. Chave do consumidor
4. consumidor secreto

As duas últimas informações não devem ser compartilhadas, como uma chave privada PGP. No entanto, devido à maneira como o fluxo de autorização do OAuth é projetado, eles precisam estar no aplicativo nativo. Mesmo que o aplicativo não fosse de código aberto e a chave / segredo do consumidor fosse criptografada, um usuário razoavelmente qualificado poderia obter acesso ao par de chave / segredo do consumidor.

Então, minha pergunta é: como contornar esse problema? Qual é a estratégia adequada para um cliente de desktop do Twitter proteger sua chave e segredo do consumidor?

Encontrei uma resposta que reflete o caminho que eu estava pensando em seguir no hueniverse . O artigo, Além do fluxo de redirecionamento da Web OAuth , oferece algumas sugestões, uma delas sendo um URL da Web que proxies o processo de troca de token. Eu tenho que descobrir uma maneira de autenticar corretamente que meu aplicativo é o que está solicitando a autenticação para esta página de proxy. No entanto, isso é possível.

Posso estar errado, mas se você agrupar as chaves no aplicativo para computador ou móvel, de código aberto ou não, é possível acessá-las. Se serviços como o Twitter e o Tumblr nos forçarem a usar a API somente do OAuth, teremos duas opções:

• configurar um serviço de proxy de autenticação para cada aplicativo
• agrupar chaves com o aplicativo

O primeiro é mais difícil e caro, não necessariamente sustentável para aplicativos pequenos e de código aberto. O último significa que o aplicativo pode e será bloqueado quando os spammers roubarem as chaves. Como o Twitter e o Tumblr ainda não oferecem uma opção melhor e ferem todos os clientes de desktop, inclusive os de código aberto, há uma proposta para distribuir as chaves "Big Fish" e usá-las como substituto .

Por fim, existe uma opção para forçar todos os usuários a obter chaves de API.

A seção 4.6 da RFC 5849 , que define o OAuth 1, afirma que o segredo do consumidor nunca foi destinado ao uso por consumidores de desktop, apesar do uso do Twitter na prática. Como Nelson Elhage apontou em " Prezado Twitter ", o Twitter pode e encerra chaves de clientes de clientes de desktop, desde que o cliente não seja grande demais para falir. Mas existem duas soluções alternativas para permitir o uso do OAuth 1 em um aplicativo para computador ou celular.

Uma maneira é fazer proxy de todo o protocolo do Twitter por meio de um servidor que você opera. Dessa forma, o segredo do consumidor permanece no seu servidor. Essa é a solução alternativa recomendada por Dick Hardt , editor da especificação do OAuth 1. Esta solução alternativa não trata do custo de operação deste servidor.

A outra maneira, como sugerido em uma postagem de Raffi Krikorian para o grupo de discussão sobre desenvolvimento do Twitter do Google e uma postagem de Chris Steipp em uma lista de discussão da Wikipedia, é "fazer com que cada usuário registre sua cópia do aplicativo de desktop como seu próprio consumidor". Em seguida, o usuário copiava e colava a chave e o segredo do consumidor recém-registrados no aplicativo. O manual do seu aplicativo precisará incluir instruções detalhadas sobre como registrar um novo aplicativo no site do desenvolvedor do Twitter. Essa limitação oficial tem alguns problemas práticos:

• Seu cliente enfrentará uma desvantagem de usabilidade em comparação com clientes proprietários conhecidos.
• O formulário para criar um novo aplicativo não parece oferecer uma maneira de preencher previamente os campos obrigatórios. Isso significa que você precisará atualizar o passo a passo do registro no seu manual sempre que o Twitter alterar o procedimento para registrar um aplicativo.
• O contrato de desenvolvedor exige que os usuários tenham idade legal para assinar um contrato vinculativo. Isso significa que um usuário do seu aplicativo com idades entre 13 e 17 anos deve ter um pai ou mãe para aceitar o contrato em nome do usuário.
• A Política do desenvolvedor do Twitter proíbe aplicativos de registro em massa e "agachamento de nome", que define como "enviar vários aplicativos com a mesma função sob nomes diferentes". Não conheço nenhum precedente sobre se o Twitter tratou usuários não relacionados que registraram cópias separadas de um aplicativo como "posseiros de nomes".

Vou responder, mas esteja avisado de que não lidei com isso sozinho, estou partindo das melhores práticas e da experiência relevante existente;

Eu não me preocuparia muito com isso. Se o seu cliente for de código aberto, ele terá acesso à fonte de qualquer maneira, e tentar controlar o que eles fazem com o seu programa é contrário à natureza da fonte aberta (embora seja importante, o que você está tentando fazer não ).

Se alguém tiver conhecimento suficiente para depurar seu programa e extrair sua chave, provavelmente saberá fazer mais do que isso e você pode estar perdendo seu tempo tentando travar ainda mais.

Como precaução, eu trocava de chave de vez em quando (se possível), mas se tudo o que eles podem fazer é fingir que é seu programa, isso não me parece muito sério.

Divulgação completa, não estou familiarizado com a API do Twitters, a API do twitterizer, os requisitos do outh ou qualquer outra coisa que eu disse que parece questionável;)

A chave e o segredo do consumidor estão vinculados ao aplicativo e não ao usuário. Com isso em formação, o provedor OAuth sabe com qual aplicativo está lidando. O restante, token de acesso e segredo serão obtidos após as primeiras etapas.

Consulte esta postagem do blog para obter mais informações, pois mostra como o protocolo funciona.