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 случаев, но как минимум позволит уменьшить поверхность атаки для наиболее внимательных пользователей, особенно если они годами вводили логин и пароль именно таким способом.
В то же время там написано вот что:
То есть в спецификации подразумевается, что между клиентов (приложением) и сервером авторизации есть некоторая степень доверия, а уже как она была достигнута, в спецификации не уточняется. Сказано лишь, что "есть какие-то способы это сделать в современных мобильных приложениях". Мы уже видели эти способы, как оно работает на самом деле и можно ли доверять на 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 случаев, но как минимум позволит уменьшить поверхность атаки для наиболее внимательных пользователей, особенно если они годами вводили логин и пароль именно таким способом.