@kirill-93

Зачем существует «дырявая» клиентская oAuth авторизация?

У большинства соц сетей и сервисов есть функция oAuth авторизации. Это такая авторизация, при которой пользователь вашего сайта авторизуется не через ваш сайт, а через свою учетную запись в какой-то социальной сети или в каком-то сервисе.
Чаще всего сервисы предлагают 2 варианта авторизации: серверный и клиентский.
Серверный работает так:
1. Пользователь перенаправляется на сайт соц сети и подтверждает, что хочет авторизоваться на вашем сайте.
2. Его перебрасывает на ваш сайт и в строке адреса передается специальный код.
3. Ваш сайт отправляет этот код вместе с секретным ключом в соц сеть и получает токен, который уже можно использовать для доступа к данным пользователя и тп.

Клиентский работает по-другому:
1. Пользователь перенаправляется на сайт соц сети и подтверждает, что хочет авторизоваться на вашем сайте.
2. Его перебрасывает на ваш сайт и в строке адреса передается готовый токен.

Зачем вообще существует второй вариант? Ведь любой узел (сисадмин, владелец точки wi-fi, провайдер, товарищ майор) может просто взять готовый токен и использовать его.
В сервисах, правда, обычно указывают, что такой способ небезопасен, но он нужен, например, для сайтов, у которых нет серверной части. Это правда, но почему для таких случаев не сделать, например так:
1. Подключаем js-библиотеку соц сети, которая открывает нашем сайте диалоговое окно.
2. Пользователь должен уже быть авторизован в соц сети в соседней вкладке (если проводить авторизацию через это диалоговое окно, то мы как владельцы сайта, можем подделать это окно и перехватывать данные пользователя).
3. Пользователь в диалоговом окне одобряет авторизацию и получает токен. Все это происходит через аякс поверх https и не может быть перехвачено.

Возможно мой вариант не работает, это то что пришло в голову по ходу написания вопроса. Но должен же быть какой-нибудь безопасный способ?
  • Вопрос задан
  • 164 просмотра
Решения вопроса 1
>>Зачем вообще существует второй вариант? Ведь любой узел (сисадмин, владелец точки wi-fi, провайдер, товарищ майор) может просто взять готовый токен и использовать его.

Данные передаётся по HTTPS! Следовательно токен не доступен промежуточным узлам, так как информация зашифрована.
Если рассматривать авторизацию через ВКонтакте токен известен толкьо: 1) ВКонтакте, 2) Сайту на который производится авторизация, 3) самому пользователю осуществляющему авторизацию
Все промежуточные провайдеры знают только что клиент по факту соединяется с некоторым IP адресом при использовании HTTPS протокола, и они не знают на какой url осуществляется запрос.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
SagePtr
@SagePtr
Еда - это святое
то мы как владельцы сайта, можем подделать это окно и перехватывать данные пользователя
В случае с серверной авторизацией - мы как владельцы сайта тоже получаем этот токен и можем как угодно использовать его пользователю во вред.
При авторизации нашего приложения в соцсети пользователю выдаётся список информации, к которому наше приложение будет иметь доступ, и пользователь должен быть готов к тому, что нечистые на руку владельцы сайта могут эти данные тайно собирать и использовать в плохих целях.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы