Междоменный вход - как автоматически входить в систему при переходе с одного домена на другой

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

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

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

Это хорошее решение. Вот два момента, которые следует учитывать:

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

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

Единая точка входа (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 шифрования логина с использованием общего секретного ключа.
• domain1.com берет зашифрованный токен, расшифровывает его, использует новый идентификатор входа в систему для входа пользователя.
• domain1 устанавливает cookie сеанса для пользователя.

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

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

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

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

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

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

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