Блог

Главная - Вопросы по программированию - Идентификатор приложения — взаимосвязь между идентификатором приложения и токеном доступа

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

#azure #asp.net-core #oauth-2.0 #azure-active-directory

#azure #asp.net-core #oauth-2.0 #azure-active-directory

Вопрос:

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

Понимание, которое я имею для реализации, заключается в том, что:

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

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

Ответ №1:

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

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

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

Обновить:

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

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

введите описание изображения здесь

Комментарии:

1. Часть между аутентификацией пользователей и клиентского приложения я понимаю. Но как API узнает, что токен доступа принадлежит этому конкретному клиентскому приложению?

2. @WWpana Токен будет включать утверждения, включая его разрешения, вы могли бы расшифровать токен доступа в jwt.io чтобы увидеть подробности.

3. @WWpana Вы могли бы сослаться на образец в моем обновлении.

4. Это имеет смысл. Спасибо!!

Ответ №2:

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

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

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

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

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

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

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