Jak przechowywać klucz klienta i klucz tajny OAuth v1 dla klienta Twittera typu open source bez ujawniania go użytkownikowi?

Chcę zrobić grubego klienta na pulpicie, twitterowego klienta typu open source. Zdarza się, że używam .NET jako mojego języka, a Twitterizer jako mojego opakowania OAuth / Twitter, a moja aplikacja prawdopodobnie zostanie wydana jako open source.

Aby uzyskać token OAuth, wymagane są cztery informacje:

1. Token dostępu (nazwa użytkownika Twittera)
2. Access Secret (hasło Twittera)
3. Klucz klienta
4. Tajemnica konsumencka

Drugich dwóch informacji nie należy udostępniać, podobnie jak klucz prywatny PGP. Jednak ze względu na sposób zaprojektowania przepływu autoryzacji OAuth muszą one znajdować się w aplikacji natywnej. Nawet jeśli aplikacja nie była oprogramowaniem typu open source, a klucz / klucz klienta został zaszyfrowany, odpowiednio wykwalifikowany użytkownik może uzyskać dostęp do pary klucz / klucz klienta.

Więc moje pytanie brzmi: jak obejść ten problem? Jaka jest właściwa strategia dla stacjonarnego klienta Twittera, aby chronić swój klucz klienta i sekret?

Znalazłem odpowiedź, która odzwierciedla ścieżkę, którą rozważałem, idąc na hueniverse . Artykuł Beyond the OAuth Web Redirection Flow zawiera kilka sugestii, z których jedną jest URL, który zastępuje proces wymiany tokenów. Muszę znaleźć sposób, aby poprawnie uwierzytelnić, że moja aplikacja żąda uwierzytelnienia na tej stronie proxy. Jest to jednak możliwe.

Mogę się mylić, ale jeśli połączysz klucze z aplikacją komputerową lub mobilną, open source, czy nie, możesz uzyskać do nich dostęp. Jeśli usługi takie jak Twitter i Tumblr zmuszają nas do korzystania z interfejsu API opartego tylko na OAuth, mamy dwie opcje:

• skonfiguruj usługę proxy uwierzytelniania dla każdej aplikacji
• pakiet kluczy z aplikacją

Ten pierwszy jest trudniejszy i bardziej kosztowny, niekoniecznie możliwy do utrzymania dla małych i otwartych aplikacji. To ostatnie oznacza, że ​​aplikacja może i zostanie zablokowana, gdy spamerzy ukradną klucze. Ponieważ Twitter i Tumblr nie dają jeszcze lepszej opcji, a wkręcają wszystkich klientów stacjonarnych, w tym klientów Open Source, istnieje propozycja dystrybucji kluczy „Big Fish” i wykorzystywania ich jako rezerwowych .

Wreszcie istnieje opcja zmuszenia każdego użytkownika do uzyskania kluczy API.

Sekcja 4.6 RFC 5849 , która definiuje OAuth 1, stanowi, że tajemnica konsumencka nigdy nie była przeznaczona do użytku przez użytkowników komputerów stacjonarnych, pomimo tego, że Twitter używa jej w praktyce. Jak zauważył Nelson Elhage w „ Drogi Twitterze ”, Twitter może usuwać klucze klientów klientów stacjonarnych i pod warunkiem, że klient nie jest zbyt duży, by upaść. Istnieją jednak dwa obejścia pozwalające na użycie OAuth 1 w aplikacji komputerowej lub mobilnej.

Jednym ze sposobów jest proxy całego protokołu Twitter za pośrednictwem obsługiwanego serwera. W ten sposób tajemnica konsumencka pozostaje na twoim serwerze. Jest to obejście zalecane przez Dicka Hardta , redaktora specyfikacji OAuth 1. To obejście nie dotyczy kosztu obsługi tego serwera.

Innym sposobem, jak sugeruje post Raffi Krikorian do grupy dyskusyjnej Google na temat rozwoju Twittera oraz post Chrisa Steippa na liście mailingowej Wikipedii, jest „ kazanie każdemu użytkownikowi zarejestrować swoją kopię aplikacji komputerowej jako własnego konsumenta”. Następnie użytkownik skopiuje i wklei nowo zarejestrowany klucz klienta i klucz tajny klienta do aplikacji. Podręcznik dla Twojej aplikacji musiałby wtedy zawierać szczegółowe instrukcje dotyczące rejestracji nowej aplikacji na stronie programisty Twittera. To oficjalne ograniczenie ma kilka praktycznych problemów:

• Twój klient spotka się z wadą użyteczności w porównaniu ze znanymi klientami.
• Wygląda na to, że formularz do utworzenia nowej aplikacji nie oferuje możliwości wstępnego wypełnienia wymaganych pól. Oznacza to, że będziesz musiał zaktualizować instrukcję rejestracji w swoim podręczniku, ilekroć Twitter zmieni procedurę rejestracji aplikacji.
• Umowa dewelopera wymaga, aby użytkownicy byli w wieku uprawniającym do zawarcia wiążącej umowy. Oznacza to, że użytkownik aplikacji w wieku od 13 do 17 lat musi poprosić rodzica o zaakceptowanie umowy w imieniu użytkownika.
• Polityka programisty Twittera zabrania masowej rejestracji aplikacji i „kucania nazw”, które definiuje jako „przesyłanie wielu aplikacji z tą samą funkcją pod różnymi nazwami”. Nie znam żadnego precedensu dotyczącego tego, czy Twitter traktował niepowiązanych użytkowników, którzy zarejestrowali osobne kopie jednej aplikacji, jako „squatters”.

Mam zamiar odpowiedzieć, ale ostrzegam, że sam sobie z tym nie poradziłem, rezygnuję z najlepszych praktyk i istniejących doświadczeń;

Nie martwiłbym się tym zbytnio. Jeśli twój klient jest open source, i tak będzie miał dostęp do źródła, a próba kontrolowania tego, co robią z twoim programem, i tak jest sprzeczna z naturą open source (choć ważne, to, co próbujesz zrobić, nie ma ).

Jeśli ktoś ma wystarczającą wiedzę do debugowania twojego programu i wyodrębnienia twojego klucza, prawdopodobnie wie, jak zrobić więcej niż to, a możesz równie dobrze marnować czas na próby dalszego blokowania.

Jako środek ostrożności zmieniałem klucze co jakiś czas (jeśli to możliwe), ale jeśli wszystko, co mogą zrobić, to udawać, że jesteś twoim programem, to nie brzmi dla mnie zbyt poważnie.

Pełne ujawnienie, nie jestem zaznajomiony z interfejsem API Twittera, interfejsem API Twittera, nadmiernymi wymaganiami lub czymkolwiek innym, co powiedziałem, co wydaje się wątpliwe;)

Klucz klienta i klucz tajny są powiązane z aplikacją, a nie z użytkownikiem. Mając to na uwadze, dostawca OAuth wie, z jaką aplikacją ma do czynienia. Reszta, token dostępu i sekret zostaną zdobyte po wykonaniu pierwszych kroków.

Zobacz ten post na blogu, aby uzyskać więcej informacji, ponieważ pokazuje on, jak działa protokół.