секрет клієнта в OAuth 2.0

Щоб використовувати goigle-накопичувач api, я повинен грати з аутентифікацією за допомогою OAuth2.0. І я отримав кілька запитань з цього приводу.

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

2. У мобільному додатку ми можемо вбудувати веб-перегляд у свій додаток. І легко витягнути поле пароля у веб-перегляді, тому що програма, яка запитує дозволу, насправді є "браузером".Отже, OAuth у мобільному додатку не має тієї переваги, що клієнтська програма не має доступу до облікових даних користувача постачальника послуг?

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

1. Так, існує реальна можливість для цього, і на цьому були деякі подвиги. Пропозиція - не тримати додаток у таємниці у вашому додатку, є навіть частина специфікації, що розповсюджені програми не повинні використовувати цей маркер. Тепер ви можете запитати, але XYZ вимагає цього для роботи. У такому випадку вони не реалізують специфікацію належним чином, і ви повинні A не користуватися цією послугою (малоймовірно) або B намагатися захистити маркер, використовуючи деякі обманюючі методи, щоб ускладнити пошук або використання вашого сервера як проксі.

   Наприклад, у бібліотеці Facebook для Android були деякі помилки, де вони просочували маркери до журналів, ви можете дізнатися більше про це тут http://attack-secure.com/all-your-facebook-access-tokens-are-belong -для нас і тут https://www.youtube.com/watch?v=twyL7Uxe6sk . Загалом, будьте дуже обережні щодо використання сторонніх бібліотек (власне здоровий глузд, але якщо викрадення токенів - це ваша велика стурбованість, додайте ще одну обережність).

2. Я блукав про пункт 2 вже досить давно. Я навіть зробив декілька обхідних шляхів у своїх додатках, щоб змінити сторінки згоди (наприклад, зміни масштабу та дизайну, щоб відповідати додатку), але нічого не заважало мені читати значення з полів всередині веб-перегляду з ім'ям користувача та паролем. Тому я повністю погоджуюся з вашим другим моментом і вважаю його великим «помилкою» в специфікації OAuth. Це означає, що "Додаток не отримує доступу до облікових даних користувачів" - це лише мрія і дає користувачам помилкове почуття безпеки ... Крім того, я думаю, що люди зазвичай підозрюють, коли програма запитує їх у своїх Facebook, Twitter, Dropbox або інших облікових даних. Я сумніваюся, що багато простих людей читають специфікацію OAuth і кажуть "Тепер я в безпеці", але натомість використовують здоровий глузд і, як правило, не використовують додатки, яким вони не довіряють.

У мене було те саме питання, що і в запитанні 1, і я нещодавно робив кілька досліджень, і я зробив висновок, що нормально не зберігати "таємницю клієнта" в таємниці. Тип клієнтів, які не зберігають конфіденційність клієнта в таємниці, називається "публічним клієнтом" у специфікації OAuth2. Можливість того, щоб хтось зловмисник зміг отримати код авторизації, а потім отримати доступ до маркера, перешкоджають наступні факти.

1. Клієнт повинен отримувати код авторизації безпосередньо від користувача, а не від служби

Навіть якщо користувач вказує на послугу, яку він довіряє клієнту, клієнт не може отримати код авторизації від послуги, лише показавши ідентифікатор клієнта та секрет клієнта. Натомість клієнт повинен отримати код авторизації безпосередньо від користувача. (Зазвичай це робиться шляхом перенаправлення URL-адрес, про який я розповім пізніше.) Отже, для зловмисного клієнта недостатньо знати ідентифікатор / секрет клієнта, якому довіряє користувач. Він повинен якось залучати або підробляти користувача, щоб надати йому код авторизації, що має бути складніше, ніж просто знати ідентифікатор / секрет клієнта.

2. URL-адреса перенаправлення реєструється з ідентифікатором / секретом клієнта

Припустимо, що зловмисний клієнт якось зумів залучити користувача та змусити її / його натиснути кнопку "Авторизувати цей додаток" на сторінці сервісу. Це призведе до реакції на переадресацію URL-адреси від сервісу до браузера користувача з кодом авторизації. Потім код авторизації буде надісланий з браузера користувача на URL-адресу переадресації, а клієнт повинен слухати URL-адресу переадресації, щоб отримати код авторизації. (URL-адреса для переадресації може бути і локальним господарем, і я зрозумів, що це типовий спосіб, коли "публічний клієнт" отримує код авторизації.) Оскільки ця URL-адреса переадресації зареєстрована в службі за допомогою ідентифікатора / секрета клієнта, зловмисний клієнт не робить мати спосіб контролю, куди надається код авторизації.

Відповідь на друге питання: API Google з причини безпеки вимагають, щоб автентифікацію / вхід не можна проводити в межах самого додатка (наприклад, веб-перегляди заборонені), і це потрібно робити поза додатком за допомогою браузера для кращої безпеки, що далі пояснюється нижче: https: //developers.googleblog.com/2016/08/moderising-oauth-interactions-in-native-apps.html