Уточнення: Мобільний додаток = Рідний додаток
Як зазначається в інших коментарях та кількох джерелах в Інтернеті, неявний вигляд здається природним для мобільних додатків, проте найкраще рішення не завжди є чітким (і насправді неявне не рекомендується з причин, розглянутих нижче).
Основні методи використання OAuth2 для власного додатка
Який би підхід ви не вибрали (є кілька компромісів, на які слід звернути увагу), вам слід звернути увагу на найкращі практики, описані тут для рідних додатків, що використовують OAuth2: https://tools.ietf.org/html/rfc8252
Розглянемо наступні варіанти
Неявна
Чи слід використовувати неявний?
Процитую розділ 8.2 https://tools.ietf.org/html/rfc8252#section-8.2
Потік неявного дозволу OAuth 2.0 (визначений у Розділі 4.2 OAuth 2.0 [RFC6749]), як правило, працює з практикою виконання запиту авторизації у браузері та отримання відповіді авторизації за допомогою інтерфейсу зв'язку на основі URI.
Однак, оскільки неявний потік не може бути захищений PKCE [RFC7636] (що потрібно в Розділі 8.1), використання Імпліцитного потоку з власними програмами НЕ РЕКОМЕНДУЄТЬСЯ .
Маркери доступу, надані за допомогою неявного потоку, також не можуть бути оновлені без взаємодії з користувачем, що робить потік надання дозволу коду авторизації - який може видавати маркери оновлення - більш практичним варіантом для авторизацій власних додатків, які вимагають оновлення маркерів доступу.
Код дозволу
Якщо ви все-таки використовуєте Код авторизації, то одним із підходів буде проксі через ваш власний компонент веб-сервера, який збагачує запити маркерів секретом клієнта, щоб уникнути його зберігання у розподіленій програмі на пристроях.
Витяг нижче з: https://dev.fitbit.com/docs/oauth2/
Потік надання дозволу коду авторизації рекомендується для програм, що мають веб-службу. Цей потік вимагає зв'язку між серверами за допомогою секрету клієнта програми.
Примітка: Ніколи не вкладайте клієнтський секрет у розподілений код, наприклад програми, завантажені через магазин програм або на стороні клієнта JavaScript.
Програми, які не мають веб-служби, повинні використовувати потік неявного надання.
Висновок
Остаточне рішення повинно враховувати бажаний досвід користувачів, а також апетит до ризику після належної оцінки ризиків ваших підходів, що потрапили до списку, та кращого розуміння наслідків.
Чудове читання тут https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
Інший - https://www.oauth.com/oauth2-servers/oauth-native-apps/, де вказано
Сучасна галузева практика полягає у використанні потоку авторизації, опускаючи секрет клієнта, а також у використанні зовнішнього агента користувача для завершення потоку. Зовнішнім користувацьким агентом, як правило, є власний браузер пристрою (з окремим доменом безпеки від власного додатка), так що програма не може отримати доступ до сховища файлів cookie або перевірити або змінити вміст сторінки всередині браузера.
Розгляд PKCE
Ви також повинні розглянути PKCE, який описаний тут https://www.oauth.com/oauth2-servers/pkce/
Зокрема, якщо ви також впроваджуєте сервер авторизації, https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ стверджує, що вам слід
- Дозволити клієнтам реєструвати власні схеми URL-адрес для своїх URL-адрес переспрямування.
- Підтримка URL-адрес переспрямування IP із зворотним зв'язком із довільними номерами портів для підтримки програм на робочому столі.
- Не думайте, що рідні програми можуть зберігати таємницю. Вимагайте, щоб усі програми заявляли, є вони загальнодоступними чи конфіденційними, і видавати секретні клієнтські секрети лише конфіденційним програмам.
- Підтримуйте розширення PKCE і вимагайте, щоб його використовували публічні клієнти.
- Спроба виявити, коли інтерфейс авторизації вбудований у веб-перегляд власного додатка, а не запускається в системному браузері, і відхилити ці запити.
Розгляд веб-переглядів
У дикій природі є багато прикладів використання веб-переглядів, тобто вбудованого користувацького агента, але цього підходу слід уникати (особливо коли додаток не є власною стороною), і в деяких випадках це може призвести до заборони вам використовувати API як витяг нижче звідси демонструє
Будь-яка спроба вбудувати сторінку автентифікації OAuth 2.0 призведе до заборони вашої програми з API Fitbit.
З міркувань безпеки сторінка авторизації OAuth 2.0 повинна бути представлена у виділеному поданні браузера. Користувачі Fitbit можуть підтвердити автентичність на справжньому сайті Fitbit.com, лише якщо вони мають інструменти, надані браузером, такі як рядок URL-адреси та інформація про сертифікат транспортного рівня (TLS).
Для рідних програм це означає, що сторінка авторизації повинна відкриватися в браузері за замовчуванням. Власні програми можуть використовувати власні схеми URL-адрес як перенаправляючі URI, щоб перенаправити користувача назад із браузера до програми, що вимагає дозволу.
Додатки iOS можуть використовувати клас SFSafariViewController замість переходу програми на Safari. Використання класу WKWebView або UIWebView заборонено.
Додатки Android можуть використовувати спеціальні вкладки Chrome замість того, щоб перемикатися на браузер за замовчуванням. Використання WebView заборонено.
Для подальшого пояснення, ось цитата з цього розділу попереднього проекту посилання на найкращі практики, наведеного вище
Вбудовані користувацькі агенти, які зазвичай реалізуються з веб-переглядами, є альтернативним методом авторизації власних програм. Однак вони є небезпечними для використання третіми сторонами за визначенням. Вони включають в себе вхід користувача з повними обліковими даними для входу, лише для того, щоб зменшити їх до менш потужних облікових даних OAuth.
Навіть використовуючи довірені сторонні програми, вбудовані користувацькі агенти порушують принцип найменших привілеїв, отримуючи більш потужні облікові дані, ніж вони потребують, потенційно збільшуючи поверхню атаки.
У типових реалізаціях вбудованих агентів користувача, заснованих на веб-перегляді, програма-хост може: реєструвати кожне натискання клавіш, введене у форму, для захоплення імен користувачів та паролів; автоматично подавати форми та обходити згоду користувача; скопіюйте файли cookie сеансу та використовуйте їх для виконання автентифікованих дій як користувача.
Заохочення користувачів до введення облікових даних у вбудованому веб-перегляді без звичайного адресного рядка та інших функцій ідентифікації, які мають браузери, унеможливлює знання користувачем, чи входять вони на законний сайт, і навіть коли вони це роблять, він навчає їх що можна вводити облікові дані без попередньої перевірки сайту.
Окрім проблем безпеки, веб-перегляди не поділяють стан автентифікації з іншими програмами або системним браузером, що вимагає від користувача входу в систему для кожного запиту авторизації, що призводить до поганого користувацького досвіду.
У зв’язку з вищезазначеним, використання вбудованих агентів користувача НЕ РЕКОМЕНДУЄТЬСЯ, за винятком випадків, коли надійний власний додаток виступає зовнішнім агентом користувача для інших програм або забезпечує єдиний вхід для кількох сторонніх програм.
Сервери авторизації ПОВИННІ розглянути кроки для виявлення та блокування входів через вбудовані агенти користувачів, які не є їхніми, де це можливо.
Деякі цікаві моменти також піднімаються тут: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- a