Интересная идея пришла в голову однажды, когда разговаривал с коллегой.

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

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

В общем, разработали общую концепцию авторизации, которая заключается в следующем:

1. есть одна общая база данных, в которой и хранится все нужная информация;
2. пользователь заходит на страницу приложения;
3. приложение проверяет существование сессии как у себя, так и в базе данных сервера авторизации;
4. если сессия есть, то все хорошо — получаем нужные права и начинаем работать;
5. если по каким-либо причинам сессии нет, то пробует ее создать;
6. приложение «редиректит» пользователя на страницу сервера авторизации;
7. если на сервере авторизации есть уже сессия для данного пользователя — то просто ее поднимаем и готово, если нет — то просим логин и пароль;
8. возвращаемся в приложение.

Все, пользователь авторизован. В следующий раз при запуске следующего приложения, происходит переброс пользователя на сервер авторизации. А там уже есть активная сессия, поэтому происходит возврат в рабочее приложение с информацией для поднятия сессии там.

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

Пока только есть первоначальные наработки класса. В нем приходится реализовывать весь необходимый функционал, чтобы класс не зависел ни от какого-либо фреймворка. Если будет необходимость, то выложу исходный код сюда.