Come posso archiviare la chiave consumer OAuth v1 e il segreto per un client Twitter desktop open source senza rivelarlo all'utente?

Voglio creare un client twitter open-source, desktop client spesso. Mi capita di usare .NET come lingua e Twitterizer come wrapper OAuth / Twitter e la mia app verrà probabilmente rilasciata come open source.

Per ottenere un token OAuth, sono necessarie quattro informazioni:

1. Token di accesso (nome utente twitter)
2. Accesso segreto (password twitter)
3. Chiave del consumatore
4. Segreto del consumatore

Le seconde due informazioni non devono essere condivise, come una chiave privata PGP. Tuttavia, a causa della modalità di progettazione del flusso di autorizzazione OAuth, è necessario che siano presenti nell'app nativa. Anche se l'applicazione non era open source e la chiave / segreto del consumatore era crittografata, un utente abbastanza esperto poteva accedere alla coppia chiave / segreto del consumatore.

Quindi la mia domanda è: come aggirare questo problema? Qual è la strategia corretta per un client Twitter desktop per proteggere la sua chiave e il segreto del consumatore?

Ho trovato una risposta che rispecchia il percorso che stavo prendendo in considerazione di scendere su hueniverse . L'articolo, Beyond the OAuth Web Redirection Flow , offre alcuni suggerimenti, uno dei quali è un URL web che inoltra il processo di scambio di token. Devo trovare un modo per autenticare correttamente che la mia app è ciò che richiede l'autenticazione a questa pagina proxy. Tuttavia, ciò è possibile.

Potrei sbagliarmi, ma se si raggruppano le chiavi con l'app desktop o mobile, open source o meno, è possibile accedervi. Se servizi come Twitter e Tumblr ci obbligano a utilizzare l'API solo OAuth, abbiamo due opzioni:

• imposta un servizio proxy di autenticazione per ogni app
• raggruppa le chiavi con l'app

Il primo è più difficile e costoso, non necessariamente gestibile per le app piccole e open source. Quest'ultimo significa che l'app può essere bloccata e una volta che gli spammer rubano le chiavi. Poiché Twitter e Tumblr non offrono ancora un'opzione migliore e avvitano tutti i client desktop, compresi i client Open Source, esiste una proposta per distribuire le chiavi "Big Fish" e usarle come fallback .

Infine, esiste un'opzione per forzare ogni utente a ottenere le chiavi API.

La sezione 4.6 di RFC 5849 , che definisce OAuth 1, afferma che il segreto del consumatore non è mai stato inteso per l'uso da parte dei consumatori di desktop, nonostante l'uso di Twitter nella pratica. Come ha sottolineato Nelson Elhage in " Dear Twitter ", Twitter può e fa terminare le chiavi consumer dei client desktop, a condizione che il client non sia troppo grande per fallire. Esistono due soluzioni alternative per consentire l'uso di OAuth 1 in un'applicazione desktop o mobile.

Un modo è quello di delegare l'intero protocollo Twitter attraverso un server in cui operi. In questo modo, il segreto del consumatore rimane sul tuo server. Questa è la soluzione consigliata da Dick Hardt , editore delle specifiche OAuth 1. Questa soluzione alternativa non risolve i costi di gestione di questo server.

L'altro modo, come suggerito in un post di Raffi Krikorian al gruppo Google di Google per lo sviluppo e un post di Chris Steipp in una mailing list di Wikipedia, è "far registrare a ciascun utente la propria copia dell'applicazione desktop come proprio consumatore". Quindi l'utente copia e incolla la chiave consumer e il segreto consumer appena registrati nell'applicazione. Il manuale della tua applicazione dovrebbe quindi includere istruzioni dettagliate su come registrare una nuova applicazione sul sito degli sviluppatori di Twitter. Questa limitazione ufficiale presenta alcuni problemi pratici:

• Il tuo cliente dovrà affrontare uno svantaggio di usabilità rispetto ai noti clienti proprietari.
• Il modulo per creare una nuova app non sembra offrire un modo per precompilare i campi richiesti. Ciò significa che dovrai aggiornare la procedura dettagliata di registrazione nel tuo manuale ogni volta che Twitter modifica la procedura per la registrazione di un'app.
• Il contratto di sviluppo prevede che gli utenti abbiano l'età legale per stipulare un contratto vincolante. Ciò significa che un utente della tua applicazione di età compresa tra 13 e 17 anni deve avere un genitore che accetta l'accordo per conto dell'utente.
• La Politica per gli sviluppatori di Twitter vieta le applicazioni di registrazione di massa e "accovacciamento di nomi", che definisce come "invio di più applicazioni con la stessa funzione con nomi diversi". Non sono a conoscenza di alcun precedente sul fatto che Twitter abbia trattato gli utenti non collegati che hanno registrato copie separate di un'applicazione come "nomi abusivi".

Sto per rispondere ma ti avverto che non ho affrontato me stesso, sto andando fuori dalle migliori pratiche e dall'esperienza pertinente esistente;

Non me ne preoccuperei troppo. Se il tuo client è open source, avrà comunque accesso alla fonte, e provare a controllare ciò che fanno con il tuo programma va comunque contro la natura dell'open source (anche se, cosa importante, ciò che stai cercando di fare non lo fa ).

Se qualcuno ha abbastanza conoscenze per eseguire il debug del programma ed estrarre la chiave, probabilmente sapranno come fare di più e potresti benissimo perdere tempo a cercare di bloccare ulteriormente.

Come precauzione, cambierei le chiavi ogni tanto (se possibile), ma se tutto ciò che possono fare è fingere di essere il tuo programma, questo non mi sembra troppo serio.

Divulgazione completa, non ho familiarità con l'API di Twitter, l'API di Twitterizer, i requisiti oauth o qualsiasi altra cosa che ho detto che sembra discutibile;)

La chiave utente e il segreto sono associati all'applicazione e non associati all'utente. Con questo in formazione il provider OAuth sa con quale applicazione sta trattando. Il resto, token di accesso e segreto saranno ottenuti dopo aver completato i primi passi.

Vedi questo post del blog per ulteriori informazioni in quanto mostra come funziona il protocollo.