Cross Domain Login - Как автоматически войти в систему при переходе с одного домена на другой

Question

Мы предлагаем ряд онлайн-услуг. Мы должны разработать систему, которая обеспечивает быструю / простую работу для пользователей, если они переводятся из одной службы (в domain1.com) в другую службу (в domain2.com).

Существует ли безопасный и надежный способ автоматического входа пользователя в систему после его перехода на новую услугу?

Кричи на меня, если приведенное ниже решение совершенно небезопасно / неверно.

Мы рассматривали систему, аналогичную той, которая предоставляется рядом онлайн-сервисов для восстановления пароля - им по электронной почте отправляется ссылка с уникальным хешем, срок действия которого истекает, что позволяет им менять свой пароль.

domain1.com сгенерирует уникальный хеш и сохранит его в базе данных с хешем, связанным с пользователем, вместе с полем даты истечения срока действия.

Пользователь будет переведен на domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com затем сделает запрос к domain1.com с хешем для получения информации о пользователе. domain1.com удалит хеш из базы данных. domain2.com будет входить в систему, устанавливать cookie и т. Д.

Может ли что-то на основе OpenID или OAuth достичь таких же результатов?

Answer 1

Единая регистрация (SSO) концептуально довольно проста.

• Пользователь нажимает domain1.com.
• domain1.com видит, что нет файла cookie сеанса.
• domain1.com перенаправляет на sso.com
• sso.com представляет страницу входа и принимает учетные данные
• sso.com устанавливает сессионный cookie для пользователя
• sso.com затем перенаправляет обратно на domain1 на специальный URL (например, domain1.com/ssologin)
• URL ssologin содержит параметр, который в основном "подписан" sso.com. Это может быть так же просто, как base64 для шифрования loginid с использованием общего секретного ключа.
• domain1.com принимает зашифрованный токен, расшифровывает его, использует новый идентификатор входа для входа в систему пользователя.
• domain1 устанавливает сессионный cookie для пользователя.

Теперь следующий случай.

• Пользователь нажимает domain2.com, который следует domain1 и перенаправляет на sso.com
• sso.com уже имеет cookie для пользователя, поэтому не отображает страницу входа
• sso.com перенаправляет обратно на domain2.com с зашифрованной информацией
• domain2.com входит в систему пользователя.

Это основы того, как это работает. Вы можете сделать его более надежным, более функциональным (например, это SSOn , но не SSOff , пользователь может "выйти" из domain1, но при этом войти в систему до domain2). Вы можете использовать открытые ключи для подписи учетных данных, у вас могут быть запросы на передачу дополнительной информации (например, права авторизации и т. Д.) С сервера единого входа. У вас может быть более тесная интеграция, например, домены, регулярно проверяющие, что у пользователя все еще есть права от сервера единого входа.

Но рукопожатие cookie через браузер с использованием перенаправлений - это ключевой фундамент, на котором основаны все эти решения SSO.

Answer 2

Если бы кто-то смог сыграть человека посередине и захватить этот хэш, они бы смогли украсть междоменную передачу? Очевидно, что он должен быть сгенерирован и отправлен клиенту до того, как ему понадобится его использовать. Так скажем, например:

Я играю человека в середине, шпионящего за Джеком. Джек обращается к domain1.com, что приводит к тому, что хеш-код должен быть подготовлен и отправлен ему, чтобы при получении доступа к domain2.com он мог отправить этот хэш в качестве аутентификации. Когда он обращается к domain1.com, его просьба приходит через меня, вы возвращаете страницу, я беру хэш и позволяю ему продолжать. Я получаю доступ к domain2.com с помощью хэша, теперь вы впустили меня в domain2.com и удалили хэш. Он не мудрее, пока не попытается войти на domain2.com и ему не сообщают, что его учетные данные больше не действительны.

Как вы преодолеете это?

Answer 3

Не было бы смысла использовать SSL для междоменного входа в систему, если вы не используете SSL для всего сеанса. Украсть сессионный cookie так же просто, как использовать хеш в URL. Какой смысл скрывать хеш в SSL, если остальная часть сеанса небезопасна.

Метод, приведенный вверху, в значительной степени является стандартным методом. Если вы решите использовать безопасные протоколы, это совсем другой вопрос, но бессмысленно шифровать только часть сеанса.

Answer 4

Это хорошее решение. Вот два момента для рассмотрения:

Вы используете термин "хеш", но не ясно, какие данные вы будете хэшировать. Вместо этого используйте «nonce»: большое (128-битное) число, генерируемое RNG криптографического качества.

Кроме того, вы не указали это, но связь между пользователем и обоими доменами, а также между самими доменами должна быть безопасной. Используйте SSL для аутентификации серверов и обеспечения конфиденциальности одноразового номера.

Answer 5

А как насчет SEO? Похоже, каждый запрос перед успешным входом в систему перенаправляется на другой домен и обратно. Я бы сказал, что это очень некрасиво. Какие заголовки вы должны отправить? 301 до SSO, а затем обратно 301 на исходную страницу? Таким образом, поискового бота "просят" дважды изменить свой индекс для этой страницы?