Як зберегти конфіденційність облікових даних клієнта, використовуючи тип надання дозволу пароля власника ресурсу OAuth2

Ми будуємо послугу відпочинку та хочемо використовувати OAauth 2 для авторизації. Поточний проект (v2-16 від 19 травня) описує чотири типи гранту . Вони є механізмами або потоками для отримання авторизації (маркера доступу).

1. Код дозволу
2. Неявний грант
3. Повноваження власника ресурсу
4. Повноваження клієнта

Здається, нам потрібно підтримати всіх чотирьох, оскільки вони служать різним цілям. Перші два (і, можливо, останній) можна використовувати із сторонніх програм, які потребують доступу до API. Код авторизації - це стандартний спосіб авторизації веб-програми, якій пощастило знаходитись на захищеному сервері, тоді як неявний потік надання буде вибором для клієнтської програми, яка не може повністю тримати свої конфіденційні дані (наприклад, мобільний / настільний додаток, клієнт JavaScript тощо).
Ми хочемо використовувати третій механізм, щоб забезпечити кращу взаємодію з користувачами на мобільних пристроях - замість того, щоб переводити користувача у діалогове вікно входу у веб-браузері тощо, користувач просто введе своє ім’я користувача та пароль безпосередньо в програму та логін. Ми також хочемо використовувати тип надання клієнтських даних, щоб отримати маркер доступу, який можна використовувати для перегляду загальнодоступних даних, не пов'язаних з жодним користувачем. У цьому випадку це не стільки авторизація, скільки щось схоже на ключ API, який ми використовуємо для надання доступу лише тим програмам, які зареєструвались у нас, даючи нам можливість скасувати доступ за потреби.

Тож мої запитання:

1. Чи вважаєте ви, що я правильно зрозумів призначення різних видів грантів?
2. Як ви можете зберегти конфіденційність своїх даних клієнта? І в третьому, і в четвертому випадку нам потрібно мати ідентифікатор клієнта та секрет клієнта десь на клієнті, що не звучить як гарна ідея.
3. Навіть якщо ви використовуєте неявний тип надання та не розкриваєте секрет клієнта, що заважає іншій програмі видавати себе за ваш додаток за допомогою того самого механізму авторизації та ідентифікатора клієнта?

Підводячи підсумок, ми хочемо мати можливість використовувати облікові дані клієнта та облікові дані власника ресурсу з клієнтської програми. Обидва ці потоки вимагають від вас хоч якось зберігати таємницю клієнта, але клієнт - це мобільний додаток або додаток JavaScript, тому їх легко можна вкрасти.

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

Проблема полягає в тому, що, як ви зазначаєте, мій сервер API не може надійно перевірити client_id програми. Якщо я включаю client_secret до коду / пакету програми, тоді він доступний кожному, хто встановлює програму, тому вимагання client_secret не зробить процес більш безпечним. Отже, будь-який інший додаток може видавати себе за мій додаток, копіюючи client_id.

Просто направити відповіді на кожну з ваших точок:

1. Я продовжую перечитувати різні чернетки специфікації, щоб побачити, чи щось не змінилося, і зосереджуюсь здебільшого на розділі Повноваження пароля власника ресурсу, але я думаю, що ви маєте на них рацію. Клієнтські дані (4) Я думаю, що їх також може використовувати внутрішня або стороння служба, яка, можливо, потребуватиме доступу не лише до „загальнодоступної” інформації, наприклад, можливо, у вас є аналітика або щось, що потребує отримання інформації для всіх користувачів.

2. Я не думаю, що ви можете тримати щось конфіденційне щодо клієнта.

3. Ніхто не заважає комусь іншому використовувати ваш ідентифікатор клієнта. Це теж моє питання. Після того, як ваш код покине сервер і буде встановлений як додаток або запущений як Javascript у браузері, ви не зможете припустити, що щось секретне.

Що стосується нашого веб-сайту, у нас була проблема, подібна до тієї, яку ви описуєте з потоком облікових даних клієнта. У підсумку я переніс автентифікацію на сторону сервера. Користувач може автентифікуватися за допомогою нашого веб-додатку, але маркер OAuth для нашого API зберігається на стороні сервера та асоціюється з веб-сеансом користувача. Усі запити API, які робить код Javascript, насправді є викликами AJAX до веб-сервера. Отже, браузер не автентифікується безпосередньо за допомогою API, а замість цього має аутентифікований веб-сеанс.

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

Ви можете відстежувати / аналізувати використання кожного ключа API, щоб спробувати виявити зловживання, після чого ви можете зробити недійсним один ключ API і надати законному користувачеві новий. Це може бути найкращим варіантом, але це ніяк не безпечно.

Ви також можете використовувати для цього схему, схожу на Refresh Token, якщо хочете трохи щільніше зафіксувати її, хоча я не знаю, скільки ви справді отримаєте. Якщо у вас закінчився термін дії Javascript-токенів api один раз на день і ви вимагали від третьої сторони зробити якесь оновлення на стороні сервера за допомогою (секретного) маркера оновлення, то вкрадені маркери api ніколи не були б корисними більше доби. Може заохотити потенційних злодіїв символів просто зареєструватися. Але свого роду біль для всіх інших, тому не впевнений, що це того варте.