Идентификация приложения - связь между идентификатором приложения и токеном доступа

Question

Я новичок в OAuth и работаю над идентификацией приложения / учетные данные клиента рабочий процесс с использованием OAuth.По сути, клиентское приложение будет вызывать API, используя идентификатор приложения клиентского приложения.API будет доверять тому, кто имеет доступ к клиентскому приложению.

Для реализации я понимаю следующее:

1. регистрация клиентского приложения в Azure AD
2. установка идентификатора приложенияклиентского приложения в API
3. включить запрос OAuth, чтобы клиентское приложение могло получать токен доступа от AAD
4. , использовать токен доступа для вызова API

Но моя путаница заключается в связи между идентификатором приложения веб-приложения и маркером доступа.Я знаю, что мы должны поместить идентификатор приложения клиента в API, чтобы API мог каким-то образом распознавать клиентское приложение. Как API узнает, что токен доступа получен из этого конкретного идентификатора приложения? Как он работает в точности?

Answer 1

Для этого есть специальный протокол / механизм проверки. Как только токен получен на сервере ресурсов (например: - API, как в вашем примере), он может выполнить самоанализ токена для определения контекста токена. OAuth 2.0 Token Introspection определяет, как должен быть сформирован запрос на самоанализ и что ожидать от ответа.

Эта спецификация определяет протокол, который позволяет авторизованным защищенные ресурсы для запроса сервера авторизации, чтобы определить набор метаданных для данного токена, который был представлен им клиент OAuth 2.0.

Прочитайте раздел ответа самоанализа , чтобы определить, какие данные он будет возвращать. Идентификатор клиента также является действительным требованием.

Теперь есть и альтернативный подход. Это то, что принял Azure AD. Azure Active Directory использует токены доступа в формате JWT.

токены доступа Azure Active Directory

Токены доступа позволяют клиентам безопасно вызывать API, защищенные Azure. Маркеры доступа Azure Active Directory (Azure AD) - это JWT, объекты JSON в кодировке Base64, подписанные Azure. Клиенты должны рассматривать токены доступа как непрозрачные строки, так как содержимое токена предназначено только для ресурса.

Токены JWT являются самодостаточными, что означает, что держатель / получатель может проверить целостность токена и подтвердить правильность утверждений. Пройдите раздел проверки токена , который объясняет весь процесс. Одной из ключевых претензий, на которую вы должны обратить внимание, является audience претензия. Это обозначает предполагаемую аудиторию JWT и может иметь несколько значений (массив).

Answer 2

Идентификатор приложения также называется клиентским идентификатором, он представляет собой клиентское приложение, которое делает защищенные запросы ресурсов от имени владельца ресурса.

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

Более подробную информацию об отношениях вы можете найти в Глоссарии разработчика Azure Active Directory .

Обновление

Например, я использую поток учетных данных клиента, чтобы получить токен доступа для MS Graph API. Затем я декодирую его в https://jwt.io/. Вы найдете заявки "aud": "https://graph.microsoft.com/", "appid": "xxxxxx", "app_displayname": "joywebapp2", подробности см. В разделе Заявки в токенах доступа .

Если вы используете токен доступа для вызова MS Graph API, он будет знать, что токен доступа получен из этого конкретного клиентского приложения, как вы и просили.