Поток учетных данных клиента OAuth - вызов сведений о клиенте в качестве утверждений

Question

У меня на рабочем месте есть реализация Identity Server 4.0.Помимо потоков неявного и аутентификационного кода, мы планируем использовать поток учетных данных клиента для аутентификации вызовов API-интерфейса.

Существует немного API, которым необходимо вести журнал того, кто его вызвал (имя вызывающего API).).Я много копал, но не смог найти убедительного (и безопасного) способа сделать это.

В моем понимании, в потоке Client Cred клиент собирается в IDS только с секретом клиента.И, очевидно, это сделает практически невозможным для IDS узнать, кто его вызывает.Я прав?Есть ли способ узнать клиента (чтобы можно было добавить в токен некоторые утверждения id)?

Любые предложения приветствуются.

РЕДАКТИРОВАТЬ: Вуточнить мой вопрос и лучше объяснить мое понимание этого конкретного потока OAuth :

Хорошо, поэтому позвольте мне быть ясным.Допустим, API X должен вызывать API Y.

Это следует следующему порядку: (1) X переходит к IDS с Client-Id и Client-Secret для Y. (2) IDS проверяет Client-Idи Secret и выдает токен доступа к X (3) X вызывает Y с данным токеном доступа

На шаге (2) выше, согласно потоку учетных данных клиента OAuth 2.0, нет ничего, кроме Client-ID и Client-Secret, которые X должен предоставить.Теперь, если API Z хочет общаться с Y, он собирается перейти на IDS с тем же Client-ID и тем же секретом.

Если IDS не может определить, является ли вызов аутентификации из X или Z, как он может добавить какие-либо дополнительные претензии в выданный токен?

Так что единственный другой способ узнать Yесли вызов сделан из X или Z, то X или Z сообщают себе (в заголовке, URL или почтовых данных), кто они (что делает недействительной всю цель авторизации через поток клиент-кредит).Помните, что мой вопрос не говорит об аутентификации.

Answer 1

Существует два подхода: либо использовать уникальные учетные данные клиента для каждого экземпляра (API X, API Z являются отдельными клиентами), либо использовать один и тот же клиент и / или оставить его клиенту для предоставления информации.

Суникальные клиенты, вы можете добавить информацию о клиенте в виде заявки в таблицу ClientClaims, например, Claim ('ApiName', 'apiname').

Эта заявка добавлена ​​в токен доступа и доступна в принимающем API.

В этом сценарии учетные данные клиента используются в качестве идентификатора / пароля, что позволяет клиенту входить в систему.

---

Альтернативой является использование одного и того же клиента для всех API.Теперь клиент должен предоставить информацию.

Один из сценариев может заключаться в выдаче apikey, которые можно использовать для идентификации клиента, например, в guid.Вы можете отправить его вместе с каждым вызовом.

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

С расширением предоставляет вы можете запросить необходимую информацию и преобразовать ее в действительный токен доступа.

Черезобъект ExtensionGrantValidationContext , к которому у вас есть доступ к входящему запросу токена - как общеизвестные проверенные значения, так и любые пользовательские значения (через коллекцию Raw)

Возможно, это идея 'расширить поток клиентских учетных данных с помощью APIKEY.