Способ реализации Single Sign-On (сквозная авторизация). Корректен ли такой способ?

282

14 июня 2017, 03:18

Есть сайт service.com, выступающий в качестве точки авторизации для mydomain.com (оба работают на одном движке, работающем по принципу единой точки входа).

Прошу совета у опытных разработчиков, насколько корректен следующий подход к проверке авторизации пользователя:

При первичном заходе на сайт mydomain.com происходит проверка куки с флагом авторизации на сайте mydomain.com. Если куки нет, идет перенаправление на service.com, где проверяется, устанавливалась ли кука авторизации для данного пользователя на service.com.
Если кука устанавливалась, осуществляется редирект header('Location: http://' . mydomain.com?token="12345"), где token - случайный код, по которому запрашивается sessionId для этого пользователя из БД.
Если мы имеем передаваемый Get-запросом токен, то после редиректа на mydomain.com запрашиваем sessionId из БД, запускаем сессию session_start(sessionId), а затем делаем еще одну перезагрузку уже без токена header('Location: http://' . mydomain.com) . Причина - безопасность, необходимо убрать из адресной строки токен.
Если кука не устанавливалась, мы имеем гостевой вход обычного посетителя сайта, для которого token, связывающий его с sessionId из БД, передавать не нужно. В таком случае нужно установить гостевую куку, чтобы больше его не отправлять в точку авторизации на проверку. Мы посетителя отправляем обратно на сайт, например, таким образом header('Location: http://' . mydomain.com?status="visitor").

При такой реализации single sign-on каждого посетителя сайта будут один раз отправлять в точку авторизации. Насколько это разумное решение, на ваш взгляд?

UPD.

Сайтов/доменных имен, привязанных к service.com может быть множество, например, otherdomain.com. Цель сквозной авторизации - необходимость предоставить пользователю, авторизованному в точке авторизации service.com и являющемуся владельцем сайта mydomain.com персональные элементы управления (например, ссылка на свой сайт вида "Мой сайт") в тот момент, когда он будет находиться на чужом для него сайте otherdomain.com. Как, например, в ЖЖ владельцы блогов имеют ссылку на свой блог, находясь на любом блоге.

Все сайты физически расположены на одном сервере.

Answer 1

session_id(sessionId) - уже неправильно. Не делайте так. Вот почему:

По умолчанию файлы сессий хранятся на диске на одном сервере. С другого сервера вы увидите пустоту, а не сессию. (Что за нагруженная система на одном сервере?)
Файлы сессий вообще-то удаляются.
Файлы сессий могут принадлежать другим пользователям, а значит PHP не сможет их прочитать. Отладка при этом выводится ровным счётом никакая. Вы будете думать что сессия началась, а на самом деле - нет.
Наконец, если кто-то "угонит" этот ID сессии через XSS или ещё как, то он сможет всегда, пока существует ваш пользователь, представляться им.

Если первые три пункта ещё можно решить через хранение сессий в БД или ещё какими-то путями, то последний пункт можно обойти только если не делать так, как вы хотите.

Лучше будет начинать сессию как обычно с уникальным ID, записывая внутрь сессии ID пользователя или что вы хотите:

$_SESSION['ID'] = $idFromDatabase;

Дальше. Есть посетители, которых вы не можете отправить для получения сессионной куки. Например, поисковые боты. Следует либо не перекидывать посетителей с публичных страниц на сервер авторизации, либо делать это в фоновом режиме через JS.