Я думаю, что ключ в вашем вопросе - это то, где вы пишете: «При этом вам не нужно будет впоследствии входить в систему, если вы используете навигацию верхнего уровня для другого продукта».
Я объясню:
Вы хотите иметь возможность перейти с site1.com на site2.com и сообщить site2.com, что вы являетесь пользователем, который вошел на сайт site1.com.
, поскольку файлы cookie не могут совместно использоваться разными доменами (кроме поддоменов, но я полагаю, что вы не говорите о поддоменах), вам нужно передать некоторую информацию по ссылке на site2.com, которая позволит ему общаться с его бэкэндом и знать, какой вы пользователь.
давайте начнем с наивного решения, а затем поработаем над решением некоторых проблем, которые оно ставит:
Предположим, у вас есть таблица пользователей в некоторой внутренней базе данных, а у вашего пользователя есть некоторый идентификатор.
Теперь предположим, что пользователь прошел аутентификацию на сайте site1.com, и он является пользователем 123 из вашей БД.
Наиболее наивным решением было бы позвонить на site2.com/url/whwhat?myRealID=123
и пусть site2 проверит этот идентификатор и "поверит" пользователю, что это действительно он.
Проблема: любой (даже действительный пользователь вашего сайта), увидевший вашу ссылку, может создать ссылку с myRealID = 123 или попробовать другие значения для нее. и site2.com примет его как этого пользователя.
Решение: позволяет не использовать предположительные идентификаторы. Предположим, что вы добавляете в свою таблицу пользователей уникальный GUID, а если у пользователя 123 есть guid 8dc70780-15e5-11e0-ac64-0800200c9a66, то позвоните на site2.com/url/whwhat?myGuid=8dc70780 -15e5-11e0-ac64-0800200c9a66.
Новая проблема: хорошо, хотя было бы очень маловероятно, что кто-то будет угадывать GUID вашего пользователя, его GUID все еще может быть взломан каким-то посредником, который видит эту ссылку, и если кто-то получит гид, он может использовать его навсегда.
Решение: используйте личный ключ, сохраненный на вашем сервере, чтобы подписать строку, содержащую следующие элементы данных, текущую метку времени, сайт назначения (то есть "site2.com"), указанный GUID, эту подпись можно перевести в высказывание «Это доказательство того, что эта ссылка была создана сайтом в указанное время для пользователя, который имеет этот GUID для аутентификации на этом домене» и отправляет его на site2.com вместе с отметкой времени и GUID. Теперь, когда site2.com получает ссылку, он может удостовериться, что она подписана правильно, и если какой-то посредник или изначально пользователь попытается изменить ее каким-либо образом (моё изменение времени или GUID), тогда подпись не будет соответствовать и site2. com откажется аутентифицировать пользователя.
Еще одна проблема: если соединение перехвачено посредником, он все еще может использовать его с другой машины.
Решение: добавить одноразовый номер к переданным параметрам. Одноразовый номер - это просто случайное число, которое ваша система аутентификации должна удостовериться, что оно не позволяет вам проходить аутентификацию с этим номером более одного раза (отсюда и имя N (umber) -ONCE). Обратите внимание, что это означает, что каждая ссылка, которую вы создаете на site1.com и которая ведет на site2.com, должна иметь отдельный одноразовый номер, который необходимо сохранить на сервере для последующей проверки.
, поскольку вы не хотите продолжать добавлять записи в эту таблицу nonce навсегда, обычно принято решение, что такая ссылка действительна только в течение определенного времени после ее создания. и, таким образом, вы можете создавать одноразовые записи, которые старше этого срока.
Я надеюсь, что это схема, которую вы ищете.
Вполне возможно, что я что-то пропустил, но это основные рекомендации, используйте подпись для подтверждения подлинности данных в ссылке и одноразовый номер для предотвращения атак посредников. Я также рекомендовал бы использовать HTTPS для этих ссылок, если это возможно.
Эяль