Смотрим документацию на ASWebAuthenticationSession от Apple:
Use an ASWebAuthenticationSession instance to authenticate a user through a web service, including one run by a third party. Initialize the session with a URL that points to the authentication webpage. When the user starts the authentication session, the operating system shows a modal view telling them which domain the app is authenticating with and asking whether to proceed. If the user proceeds with the authentication attempt, a browser loads and displays the page, from which the user can authenticate. In iOS, the browser is a secure, embedded web view. In macOS, the system opens the user’s default browser if it supports web authentication sessions, or Safari otherwise.
Выделю отдельно: "In iOS, the browser is a secure, embedded web view". Для полного понимания также рекомендую ознакомиться с AppAuth, для андроида также имеется. На данный момент критических уязвимостей в этих вариантах авторизации не выявлено, в конце концов разработчики стандартов авторизации не настолько дилетанта, чтобы оставить такую гору проблем в своих решениях, можете мне поверить.
Я неверно выразился - на самом деле мобильное приложение ВК (если бы это был flow OAuth) было бы User Agent, а не клиентом. Клиент это сам сервер авторизации ВК, поэтому делегирование тут бессмысленно - сервер ВК не станет же просить доступа у себя самого
Извините, но это тоже неверные утверждения, либо я не понимаю что вы имеете в виду. В спецификациях четко прописаны роли в oauth 2.0, но если кто-то их как то иначе интерпретирует, то это явно не проблема стандарта. Сервер авторизации это не клиент, а скаченное из app store приложение должно авторизовываться на сервере, через его web интерфейс.
Это приложение подходит под ваше определение? Ему можно доверять? Как оно будет вас авторизовывать? И это app store, 4,5 звезды.
Вы упускаете момент, что OAuth разрабатывался для браузеров, где действительно приложение не может залезть в соседнюю вкладку и посмотреть креды, поэтому принцип «не давать креды напрямую приложению» работает. В случае нативных приложений это не работает, потому что оно фактически имеет полный доступ к любым WebView, которое оно открывает, и в этом разделении нет смысла.
Возможно, вместе со мной все это упускают разработчики AppAuth, google, сообщество spring security, keycloak и все, кто разрабатывал этот стандарт. Такое вполне возможно, но я не думаю что это так. Скорее что-то упускают разработчики мобильных приложений, которые делают свои системы безопасности как-то иначе. Вам так не кажется?
Как минимум зловреду нужно знать client_id, а даже если он его получит, то ему все также надо пройти authorization code flow. Злоумышленник может создать приложение, которое перехватывает такие же редиректы, как у нашего приложение. Но с Proof Key for Code Exchange by OAuth Public Clients эта проблема решается.
Авторы спецификации подразумевали, что first party app по умолчанию обладает большим уровнем доверия. Как его достичь не уточняется, но это может быть, например, внутреннее приложение компании (для какой-нибудь курьерской службы, например), по сути это и есть first party app - предустановленный софт либо внутренние разработки не для массового сегмента. Вот что говорит microsoft по этому поводу на своем форуме.
В целом, я согласен, что при прочих равных условиях это небезопасно и противоречит оригинальной идее oauth 2.0
Так так так, браузер получает и отправляет сетевые запросы для авторизации и получения токена сессии, приложение делает то же самое, но не рендерит html+css. В чём разница получается? В том, что не видим, на какой домен мы отправляем данные? Ну я лично не думаю что Тинькофф украдёт мой номер телефона и код для входа в тинькоффк.
Тинькофф точно не украдет ваш номер телефона, по крайней мере мы хотим в этой верить)) А вот оно украдет. И как понять, что вы ввели логин пароль не в приложение т-банка а вот сюда? Окно браузера с всплывающим предупреждением дает хоть какой-то шанс на, что пользователь обратит внимание на то, куда он вводит логин и пароль. Особенно если он это делал годами и другого варианта у него нет.
И в чём проблема для фейковых приложений открыть страничку в браузере и просто получить токен сессии??? Это наоборот более уязвимая и простая для мошенников стратегия: пользователь увидит что домен настоящий и откинет сомнения, не надо пытаться повторить формы авторизации, все двухфакторки пользователь подтвердит сам, а зловред получит готовенький токен.
В момент редиректа зловредное приложение и правда может перехватить любые данные. Для этого был придуман Proof Key for Code Exchange by OAuth Public Clients - использование code_verifier иcode_challenge . Кроме того, если использовать universal links или applink, то такая атака в принципе не сработает.
Because this specification enables a client application to interact directly with the end user, and the application handles sending any information collected from the user to the authorization server, it is expected to be used only for first-party applications when the authorization server also has a high degree of trust of the client.
This specification is not prescriptive on how the Authorization Server establishes it's trust in the first-partyness of the application. For mobile platforms, most support some mechanism for application attestation that can be used to identify the entity that created/signed/uploaded the app to the app store. App attestation can be combined with other mechanisms like Dynamic Client Registration [RFC7591] to enable strong client authentication in addition to client verification (first-partyness). The exact steps required are out of scope for this specification. Note that applications running inside a browser (e.g. Single Page Apps) context it is much more difficult to verify the first-partyness of the client. Please see Section 9.8 for additional details.
То есть в спецификации подразумевается, что между клиентов (приложением) и сервером авторизации есть некоторая степень доверия, а уже как она была достигнута, в спецификации не уточняется. Сказано лишь, что "есть какие-то способы это сделать в современных мобильных приложениях". Мы уже видели эти способы, как оно работает на самом деле и можно ли доверять на 100% сторам.
И тут же идут пункты 9.2 и 9.3, где прямым текстом говорится, что это не очень то и безопасно:
There are two ways using this specification increases the risk of phishing.
With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server. If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application.
In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites. By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials.
Благодаря этой спецификации клиент напрямую взаимодействует с конечным пользователем, собирая предоставленную пользователем информацию и отправляя ее на сервер авторизации. Если злоумышленник выдает себя за клиента и успешно обманом заставляет пользователя использовать его, он может не осознавать, что передает свои учетные данные вредоносному приложению.
Не стоит забывать, что пока что это драфт, т.е. эта версия стандарта еще не принята, что неудивительно, т.к. вопросов очень много. В любом случае ни одно из существующих, например, в app store приложений не может эту спецификацию реализовывать, т.к. ее еще банально нет. И как будто бы, из того, что я вижу она провисит в драфте не один год, пока не будет придуман тот самый механизм "app attestation", чтобы можно было устанавливать доверительные отношения между клиентом и сервером, но слабо себе представляю что это будет за механизм. Поэтому сейчас ничего лучше OAuth 2.0 for Native Apps сейчас нет, по крайней мере так считают эксперты мирового уровня.
First party application это, то что идет в комплекте с вашим девайсом. Если у вас iphone, то все, что там установлено по умолчанию это и есть first party application - safari, заметки и т.д. Для таких приложений сейчас принимаются попытки написать стандарт, цитату из которого вы привели. Приложение сбера или вк были бы first party application если бы его разработчиком был apple. Поэтому для вашего девайса (iphone например) это самые что ни на есть third party app и всегда есть отличный от нуля шанс скачать из app store что-то не то под видом сбера или вк. И ввести туда логин и пароль (который очень часто одинаковый везде, где только можно). Тут не идет речи о том, чтобы полностью решить эту проблему, это невозможно, но хотя бы сократить поверхность атак - если 40% пользователей обратят внимание, на то, что страница в браузере не та, то это уже хорошо.
В first party apps все немного по-другому, там могут быть утечки пароля или логина с последующим перехватом их трояном например. Все, что мы ставим себе из сторов это не first party apps и там лучше следовать рекомендациям rfc. Грубо говоря, камере на айфоне это не нужно,т.к. это first party app, а вот сберу из app store не помешало бы, т.к. это third party app.
Вы предлагаете отдельное окно, и считаете это критически важным?
Это не я предлагаю и считаю это критически важным, это предлагает rfc и ouath 2.0 в целом (и считает не просто критически важным, а основной идеей всего фрэймворка).
Ну т.е. исходные данные для меня простые - я доверяю своему банку деньги. И я доверяю его приложению (хотя разумеется, допускаю, что там могут быть баги). И когда я ставлю это приложение, я убеждаюсь дважды, что оно настоящее. В противном же случая я не вижу разницы. Если вы видите - поясните, в чем она?
К сожалению это то, к чему мы пришли на данный момент. С точки зрения rfc и oauth 2.0 в целом доверять нужно серверу авторизации, чью страницу для ввода логина и пароля мы видим в браузере. Точка. Можно с этим спорить, но это факт. На этой идее основаны современные мобильные sdk, так работает keycloak, и не просто так мэйнтейнеры того же keycloak нас предупреждают:
Secure authentication is always about doing the proper things on the secure server, aka Keycloak, with the use of the users browser. Please, do yourself and your users a favor and read and understand the specs, before implementing “something that just somehow” works.
Безопасная аутентификация всегда предполагает выполнение правильных действий на защищенном сервере, известном как Keycloak, с использованием браузера пользователя. Пожалуйста, сделайте себе и своим пользователям одолжение: прочитайте и поймите спецификации, прежде чем внедрять «что-то, что каким-то образом» работает.
Еще раз цитата из rfc:
The resource owner password credentials grant [RFC6749] MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the authorization server) and users are trained to enter their credentials in places other than the authorization server.
Даже если клиент безопасен, это приводит к увеличению поверхности атаки (учетные данные могут просачиваться не только на сервер авторизации), а пользователей обучают вводить свои учетные данные не только на сервере авторизации.
Эта идея - суть есть краеугольный камень всего oauth 2.0 (и не только). Ее можно критиковать (в некоторых аспектах вполне обоснованно), но реальность такова, что конкурентоспособной альтернативы предложено не было. И, к сожалению, эта идея почему-то вызывает у людей отторжение, видимо годами привыкшие вводить свои данные в нативные компоненты приложения, пользователи начали считать это нормой.
@sshikov имеет в виду, что делегирование аутентификации/авторизации не нужно для first-party клиента - OAuth/OpenID придумали для third-party клиентов
Это неверное утверждение. First patry application - это приложение, созданное разработчиком самой платформы, например, предустановленные приложения для ios, разработчик которых apple. Для таких приложение есть особая авторизация, которая пока еще в драфте. В таких приложениях риски всегда ниже, поэтому стандартные процессы Oauth 2.0 во многом бессмысленны. Что сбер, что вк разработали не google и не apple, и они уж точно не предустановлены ни в одну из ОС.
Погодите. С чего вы решили, что при входе в приложение банка я доверяю google.com, которому одновременно доверяет и банк? В приложение Сбер/Тиньков можно войти по кредам гугля? И давно ли?
В статье речь шла не про вход по кредам гугла в приложениях сбера или тинька, а про то, что вход в них должен осуществляться через отдельное браузерное окно как и предполагает Oauth 2.0.
В моем понимании, Сбер скажем использует Oauth не когда вы входите в Сбербанк Онлайн, а когда вы входите куда-то по СберID, т.е. именно сервис Сбера и является тем, кто аутентифицирует пользователя.
Даже если это и правда, то так делать, как Сбер, категорически неверно. В rfc вполне четко прописан процесс авторизации для мобильных приложений, а если компания так, как написано в стандарте делать не хочет, то она не только подвергает своих пользователей лишней опасности, но и учит их доверять учетные данные своему приложению, а не серверу авторизации (тому же СберID или "Сбер Онлайн", неважно), что в общем-то прямо и сказано в спецификации. Отсюда и результат. Особенно интересно читать отзывы в app store от тысяч пользователей, которые установили себе эти приложения и чьи учетные данные угнали.
Увы, это факт. Поэтому при запросе авторизации приложение дает предупреждение о том, что будет использовано для авторизации, а в браузерном окне виден адрес сервера авторизации. Это не решит проблему в 10 из 10 случаев, но как минимум позволит уменьшить поверхность атаки для наиболее внимательных пользователей, особенно если они годами вводили логин и пароль именно таким способом.
Смотрим документацию на
ASWebAuthenticationSessionот Apple:Выделю отдельно: "In iOS, the browser is a secure, embedded web view". Для полного понимания также рекомендую ознакомиться с AppAuth, для андроида также имеется. На данный момент критических уязвимостей в этих вариантах авторизации не выявлено, в конце концов разработчики стандартов авторизации не настолько дилетанта, чтобы оставить такую гору проблем в своих решениях, можете мне поверить.
Извините, но это тоже неверные утверждения, либо я не понимаю что вы имеете в виду. В спецификациях четко прописаны роли в oauth 2.0, но если кто-то их как то иначе интерпретирует, то это явно не проблема стандарта. Сервер авторизации это не клиент, а скаченное из app store приложение должно авторизовываться на сервере, через его web интерфейс.
Это приложение подходит под ваше определение? Ему можно доверять? Как оно будет вас авторизовывать? И это app store, 4,5 звезды.
Возможно, вместе со мной все это упускают разработчики AppAuth, google, сообщество spring security, keycloak и все, кто разрабатывал этот стандарт. Такое вполне возможно, но я не думаю что это так. Скорее что-то упускают разработчики мобильных приложений, которые делают свои системы безопасности как-то иначе. Вам так не кажется?
Как минимум зловреду нужно знать
client_id,а даже если он его получит, то ему все также надо пройтиauthorization code flow.Злоумышленник может создать приложение, которое перехватывает такие же редиректы, как у нашего приложение. Но с Proof Key for Code Exchange by OAuth Public Clients эта проблема решается.Авторы спецификации подразумевали, что first party app по умолчанию обладает большим уровнем доверия. Как его достичь не уточняется, но это может быть, например, внутреннее приложение компании (для какой-нибудь курьерской службы, например), по сути это и есть first party app - предустановленный софт либо внутренние разработки не для массового сегмента. Вот что говорит microsoft по этому поводу на своем форуме.
В целом, я согласен, что при прочих равных условиях это небезопасно и противоречит оригинальной идее oauth 2.0
Тинькофф точно не украдет ваш номер телефона, по крайней мере мы хотим в этой верить)) А вот оно украдет. И как понять, что вы ввели логин пароль не в приложение т-банка а вот сюда? Окно браузера с всплывающим предупреждением дает хоть какой-то шанс на, что пользователь обратит внимание на то, куда он вводит логин и пароль. Особенно если он это делал годами и другого варианта у него нет.
В момент редиректа зловредное приложение и правда может перехватить любые данные. Для этого был придуман Proof Key for Code Exchange by OAuth Public Clients - использование
code_verifierиcode_challenge. Кроме того, если использовать universal links или applink, то такая атака в принципе не сработает.В то же время там написано вот что:
То есть в спецификации подразумевается, что между клиентов (приложением) и сервером авторизации есть некоторая степень доверия, а уже как она была достигнута, в спецификации не уточняется. Сказано лишь, что "есть какие-то способы это сделать в современных мобильных приложениях". Мы уже видели эти способы, как оно работает на самом деле и можно ли доверять на 100% сторам.
И тут же идут пункты 9.2 и 9.3, где прямым текстом говорится, что это не очень то и безопасно:
Благодаря этой спецификации клиент напрямую взаимодействует с конечным пользователем, собирая предоставленную пользователем информацию и отправляя ее на сервер авторизации. Если злоумышленник выдает себя за клиента и успешно обманом заставляет пользователя использовать его, он может не осознавать, что передает свои учетные данные вредоносному приложению.
Не стоит забывать, что пока что это драфт, т.е. эта версия стандарта еще не принята, что неудивительно, т.к. вопросов очень много. В любом случае ни одно из существующих, например, в app store приложений не может эту спецификацию реализовывать, т.к. ее еще банально нет. И как будто бы, из того, что я вижу она провисит в драфте не один год, пока не будет придуман тот самый механизм "app attestation", чтобы можно было устанавливать доверительные отношения между клиентом и сервером, но слабо себе представляю что это будет за механизм. Поэтому сейчас ничего лучше OAuth 2.0 for Native Apps сейчас нет, по крайней мере так считают эксперты мирового уровня.
Кстати СберID это не платформа как таковая, а сервер авторизации. Мне кажется, что это очень сильно кастомизированная keycloak., но могу ошибаться.
First party application это, то что идет в комплекте с вашим девайсом. Если у вас iphone, то все, что там установлено по умолчанию это и есть first party application - safari, заметки и т.д. Для таких приложений сейчас принимаются попытки написать стандарт, цитату из которого вы привели. Приложение сбера или вк были бы first party application если бы его разработчиком был apple. Поэтому для вашего девайса (iphone например) это самые что ни на есть third party app и всегда есть отличный от нуля шанс скачать из app store что-то не то под видом сбера или вк. И ввести туда логин и пароль (который очень часто одинаковый везде, где только можно). Тут не идет речи о том, чтобы полностью решить эту проблему, это невозможно, но хотя бы сократить поверхность атак - если 40% пользователей обратят внимание, на то, что страница в браузере не та, то это уже хорошо.
В first party apps все немного по-другому, там могут быть утечки пароля или логина с последующим перехватом их трояном например. Все, что мы ставим себе из сторов это не first party apps и там лучше следовать рекомендациям rfc. Грубо говоря, камере на айфоне это не нужно,т.к. это first party app, а вот сберу из app store не помешало бы, т.к. это third party app.
Это не я предлагаю и считаю это критически важным, это предлагает rfc и ouath 2.0 в целом (и считает не просто критически важным, а основной идеей всего фрэймворка).
К сожалению это то, к чему мы пришли на данный момент. С точки зрения rfc и oauth 2.0 в целом доверять нужно серверу авторизации, чью страницу для ввода логина и пароля мы видим в браузере. Точка. Можно с этим спорить, но это факт. На этой идее основаны современные мобильные sdk, так работает keycloak, и не просто так мэйнтейнеры того же keycloak нас предупреждают:
Безопасная аутентификация всегда предполагает выполнение правильных действий на защищенном сервере, известном как Keycloak, с использованием браузера пользователя. Пожалуйста, сделайте себе и своим пользователям одолжение: прочитайте и поймите спецификации, прежде чем внедрять «что-то, что каким-то образом» работает.
Еще раз цитата из rfc:
Даже если клиент безопасен, это приводит к увеличению поверхности атаки (учетные данные могут просачиваться не только на сервер авторизации), а пользователей обучают вводить свои учетные данные не только на сервере авторизации.
Эта идея - суть есть краеугольный камень всего oauth 2.0 (и не только). Ее можно критиковать (в некоторых аспектах вполне обоснованно), но реальность такова, что конкурентоспособной альтернативы предложено не было. И, к сожалению, эта идея почему-то вызывает у людей отторжение, видимо годами привыкшие вводить свои данные в нативные компоненты приложения, пользователи начали считать это нормой.
Это неверное утверждение. First patry application - это приложение, созданное разработчиком самой платформы, например, предустановленные приложения для ios, разработчик которых apple. Для таких приложение есть особая авторизация, которая пока еще в драфте. В таких приложениях риски всегда ниже, поэтому стандартные процессы Oauth 2.0 во многом бессмысленны. Что сбер, что вк разработали не google и не apple, и они уж точно не предустановлены ни в одну из ОС.
В статье речь шла не про вход по кредам гугла в приложениях сбера или тинька, а про то, что вход в них должен осуществляться через отдельное браузерное окно как и предполагает Oauth 2.0.
Даже если это и правда, то так делать, как Сбер, категорически неверно. В rfc вполне четко прописан процесс авторизации для мобильных приложений, а если компания так, как написано в стандарте делать не хочет, то она не только подвергает своих пользователей лишней опасности, но и учит их доверять учетные данные своему приложению, а не серверу авторизации (тому же СберID или "Сбер Онлайн", неважно), что в общем-то прямо и сказано в спецификации. Отсюда и результат. Особенно интересно читать отзывы в app store от тысяч пользователей, которые установили себе эти приложения и чьи учетные данные угнали.
Увы, это факт. Поэтому при запросе авторизации приложение дает предупреждение о том, что будет использовано для авторизации, а в браузерном окне виден адрес сервера авторизации. Это не решит проблему в 10 из 10 случаев, но как минимум позволит уменьшить поверхность атаки для наиболее внимательных пользователей, особенно если они годами вводили логин и пароль именно таким способом.