Междоменный логин - что хранить в базе данных?

Question

Я работаю в системе, которая позволит мне войти в одну и ту же систему через разные домены. (www.example.com, www.mydomain.com, sub.domain.com и т. д.)

Следующие темы составляют основу моего исследования до сих пор:
Единая регистрация на нескольких доменах
Межсайтовый вход в домен с членством .net

Что я хочу сделать, так это то, что если я вошел в систему в главном домене и 1012 * и зашел на страницу в подчиненном домене 1014 *, чтобы автоматически войти в систему на подчиненном устройстве.

Очевидно, что если я не вошел в систему на главном сервере, мне нужно будет ввести свое имя пользователя и пароль.

Пошаговое руководство:
1. Пользователь заходит на главный сайт
2. Пользователь переходит на подчиненный сайт
3. Ведомый сайт перенаправляет на главный сайт, чтобы проверить, вошел ли пользователь в систему.
4. Если пользователь вошел в систему на главном сервере, запишите идентификатор токена RFC 4122 и отправьте его на подчиненный сайт.
5. Затем подчиненный сайт ищет идентификатор токена в центральной базе данных и регистрирует этого пользователя.

Это может в конечном итоге работать более чем один раз на PHP и Apache, поэтому я не могу просто сохранить:

token_id, php_session_id, created

Есть ли у меня проблемы с хранением и использованием этого:

token_id, username, hashed_password, created

Который удаляется при использовании или автоматически через x секунд.

Answer 1

Основная идея в ссылке, на которую вы ссылаетесь, в порядке, но она также говорит об управлении сеансами - забудьте о том, что хранить в базе данных - все, что вам нужно сделать, это включить сеансы на главном сервере и клиенте. И сохраните аутентифицированное имя пользователя в сеансе (главным образом, чтобы вы могли видеть, был ли пользователь имеет аутентификацию).

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

Нет - вы перенаправляете только с подчиненного сайта (называя его клиентом становится запутанным), если подчиненный сайт определяет, что пользователь не был аутентифицирован.

Забудьте о RFC 4122 - это просто умный способ получить uuids, которые используются в посте, который вы называете идентификаторами сеанса. PHP уже генерирует совершенно хорошие значения.

Вам необходимо передать какое-то сообщение обратно от главного к подчиненному, которое предоставляет идентификатор пользователя и тот факт, что пользователь прошел аутентификацию в URL-адресе (вы не можете передавать куки-файлы по доменам и не можете делать ПОСТ в редирект). Один из очевидных способов сделать это - поделиться секретом как с ведущим, так и с ведомым, а затем ...

$redirect_to='http://slave.example.com/sso_lander.php?auth_token=' 
       . encrypt($some_random_alphanum_chars 
         . '/' . $user . '/' 
         . time(), $shared_secret);
header("Location: $redirect_to", true, 303);

Тогда на рабе:

if (!($_SESSION['authenticated_user']) && $_GET['auth_token']) {
    $auth_token=explode('/',decrypt($_GET['auth_token'], $shared_secret));
    if ((abs($auth_token[2]-time())<3) {
          // if more than 3 seconds after generate - DO NOT USE
          $_SESSION['authenticated_user']=$auth_token[1];
    }
}

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

С