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) Сервер авторизации аутентифицирует клиента и проверяет       разрешение на авторизацию, и если оно действительное, выдает токен доступа       и токен обновления.

(C) Клиент делает защищенный запрос ресурса ресурсу       сервера, представив токен доступа.

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

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

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

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

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