Поддерживают ли какие-либо гранты OAuth предоставление доступа от имени пользователя, не требуя взаимодействия с пользователем?

Question

У нас есть несколько веб-служб и сервер OAuth2, который защищает доступ к ним.

Я хочу, чтобы наши внешние клиенты могли использовать эти веб-службы в своих мобильных приложениях.Но в некоторых случаях они хотят поддерживать свою собственную базу данных логина / пароля и не требуют, чтобы пользователь проходил аутентификацию отдельно от наших веб-сервисов.В этом случае у клиента есть идентификаторы для пользователей на нашей стороне, которые соответствуют их собственным пользователям (мы синхронизируем их вне процесса OAuth).

Итак, предполагая, что пользователи уже установили сеанс на стороне клиентаЯ хочу иметь возможность предоставить им какой-то токен доступа, который предоставит им доступ к соответствующему пользователю на нашей стороне, не запрашивая у них отдельный пароль.Как я могу это сделать?

Один из подходов состоит в том, чтобы потребовать от клиентов настроить прокси для наших веб-служб, защищенных их собственным сеансом.Их мобильные приложения будут отправлять запросы на прокси-сервер вместо наших веб-сервисов напрямую.Их сервер мог бы использовать client-credentials grant , чтобы получить токен доступа и добавить его к любым входящим запросам перед передачей их на наш сервер.

Есть ли лучший способ?Это кажется довольно сложным для реализации клиентами, и вам нужно как-то проверить, что входящие запросы не пытаются получить доступ к данным для другого пользователя.

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

Answer 1

Доступ к ресурсам пользователя без авторизации или авторизации пользователя запрещен (не имеет значения, равен ли он 1.0a или 2.0).Следовательно, нет grant_type для прямой поддержки.

Кроме того, предложение прокси может быть не очень хорошей идеей по двум причинам.

1. Безопасность: этот прокси откроет зияющую дыру в ваших системах, что, зная электронную почту пользователя, атака сможет получить все данные из вашей системы.
2. Maintanebility: Как вы будете отслеживать авторизацию, чтобы токен учетных данных клиента имел доступ к определенной электронной почте через систему?Это может создать ненужные контрольные точки в ваших приложениях.

Теперь предлагаем предлагаемое решение, которое может работать без изменения большей части вашего приложения

Обратите внимание, что это будет хорошоИдея включить двухстороннюю взаимную аутентификацию или некоторую дополнительную безопасность для проверки.

Дайте мне знать, если это не решит проблему.