Может ли токен доступа OAuth 2.0 быть JWT?

Из того, что я могу сказать, спецификация OAuth 2.0 является крайне неопределенным с точки зрения того, какую форму следует access token:

Маркер может обозначать идентификатор, используемый для получения авторизации информации или может самостоятельно содержать информацию авторизации поддающимся проверке образом (то есть, токенную строку, состоящую из некоторых данных и подписи). Для того, чтобы клиент мог использовать токен, могут потребоваться дополнительные аутентификационные данные, которые выходят за рамки этой спецификации.

Маркер доступа обеспечивает уровень абстракции, заменяя различные конструкции авторизации (например, имя пользователя и пароль) одним маркером, понятным сервером ресурсов. Эта абстракция позволяет выдавать токены доступа более ограничительными, чем предоставленный для их получения, а также удалять сервер ресурсов, чтобы понять широкий диапазон методов проверки подлинности.

Агенты доступа могут иметь разные форматы, структуры и методы использования (например, криптографические свойства) на основе требований безопасности сервера ресурсов. Атрибуты доступа к токенам и методы, используемые для доступа к защищенным ресурсам , выходят за рамки данной спецификации и определяются спецификациями компаньона, такими как RFC6750.

(выделено курсивом)

Связанный RFC6750 не предлагает гораздо большей специфичности. Существует пример тела ответа HTTP, который показывает:

{
       "access_token":"mF_9.B5f-4.1JqM",
       "token_type":"Bearer",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
     }

Это указывает на то, что access_token может быть непрозрачным текстом ASCII, таким как закодированный JSON Web Token (JWT)

С моей точки зрения, похоже, что JWT-as-access_token обладает некоторыми желательными свойствами:

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

• Это позволяет легко подписать и проверить с помощью проверенных криптографических библиотек.

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

Мои вопросы: во-первых, допустимо ли для токена доступа быть JWT? Во-вторых, если это допустимо в соответствии со спецификацией, есть ли какие-либо дополнительные соображения, которые сделают использование JWT в качестве токена доступа плохими идеями?

Ответы

Ответ 1

A1: Использование JWT в качестве токена доступа, конечно же, разрешено спецификацией именно потому, что спецификация не ограничивает его формат.

A2: Идея использования JWT в качестве токена доступа заключается в том, что он может быть автономным, чтобы цель могла проверить токен доступа и использовать связанный контент без необходимости возвращаться на сервер авторизации. Это отличная собственность, но делает отзыв более сложным. Поэтому, если ваша система требует возможности немедленного отзыва доступа, JWT, вероятно, не является правильным выбором для токена доступа (хотя вы можете получить довольно далеко, сократив время жизни JWT).

Ответ 2

Пока сервер авторизации и сервер ресурсов соглашаются с тем, что означает токен доступа, не имеет значения, каков их контент. Поэтому единственная причина, по которой вы могли бы столкнуться с проблемой, заключалась бы в том, что при использовании этих двух серверов вы использовали разные библиотеки или фреймы.