Разница между "потоком пароля владельца ресурса" и "Потоком учетных данных клиента"

Разница между "Потоком пароля владельца ресурса" и "Потоком учетных данных клиента" кажется мне непонятной. Первый, как представляется, перенаправляет учетные данные пароля на сервер для проверки, в то время как последний также выполняет аутентификацию с сервером, но спецификация не указывает, какой метод используется здесь. Этот поток предназначен для сеансов cookie? Спецификация действительно не дает ясного варианта использования.

Из спецификации OAuth 2.0:

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

                 Figure 6: Client Credentials Flow

и

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

        Figure 5: Resource Owner Password Credentials Flow
+26
источник поделиться
4 ответа

Для потока учетных данных клиента требуются только client_id и client_secret. Для потока Владелец ресурса требуется пароль пользователя.

Поток клиентских учетных данных позволяет приложению получать токен из контекста пользователя.

+22
источник

Хорошим примером этого может быть следующее:

Предположим, что вы являетесь статистической компанией под названием AllStats, у которой есть собственная пользовательская база, где каждый пользователь имеет свое имя пользователя и пароль. У AllStats есть свой собственный существующий веб-сайт, который поддерживает собственный API. Однако AllStats теперь хочет выпустить мобильное приложение.

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

Мне нравится просматривать поток паролей владельца ресурса как поток, который будут использовать разработчики 1-го стороннего приложения, тогда как Client Credentials Поток потока, который будут использовать сторонние разработчики приложений.

Представьте, что если в приложении Facebook вам понадобилось использовать Client Credentials Flow вместо того, чтобы просто предоставить вам форму с именем пользователя/паролем. Казалось бы, немного странно, да?

Теперь, если вы представляете, вы загружаете стороннее приложение с интеграцией Facebook. Я бы предположил, что вы (и большинство людей) будет очень назойливым, если приложение предложит вам имя пользователя/пароль вместо использования пользовательского интерфейса Client Credential Flow.

FWIW, это не означает, что приложения 1-й стороны не используют Client Credential Flow. Но вместо того, чтобы попытаться нарисовать сценарий реального мира (и общее обобщение), когда будет использоваться поток пароля владельца ресурса.

+14
источник
другие ответы

Похожие вопросы

Кроме ответа user3287829. Я хочу добавить следующее.

Как RFC говорится о предоставлении мандата Client Credential.

Клиент делает запрос к конечной точке маркера, добавляя следующие параметры с использованием "application/x-www-form-urlencoded"
формат в приложении B с кодировкой символов UTF-8 в HTTP-формате request entity-body:

grant_type          ОБЯЗАТЕЛЬНЫЙ. Значение ДОЛЖНО быть установлено на "client_credentials".

Объем          НЕОБЯЗАТЕЛЬНЫЙ. Объем запроса доступа, как описано в          Раздел 3.3.

Клиент ДОЛЖЕН пройти аутентификацию с сервера авторизации как описанных в разделе 3.2.1.

Например, клиент делает следующий HTTP-запрос, используя безопасность транспортного уровня (с дополнительными разрывами строк для целей показа только):

 POST /token HTTP/1.1
 Host: server.example.com
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
 Content-Type: application/x-www-form-urlencoded

 grant_type=client_credentials

Сервер авторизации ДОЛЖЕН аутентифицировать клиента.

Клиент должен быть зарегистрирован на сервере авторизации заранее. и Authorization включает учетные данные клиента, которые будут аутентифицированы сервером.

+2
источник

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

0
источник

Посмотрите другие вопросы по метке или Задайте вопрос