Як зберігати споживчий ключ та секрет OAuth v1 для клієнта Twitter з відкритим кодом, не розкриваючи його користувачеві?

Я хочу зробити клієнт з щільним клієнтом, робочий стіл, з відкритим кодом twitter. Я, мабуть, використовує .NET як мою мову, а Twitterizer - як мій оболонку OAuth / Twitter, і моя програма, швидше за все, буде випущена як відкритий код.

Щоб отримати маркер OAuth, потрібно чотири відомості:

1. Токен доступу (ім'я користувача twitter)
2. Секрет доступу (пароль twitter)
3. Споживчий ключ
4. Consumer Secret

Другі два фрагменти інформації не можна ділитися, як приватний ключ PGP. Однак, завдяки тому, як розроблений потік авторизації OAuth, вони повинні знаходитись у нативній програмі. Навіть якщо програма не була відкритим кодом, а споживчий ключ / секрет були зашифровані, досить кваліфікований користувач міг отримати доступ до споживчого ключа / секретної пари.

Отже, моє запитання полягає в тому, як мені вирішити цю проблему? Яка правильна стратегія для настільного клієнта Twitter для захисту свого споживчого ключа та секрету?

Я знайшов відповідь, яка відображає шлях, який я розглядав, як спускатися ввечері . Стаття, що знаходиться поза потоком перенаправлення веб-каналів OAuth , пропонує деякі пропозиції, однією з яких є URL-адреса веб-сайту, яка наближає процес обміну маркерами. Я повинен розробити спосіб належної автентифікації, що мій додаток вимагає аутентифікації на цій сторінці проксі. Однак це можливо.

Я можу помилятися, але якщо ви зв’язуєте ключі з настільним або мобільним додатком, відкритим кодом чи ні, доступ до них є. Якщо такі послуги, як Twitter та Tumblr, змушують нас використовувати API лише для OAuth, у нас є два варіанти:

• налаштування служби аутентичного проксі для кожного додатка
• ключі в комплекті з додатком

Перший є складнішим і затратнішим, не обов'язково піддається технічному обслуговуванню для невеликих програм із відкритим кодом. Останнє означає, що додаток може і буде заблоковано, як тільки спамери вкрадуть ключі. Оскільки Twitter і Tumblr ще не дають кращого варіанту, і накручують всіх настільних клієнтів, клієнтів з відкритим кодом включно, є пропозиція розповсюджувати клавіші "Big Fish" і використовувати їх як резервний .

Нарешті, є можливість змусити кожного користувача отримати ключі API.

Розділ 4.6 RFC 5849 , який визначає OAuth 1, зазначає, що споживча таємниця ніколи не була призначена для використання настільними споживачами, незважаючи на те, що її Twitter використовує на практиці. Як зазначив Нельсон Елхадж у "Шановному Твіттері ", Twitter може і дійсно скасовує споживчі ключі настільних клієнтів, за умови, що клієнт не надто великий, щоб не вийти з ладу. Але є два обхідні шляхи, які дозволяють використовувати OAuth 1 у настільному або мобільному додатку.

Один із способів - проксі весь протокол Twitter через сервер, на якому ви працюєте. Таким чином, секрет споживача залишається на вашому сервері. Це рішення, рекомендоване Діком Хардтом , редактором специфікації OAuth 1. Це вирішення не стосується витрат на роботу цього сервера.

Інший спосіб, як це запропоновано у публікації Раффі Крикоріана до групи розмов Google щодо розмови у Twitter та публікації Кріса Степпа до списку розсилки у Вікіпедії, - це "кожен користувач зареєструвати свою копію вашої настільної програми як свого споживача". Тоді користувач скопіює та вставить щойно зареєстрований споживчий ключ та таємницю споживача у вашу заявку. Посібник до вашої програми повинен включати детальні інструкції щодо того, як зареєструвати нову програму на веб-сайті розробника Twitter. Це офіційне обмеження має кілька практичних проблем:

• Ваш клієнт зіткнеться з недоліком зручності використання в порівнянні з відомими власними клієнтами.
• Форма для створення нової програми не виникає , щоб запропонувати спосіб попередньо заповнити необхідні поля. Це означає, що вам доведеться оновлювати посібник з реєстрації у вашому посібнику щоразу, коли Twitter змінить процедуру реєстрації програми.
• Договір розробника вимагає, щоб користувачі мали повноліття, щоб укласти обов'язковий договір. Це означає, що користувач вашої програми віком від 13 до 17 років повинен мати батьків, щоб прийняти угоду від імені користувача.
• Політика щодо розробників Twitter забороняє масове реєстрацію програм та "присідання імен", що визначається як "подання декількох додатків з однаковою функцією під різними іменами". Мені невідомий будь-який прецедент щодо того, чи Twitter ставився до споріднених користувачів, які зареєстрували окремі копії однієї програми як "розсічники імен".

Я збираюся відповісти, але буду попереджений, що я сам цього не займався, я переживаю кращі практики та існуючий відповідний досвід;

Я б не переживав про це занадто. Якщо ваш клієнт з відкритим вихідним кодом , то вони будуть мати доступ до джерела в будь-якому випадку, і намагаються контролювати те , що вони роблять з вашою програмою йде проти природи з відкритим вихідним кодом в будь-якому випадку (хоча важливо, що ви намагаєтеся зробити НЕ ).

Якщо хтось має достатньо знань для налагодження вашої програми та вилучення вашого ключа, він, ймовірно, знає, як зробити більше, ніж ви, і ви могли б дуже добре витрачати свій час, намагаючись далі відключитися.

У міру застереження я міняв би клавіші так часто (якщо це можливо), але якщо все, що вони можуть зробити, це прикидатися вашою програмою, ніж це не звучить для мене занадто серйозно.

Повне розкриття інформації, я не знайомий з API Twitters, API twitterizer, вимогами Oauth або чим-небудь іншим, що я сказав, що звучить сумнівно;)

Споживчий ключ та секрет пов'язані із додатком, а не зв'язані з користувачем. З огляду на це, постачальник OAuth знає, з якою програмою він має справу. Решта, маркер доступу та секрет будуть отримані після перших кроків.

Дивіться цю публікацію в блозі для отримання додаткової інформації, оскільки вона показує, як працює протокол.