OAuth 2: разделение сервера ресурсов и сервера авторизации

Спецификация OAuth 2 позволяет мне полагать, что "сервер ресурсов" и "сервер авторизации" необязательно должны быть одним и тем же приложением, но я изо всех сил пытаюсь понять, как это фактически реализуется на практике.

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

сервер ресурсов
сервер авторизации
веб-интерфейс
стороннее клиентское приложение

Сценарий # 1: вход в веб-интерфейс

Пользователь отправляет регистрационную форму
Учетные данные веб-приложений POST для сервера auth (grant_type = password) и получает access_token
веб-приложение сохраняет access_token в сеансе
при каждом последующем запросе:
- Ресурсы GET с сервера ресурсов (w/access_token в заголовке авторизации) и визуализировать его в веб-интерфейсе
- если мы получим 401, то запишите пользователя (удалите access_token из сеанса)

Сценарий №2: авторизация стороннего приложения

пользователь запрашивает авторизацию с помощью службы auth Отображается форма
allow/deny
пользователь перенаправляется обратно в клиентское приложение с кодом авторизации
Клиентский адрес POST-кода для службы auth (grant_type = authorization_code) и получает access_token
клиент получает ресурсы от передачи сервера ресурсов (w/заголовок Auth)

В части, с которой я столкнулся с трудностями, заключается в том, как аутентифицировать пользователя, прежде чем показывать форму allow/deny в сценарии # 2. Пользователь может войти в основное веб-приложение, но служба auth не имеет ни малейшего представления об этом, и как-то нужно будет снова аутентифицировать пользователя. Должна ли служба auth поддерживать логин/сеансы?

Мне интересно, может ли это иметь смысл для веб-приложения отвечать за показ формы allow/deny по двум причинам:

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

Здесь одна из возможных альтернатив сценарию № 2:

пользователь запрашивает авторизацию из веб-приложения Отображается форма
allow/deny
POST для веб-приложений для сервера auth, создающего новый грант, возвращается код авторизации
веб-приложение перенаправляет клиентское приложение с кодом авторизации
клиентский POST-код приложения для службы auth и получает access_token

Какой лучший способ справиться с этим? Любые общие комментарии, советы и т.д. Были бы замечательными!

Спасибо

Ответ 1

Ваш альтернативный сценарий - это, вероятно, то, с чем вы хотите пойти: если вы действительно хотите отделить свои потоки, вы можете попробовать что-то вроде этого:

пользователь запрашивает авторизацию от службы auth от имени службы с помощью grant_type = code
Служба auth реализует, что пользователь не вошел в систему: перенаправляет на веб-приложение с параметром запроса, запрашивая веб-сервер для отправки пользователя.
веб-приложение сохраняет параметр запроса, затем запрашивает имя пользователя/пароль
Учетные данные веб-приложений POST для сервера auth (grant_type = пароль) и получает access_token.
веб-приложение сохраняет access_token в сеансе
веб-приложение генерирует подписанный токен, захватывающий идентификатор пользователя, и перенаправляет обратно на службу auth с подписанным токеном в качестве параметра запроса
служба auth анализирует подписанный токен, извлекает идентификатор пользователя, отображает форму разрешения/отказа
пользователь перенаправляется обратно в клиентское приложение с кодом авторизации
Клиентский адрес POST-кода для службы auth (grant_type = authorization_code) и получает access_token
клиент получает ресурсы от передачи сервера ресурсов (w/заголовок Auth)

Ответ 2

Документация OAauth2: https://tools.ietf.org/html/rfc6749

(A) Клиент запрашивает токен доступа путем аутентификации с помощью сервера авторизации и предоставления разрешения.

(B) Сервер авторизации аутентифицирует клиента и проверяет разрешение на авторизацию, и если оно действительное, выдает токен доступа и токен обновления.

(D) Сервер ресурсов проверяет токен доступа, и если он действителен, служит для запроса.

(E) Шаги (C) и (D) повторяются до истечения срока действия маркера доступа. Если клиент знает, что токен доступа истек, он переходит к шагу (G); в противном случае он выполняет другой защищенный запрос ресурса.

(F) Поскольку токен доступа недействителен, сервер ресурсов возвращается неверная ошибка токена.

(G) Клиент запрашивает новый токен доступа, аутентифицируя сервера авторизации и представления токена обновления. требования проверки подлинности клиента основаны на типе клиента и в политике сервера авторизации.

(H) Сервер авторизации аутентифицирует клиента и проверяет токен обновления, и если он действителен, выдает новый токен доступа (и, необязательно, новый токен обновления).