Подтвердить что ты не робот

Разница между объемом и полномочиями в UAA

В UAA Существуют две концепции, полномочия и область действия.

Эти концепции, похоже, перекрываются. Я хотел бы знать точную разницу и цель

Например, oauth.login

4b9b3361

Ответ 1

Области действия - это разрешения клиента OAuth, действующего от имени пользователя. Они предоставляются после получения токена пользователя с одним из следующих типов предоставления: auth_code, password, implicit. Области действия показывают, к чему приложению разрешен доступ от имени пользователя (так называемая делегированная авторизация).

Полномочия - это разрешения клиента OAuth, действующего от своего имени, и участие пользователя отсутствует. Они предоставляются после получения клиентского токена с grant_type of client_credentials. Типичное использование - это приложение или API, пытающиеся получить доступ к ресурсу со своими учетными данными без участия пользователя.

В UAA oauth.login является разрешением системного уровня и использовался устаревшей реализацией проекта login-server (когда UAA и Login Server были отдельными компонентами). Это разрешение разрешает доступ на уровне администратора для сервера входа.

Ответ 2

1) полномочия и роли - это пружинная формулировка для разрешений. Это не определено в спецификации OAuth2.

2) роли определены OAuth2. Он предназначен для переноса между сервером авторизации и сервером ресурсов того, что конечный пользователь разрешил клиенту делать от его имени.

Как следствие, полномочия, предоставляемые клиенту, всегда должны быть подмножеством полномочий конечного пользователя: все возможные области действия => все полномочия пользователя; чем меньше возможностей, тем меньше авторитетов.

Одна хитрость в некоторых потоках OAuth2 заключается в том, что клиент является конечным пользователем (он не аутентифицируется от имени кого-либо, а от своего имени).

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

Последняя требует написания и настройки вашего собственного конвертера полномочий, который уже возможен для JWT, но еще не для самоанализа (должен прийти, для этого открыт билет)

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