@kirill-93

Безопасна ли такая авторизация?

Здравствуйте. Есть большой проект, который имеет несколько дочерних и мобильные приложения.
Дочерние сайты - это SPA на vue.js, каждое из которых имеет свое мобильное приложение на cordova. Для удобства, код каждого сайта и код приложения для этого сайта один и тот же. По факту мобильное приложение - это просто мобильная версия сайта, которая завернута в cordova и умеет обращаться к АПИ телефона.
Появилась необходимость единой авторизации через сторонние сервисы, который более 10. В некоторых из этих сервисов предусмотрены разные домены для авторизации (например через фейсбук), в других можно использовать только один домен. Кроме того в мобильных приложениях нет домена.
Структура доментов примерно такая:
base.domain.com - главный и основной домен, на котором находится админка и на который настроен редирект с соц сетей при авторизации.
domain1.com, domain2.com, domain3.com - сайты SPA, которые тянут данные аяксом с base.domain.com (плюс три мобильных приложения)
Чтобы все это унифицировать, я решил делать авторизацию следующим образом:
На примере facebook. С любого из дочерних сайтов человека отправляет на facebook(или любой другой сторонний сервис для авторизации) в окно авторизации, а после авторизации перекидывает на base.domain.com. Там я получаю все данные, авторизую человека, записываю в БД какой-то хэш и делаю редирект на base.domain.com?token=xxxxxx, где token - это хэш, который я сохраняю на дочернем сайте с локалстораж и по нему обращаюсь с запросами, как авторизованный пользователь.
Таким образом, мне удалось использовать одну схему авторизации для всех шести приложений, не заводя разные аккаунты в социальных сетях и не используя разные способы авторизации.
Какие минусы у моего способа?
Сам я вижу только то, что токен передается в открытом виде, решения вижу два:
1) Передавать его в теле, то есть делать редирект, например на base.domain.com/success, а на экран уже выводить сам хэш. (я так пробовал, были какие-то трудности с получением содержимого страницы в мобильном приложении).
2) После получения хэша дочерним сайтом или приложением его нужно "активировать", отправив пост запрос на сервер, после чего этот хэш станет недействительным, а приложение получит уже настроящий хэш для авторизации.
Извините, что получилось длинно, хотел все подробно расписать. Спасибо!
  • Вопрос задан
  • 235 просмотров
Пригласить эксперта
Ответы на вопрос 1
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
... и делаю редирект на base.domain.com?token=xxxxxx, где token - это хэш, который я сохраняю на дочернем сайте с локалстораж и по нему обращаюсь с запросами, как авторизованный пользователь.
Вот тут-то и поймали токен (хэш) авторизованного пользователя.
Зачем передавать хэш в URI, если он уже лежит у клиента (в localstorage или в приложении)?
Подписываете запрос к любому вашему сервису токеном клиента (т.е. авторизованным пользователем). (сам токен - никогда не передаёте по сети).
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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