Какъв е правилният OAuth 2.0 поток за мобилно приложение

Пояснение: Мобилно приложение = родно приложение

Както е посочено в други коментари и няколко източника онлайн, имплицитното изглежда като естествено подходящо за мобилни приложения, но най-доброто решение не винаги е ясно (и всъщност имплицитното не се препоръчва поради причините, обсъдени по-долу).

Най-добри практики за 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/, което гласи

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

Разглеждане на 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 адреси за пренасочване.
• Поддържайте обратни IP пренасочващи URL адреси с произволни номера на портове, за да поддържате настолни приложения.
• Не предполагайте, че родните приложения могат да пазят тайна. Изисквайте всички приложения да декларират дали са публични или поверителни и издавайте клиентски тайни само на поверителни приложения.
• Поддържайте разширението PKCE и изисквайте публичните клиенти да го използват.
• Опитайте се да откриете кога интерфейсът за оторизация е вграден в уеб изгледа на собствено приложение, вместо да се стартира в системен браузър, и отхвърлете тези заявки.

Разглеждане на изгледи в мрежата

Има много примери в дивата природа с използване на Web Views, т.е. вграден потребителски агент, но този подход трябва да се избягва (особено когато приложението не е от първа страна) и в някои случаи може да доведе до забрана за използване на API като извадка по-долу от тук демонстрира

Всеки опит за вграждане на страницата за удостоверяване на OAuth 2.0 ще доведе до забрана на вашето приложение от Fitbit API.

От съображения за сигурност страницата за оторизация на OAuth 2.0 трябва да бъде представена в специален изглед на браузъра. Потребителите на Fitbit могат да потвърдят, че се удостоверяват само с оригиналния сайт Fitbit.com, ако разполагат с инструментите, предоставени от браузъра, като URL лентата и информацията за сертификата за сигурност на транспортния слой (TLS).

За родните приложения това означава, че страницата за оторизация трябва да се отвори в браузъра по подразбиране. Родните приложения могат да използват персонализирани URL схеми като URI за пренасочване, за да пренасочат потребителя обратно от браузъра към приложението, което иска разрешение.

Приложенията за iOS може да използват класа SFSafariViewController вместо превключване на приложението към Safari. Използването на класа WKWebView или UIWebView е забранено.

Приложенията за Android може да използват персонализирани раздели на Chrome вместо приложението да превключва към браузъра по подразбиране. Използването на WebView е забранено.

За допълнително пояснение, ето цитат от този раздел на предишен проект на връзката за най-добра практика, предоставена по-горе

Вградените потребителски агенти, обикновено имплементирани с уеб изгледи, са алтернативен метод за оторизиране на собствени приложения. Те обаче не са безопасни за използване от трети страни по дефиниция. Те включват потребителя да влезе с пълните си идентификационни данни за вход, само за да ги намали до по-малко мощни идентификационни данни за OAuth.

Дори когато се използват от доверени приложения на първа страна, вградените потребителски агенти нарушават принципа на най-малко привилегии, като получават по-мощни идентификационни данни, отколкото са им необходими, потенциално увеличавайки повърхността на атака.

В типични базирани на уеб изглед реализации на вградени потребителски агенти, хост приложението може: да регистрира всяко натискане на клавиш, въведено във формуляра, за да улови потребителски имена и пароли; автоматично изпращане на формуляри и заобикаляне на съгласието на потребителя; копирайте сесийни бисквитки и ги използвайте за извършване на удостоверени действия като потребител.

Насърчаването на потребителите да въвеждат идентификационни данни във вграден уеб изглед без обичайната адресна лента и други функции за самоличност, които браузърите имат, прави невъзможно потребителят да знае дали влиза в легитимния сайт и дори когато влиза в него, той ги обучава че е добре да въвеждате идентификационни данни, без първо да потвърдите сайта.

Освен опасенията за сигурността, уеб изгледите не споделят състоянието на удостоверяване с други приложения или системния браузър, което изисква потребителят да влезе за всяка заявка за оторизация и води до лошо потребителско изживяване.

Поради горепосоченото използването на вградени потребителски агенти НЕ СЕ ПРЕПОРЪЧВА, освен когато доверено приложение на първа страна действа като външен потребителски агент за други приложения или осигурява единично влизане за множество приложения на първа страна.

Сървърите за оторизация ТРЯБВА да обмислят предприемането на стъпки за откриване и блокиране на влизания чрез вградени потребителски агенти, които не са техни собствени, когато е възможно.

Тук също се повдигат някои интересни точки: https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the-a

За съжаление не мисля, че има ясен отговор на този въпрос. Ето обаче опциите, които идентифицирах:

• Ако е добре да попитате потребителя за неговите/нейните идентификационни данни, тогава използвайте Идентификационните данни за парола за собственик на ресурс. Това обаче може да не е възможно поради някои причини, а именно

  • Usability or security policies forbid the insertion of the password directly at the app
  • Процесът на удостоверяване е делегиран на външен доставчик на идентичност и трябва да се извърши чрез базиран на HTTP пренасочване поток (напр. OpenID, SAMLP или WS-Federation)

