Я работаю над внедрением OAuth 2.0 JWT access_token на моем сервере аутентификации. Но я не понимаю, в чем разница между audзаявлением JWT и client_idзначением заголовка HTTP. Они одинаковы? Если нет, можете ли вы объяснить разницу между ними?
Я подозреваю, что это audдолжно относиться к серверам ресурсов, а они client_idдолжны относиться к одному из клиентских приложений, распознаваемых сервером аутентификации (например, веб-приложение или приложение iOS).
В моем текущем случае мой сервер ресурсов также является моим клиентом веб-приложения.
aud REQUIRED for session_token. Contains the client_id of the client receiving the assertion.Утверждение JWT
aud(Аудитория)Согласно RFC 7519 :
Утверждение Audience (
aud), как определено в спецификации, является общим и зависит от приложения. Предполагаемое использование - определение предполагаемых получателей токена. То, что имеет в виду получатель, зависит от приложения. Значение аудитории - это либо список строк, либо одна строка, если есть только одноaudутверждение. Создатель токена не обеспечиваетaudправильную проверку, ответственность за определение того, следует ли использовать токен, лежит на получателе.Каким бы ни было значение, когда получатель проверяет JWT и хочет подтвердить, что токен предназначен для использования в его целях, он ДОЛЖЕН определить, какое значение в
audидентифицирует себя, и токен должен проверяться только в том случае, если объявленный идентификатор получателя присутствует вaudиске. Не имеет значения, является ли это URL-адресом или какой-либо другой строкой для конкретного приложения. Например, если моя система решает, что идентифицирует себяaudс помощью строки:api3.app.comтогда она должна принимать JWT только в том случае, еслиaudутверждение содержитapi3.app.comв своем списке значений аудитории.Конечно, получатели могут проигнорировать это
aud, поэтому это полезно только в том случае, если получатель хочет получить положительное подтверждение того, что токен был создан специально для него.Моя интерпретация, основанная на спецификации, заключается в том, что
audутверждение полезно для создания специально созданных JWT, которые действительны только для определенных целей. Для одной системы это может означать, что вы хотите, чтобы токен действовал для одних функций, но не действовал для других. Вы можете выпускать токены, ограниченные только определенной «аудиторией», при этом используя те же ключи и алгоритм проверки.Поскольку в типичном случае JWT создается доверенным сервисом и используется другими доверенными системами (системами, которые не хотят использовать недействительные токены), этим системам просто необходимо координировать значения, которые они будут использовать.
Конечно,
audэто совершенно необязательно, и его можно игнорировать, если ваш вариант использования этого не требует. Если вы не хотите ограничивать использование токенов определенной аудиторией или ни одна из ваших систем на самом деле не будет проверятьaudтокен, то это бесполезно.Пример: токены доступа и обновления
Я могу придумать один надуманный (но простой) пример: возможно, мы хотим использовать JWT для доступа и обновления токенов без необходимости реализовывать отдельные ключи и алгоритмы шифрования, а просто хотим гарантировать, что токены доступа не будут проверяться как токены обновления или наоборот. -верс.
Используя,
audмы можем указать требованиеrefreshдля токенов обновления и требованиеaccessдля токенов доступа при создании этих токенов. Когда делается запрос на получение нового токена доступа из токена обновления, нам необходимо проверить, что токен обновления был подлинным токеном обновления.audПроверки , как описано выше , покажет нам , был ли маркер на самом деле действительный маркер обновления, посмотрев специально для претензииrefreshвaud.OAuth ID клиента против JWT
audпретензииИдентификатор клиента OAuth совершенно не связан и не имеет прямого отношения к заявкам JWT
aud. С точки зрения OAuth токены являются непрозрачными объектами.Приложение, которое принимает эти токены, отвечает за анализ и проверку значения этих токенов. Я не вижу особой ценности в указании идентификатора клиента OAuth в
audзаявке JWT .источник
Если вы пришли сюда в поисках OpenID Connect (OIDC): OAuth 2.0! = OIDC
Я понимаю, что это помечено для oauth 2.0, а НЕ OIDC, однако часто наблюдается смешение между двумя стандартами, поскольку оба стандарта могут использовать JWT и
audутверждение. И один (OIDC) в основном является расширением другого (OAUTH 2.0). (Я сам наткнулся на этот вопрос, ища OIDC.)Токены доступа OAuth 2.0 ##
Для токенов доступа OAuth 2.0 существующие ответы довольно хорошо покрывают это. Кроме того, вот один соответствующий раздел из OAuth 2.0 Framework (RFC 6749)
Токены идентификатора OIDC ##
У OIDC есть токены ID в дополнение к токенам доступа. Спецификация OIDC явно указывает на использование
audутверждения в токенах ID. ( openid-connect-core-1.0 )кроме того, OIDC определяет
azpутверждение, которое используется вместе сaudкогдаaudимеет более одного значения.источник
Хотя это и устарело, я думаю, что вопрос актуален даже сегодня
Да, слово aud должно относиться к стороне-потребителю токена. А client_id относится к стороне получения токена.
В сценарии OP и веб-приложение, и сервер ресурсов принадлежат одной стороне. Это означает, что клиент и аудитория совпадают. Но могут быть ситуации, когда это не так.
Подумайте о SPA, который потребляет ресурс, защищенный OAuth. В этом сценарии клиентом является SPA. Защищаемый ресурс - это аудитория токена доступа.
Второй сценарий интересен. Существует рабочий проект под названием « Индикаторы ресурсов для OAuth 2.0 », в котором объясняется, где вы можете определить целевую аудиторию в запросе авторизации. Таким образом, полученный токен будет ограничен указанной аудиторией. Кроме того, в Azure OIDC используется аналогичный подход, в котором он разрешает регистрацию ресурса и разрешает запросу аутентификации содержать параметр ресурса для определения целевой аудитории маркера доступа. Такие механизмы позволяют рекламным объявлениям OAuth иметь разделение между клиентом и стороной, потребляющей токены (аудиторией).
источник