OAuth2: предотвращение злоупотребления токенами доступа законным сервером ресурсов

Question

Рассматривая мультисервисную настройку, где один сервер авторизации (AS) управляет доступом к серверу с несколькими ресурсами (RS) и RS2 в этом примере.

Если у нас есть один токен доступа для обеих RS, и мы отправляем токен доступа на RS1, то RS1 сможет совершать вызовы с этим токеном доступа на RS2. Это угроза безопасности, которую я хотел бы избежать, особенно в среде, где не каждый сервер ресурсов заслуживает доверия.

В rfc6819 упоминается эта угроза и решение:

Серверы авторизации в мультисервисных средах могут учитывать выдача токенов с разным контентом на разные серверы ресурсов и явно указать в токене целевой сервер, на который токен предназначен для отправки.

Однако я новичок в OAuth2 и пытаюсь понять, КАК это реализовать. Я понимаю, что в OAuth2 есть концепция scope и audience, но я не вижу, как разные потоки авторизации выдают разные токены доступа для разных серверов ресурсов.

Ради простоты мы принимаем грант для владельца ресурса.

Клиент выполняет вход в систему для получения токена обновления и токена доступа

GET /token
 ?grant_type=password
 &username=user
 &password=pass
 &scope=rs1 rs2

Ответ AS:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}

Параметр access_token ТРЕБУЕТСЯ, как указано в RFC. Но какой токен доступа должен быть? Один для RS1 или один для RS2? Как получить другие необходимые токены доступа? Нужно ли использовать токен обновления?

Возможно, RFC не рассматривает этот вариант использования. Существуют ли лучшие или распространенные методы предотвращения утечки токена доступа с одного RS на другой?

Answer 1

С точки зрения специфики OAU вы должны использовать scope для определения целевой аудитории токенов доступа. Это определяется следующим образом ( ссылка ),

Конечные точки авторизации и токена позволяют клиенту указывать область запроса на доступ с использованием параметра запроса "scope". В В свою очередь, сервер авторизации использует параметр ответа "scope" для сообщить клиенту объем выданного токена доступа.

Когда вы определяете это в своем запросе авторизации (или в запросе токена в зависимости от используемого потока). После этого сервер авторизации должен выдать токен доступа с запрошенной областью действия.

Теперь, когда вы проверяете токен доступа с сервера ресурсов (или клиента в зависимости от сценария), вы должны проверить значение области. Для этого у вас есть два варианта.

Сначала используется конечная точка token introspection, определяемая rfc7662 . В конечной точке самоанализа вы можете получить значения области действия токена доступа.

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

Наконец, вы заявляете,

Если у нас есть один токен доступа для обеих RS, и мы отправляем токен доступа на RS1, то RS1 сможет совершать вызовы с этим токеном доступа к RS2

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