• Ако се изисква използване на поток, базиран на браузър, тогава използвайте Потока на кода за оторизация. Тук дефиницията на redirect_uri е голямо предизвикателство, за което има следните опции:

  • Use the technique described in https://developers.google.com/accounts/docs/OAuth2InstalledApp, where a special redirect_uri (e.g. urn:ietf:wg:oauth:2.0:oob) signals the authorization endpoint to show the authorization code instead of redirecting back to the client app. The user can manually copy this code or the app can try to obtain it from the HTML document title.
  • Използвайте localhost сървър на устройството (управлението на портовете може да не е лесно).
  • Използвайте персонализирана URI схема (напр. myapp://...), която при дерефериране задейства регистриран „манипулатор“ (подробностите зависят от мобилната платформа).
  • Ако е наличен, използвайте специален „уеб изглед“, като например WebAuthenticationBroker в Windows 8, за да контролирате и достъп до HTTP пренасочващите отговори.

Надявам се това да помогне

Педро

TL;DR: Използвайте Предоставяне на код за оторизация с PKCE

1. Вид имплицитно предоставяне

Неявният тип грант е доста популярен при мобилните приложения. Но не беше предназначено да се използва по този начин. Има опасения за сигурността около пренасочването. Джъстин Ричър заявява:

Проблемът идва, когато осъзнаете, че за разлика от URL адреса на отдалечен сървър, няма надежден начин да се гарантира, че обвързването между даден URI за пренасочване и конкретно мобилно приложение се спазва. Всяко приложение на устройството може да се опита да се вмъкне в процеса на пренасочване и да го накара да обслужва URI адреса за пренасочване. И познайте какво: ако сте използвали имплицитния поток в собственото си приложение, тогава току-що сте предали на атакуващия своя маркер за достъп. Няма възстановяване от тази точка —„те имат токена и могат да го използват.

И заедно с факта, че не ви позволява да опресните токена за достъп, по-добре го избягвайте.

2. Тип предоставяне на код за оторизация

Предоставянето на код за оторизация изисква клиентска тайна. Но не трябва да съхранявате поверителна информация в изходния код на вашето мобилно приложение. Хората могат да ги извлекат. За да не разкриете тайната на клиента, трябва да стартирате сървър като посредник, както пише във Facebook :

Препоръчваме токените за достъп до приложението да се използват само директно от сървърите на приложението ви, за да се осигури най-добрата сигурност. За местни приложения предлагаме приложението да комуникира с вашия собствен сървър и сървърът след това да прави API заявки към Facebook, използвайки App Access Token.

Не е идеално решение, но има нов, по-добър начин за извършване на OAuth на мобилни устройства: Ключ за доказване за обмен на код

3. Тип предоставяне на код за упълномощаване с PKCE (ключ за доказателство за обмен на код)

От ограниченията беше създадена нова техника, която ви позволява да използвате кода за оторизация без клиентска тайна. Можете да прочетете пълния RFC 7636 или това кратко въведение.

PKCE (RFC 7636) е техника за защита на публични клиенти, които не използват клиентска тайна.

Използва се предимно от собствени и мобилни приложения, но техниката може да се приложи и към всеки публичен клиент. Изисква допълнителна поддръжка от сървъра за оторизация, така че се поддържа само от определени доставчици.

от https://oauth.net/2/pkce/

Използването на уеб изглед във вашето мобилно приложение трябва да бъде достъпен начин за внедряване на протокол OAuth2.0 на платформа Android.

Що се отнася до полето redirect_uri, мисля, че http://localhost е добър избор и не е нужно да пренасяте HTTP сървър във вашето приложение, защото можете да замените внедряването на функцията onPageStarted в класа WebViewClient и да спрете да зареждате уеб страницата от http://localhost, след като сте проверете параметъра url.

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}

Най-плавното потребителско изживяване за удостоверяване и най-лесното за внедряване е да вградите уеб изглед в приложението си. Обработете отговорите, получени от уеб изгледа от точката за удостоверяване и открийте грешка (анулиране от потребителя) или одобрение (и извлечете токен от параметрите на заявката на url). И мисля, че всъщност можете да направите това във всички платформи. Успешно направих тази работа за следното: ios, android, mac, приложения за Windows Store 8.1, приложение за Windows Phone 8.1. Направих това за следните услуги: dropbox, google drive, onedrive, box, basecamp. За платформите без Windows използвах Xamarin, за който се предполага, че не излага всички специфични за платформата API, но все пак изложи достатъчно, за да направи това възможно. Така че това е доста достъпно решение, дори от гледна точка на различни платформи, и не е нужно да се притеснявате за потребителския интерфейс на формуляра за удостоверяване.