OAuth2 Client Credential flow - Какова цель получения токена доступа?

Question

В потоке учетных данных клиента OAuth2 есть два шага для выполнения аутентифицированного запроса к API:

1. Используя идентификатор клиента и client secret , сделайте запрос к серверу аутентификации. Получить временный (т.е. 24-часовой) токен доступа.
2. Используя токен доступа , полученный с шага 1, отправьте запрос в API. API проверит на сервере аутентификации, что токен доступа действителен. Если это так, то примите запрос.

Что мне неясно, так это почему этот поток имеет больше смысла, чем просто передача идентификатора клиента и секрета в API, а затем проверка API с помощью сервера аутентификации, что идентификатор клиента и секрет клиента действительны?

В моем конкретном случае сервер аутентификации и API принадлежат одной и той же компании.

Answer 1

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

Но если учетные данные клиента передаются в API, ему необходимо будет каждый раз подключаться к серверу авторизации, чтобы проверить, что учетные данные клиента и области действия все еще действительны.

Кроме того, использование токенов на предъявителя вместо учетных данных в запросе, вероятно, является лучшим вызовом, поскольку, как только вы сможете воспользоваться Token Binding