Единый вход на основе OAuth2

Question

Я разрабатываю систему единого входа на основе OAuth2.

У меня есть 3 службы:

1. Поставщик удостоверений SSO, который содержит пользователей и сервер OAuth2 - http://sso.idp.loc

2. поставщик услуг единого входа с интерфейсной частью на Angular - http://sso.sp -angular.loc

3. поставщик услуг единого входа (случайный веб-сайт) - http://sso.sp -web.loc

Поставщики услуг проверяют каждый токен доступа запроса, выданный поставщиком удостоверений.

Механизм следующий:

1. Перейдите к любому поставщику услуг и нажмите логин
2. Перенаправить на sso.idp.loc / login_check, чтобы проверить учетные данные (из файлов cookie).
3. Если не авторизован - перейдите на sso.idp.loc / login.
4. После входа в систему - установите куки для провайдера идентификации и перенаправьте его на целевой провайдер с этими куки в параметре get.
5. Установка новых файлов cookie из параметра get для поставщика услуг и перенаправление на целевой путь.
6. Если вдруг произошла ошибка аутентификации на поставщике услуг - перейдите в sso.idp.loc / login_check с целевым путем.

Cookies содержат oauth-доступ и токены.

Все в порядке, пока токен действителен.По истечении срока действия токена службы prodider переходит на sso.idp.loc / login_check и снова проверяет токен доступа, а затем пытается один раз получить новый, используя токен обновления.В случае успеха новые учетные данные устанавливаются как sso.idp.loc и поставщик услуг.Допустим, это произошло на sso.sp-web.loc.

Здесь у меня есть несколько проблем:

1. Тогда другой поставщик услуг sso.sp-angular.loc не знает, что учетные данныебудут изменены, и следующий запрос будет перенаправлен на sso.idp.loc / login_check (его можно отсортировать, отправив запрос второй раз).
2. Когда пользователь редактирует форму на sso.sp-web.loc и токен имеетсрок действия истекает, тогда отправка завершится неудачей.
3. Как управлять вызовами ajax после истечения срока действия токена?

Следует учитывать тот факт, что токен доступа может быть изменен в любое время.

Возможно, что-то не так в моей системе.Буду рад здесь любым решениям.

Answer 1

Я думаю, что ваша концепция единого входа неверна - вам не следует использовать одни и те же токены.Токены должны быть разными для каждого клиента (приложения).OAuth2 SSO обычно реализуется следующим образом (реализация не описана в RFC OAuth2):

1. Приложение «App1» запрашивает токен, перенаправляя браузер пользователя на сервер авторизации (/authконечная точка).
2. Сервер авторизации устанавливает cookie-файл сеанса в браузер и сохраняет информацию о том, какой пользователь был аутентифицирован в этом сеансе.Файл cookie действителен только для запросов сервера авторизации.
3. Когда другое приложение «App2» запрашивает токен, браузер отправляет файл cookie сеанса вместе с запросом конечной точки /auth.Сервер авторизации разрешает сеанс.Сеанс уже был аутентифицирован, поэтому сервер авторизации может решить не запрашивать учетные данные и сразу же выпустить новые токены (или код авторизации).

Answer 2

Похоже, вы реализовали тип неявного предоставления OAuth 2.0.Это довольно небезопасно.В идеале вы должны реализовать тип предоставления кода авторизации и хранить свои клиентские секреты на стороне сервера ресурсов (которого вы называете поставщиком услуг).Я рекомендую вам прочитать ответы здесь и здесь .

Теперь давайте ответим на вопросы:

1. Если вы установитеАтрибут домена вашего cookie правильно, cookie, установленный первым сервером ресурсов, также должен быть доступен для второго сервера.

2. Когда пользователь редактирует форму и срок действия токена истекает, фильтр API на сервере ресурсов может обнаружить токен с истекшим сроком действия и вернуть клиенту код ответа 401.Получив 401, клиент или браузер могут сделать еще один вызов API на сервере, чтобы обновить токен доступа.API извлекает токен обновления из cookie и вызывает сервер авторизации с секретом клиента и токеном обновления, чтобы получить новый токен доступа.Если время обновления не истекло, сервер авторизации вернет новую пару маркеров доступа и обновления, которые будут возвращены браузеру и установленным файлам cookie.Теперь браузер снова вызовет форму отправки api с новым токеном доступа.Все это будет происходить без проблем с пользователем.Полный сбой произойдет, только если срок действия маркера обновления истек.

3. Аналогично тому, как указано в 2.