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

Question

Из того, что я могу сказать, the OAuth 2.0 specification крайне расплывчатым с точки зрения того, что образуют 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-как-access_token имеет некоторые желательные свойства:

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

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

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

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

Answer 1

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

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

Answer 2

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