⌕ Поиск по атласу

IETF · RFC · RFC9101

RFC9101 · Механизм авторизации OAuth 2.0: запрос авторизации, защищённый с помощью JWT (JAR)

The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)

RFC 9101 определяет передачу параметров запроса авторизации OAuth 2.0 в объекте запроса (Request Object), представленном JWT. Объект подписывается с помощью JWS для защиты целостности и аутентификации источника; дополнительное шифрование с помощью JWE обеспечивает конфиденциальность. Объект передаётся непосредственно в параметре request либо по ссылке в request_uri. Сервер авторизации проверяет подпись и совпадение client_id во внешнем запросе и объекте, а для обработки использует только параметры из объекта запроса. Документ также рассматривает предотвращение понижения защиты, риски получения объектов по URI, смешения назначений JWT и раскрытия персональных данных.

Назначение

Обеспечить защиту параметров запроса авторизации на прикладном уровне при их передаче через браузер или другой пользовательский агент, где отдельные TLS-соединения сами по себе не обеспечивают сквозную защиту запроса.

Применение

Применять при проектировании клиентов и серверов авторизации OAuth 2.0, которым нужна защита целостности и подтверждение источника запроса, а при необходимости — его конфиденциальность. Согласовать поддерживаемые алгоритмы, передавать подписанный объект через request или request_uri и проверять его до обработки параметров авторизации. Для предотвращения обхода JAR обычными запросами OAuth 2.0 использовать метаданные require_signed_request_object. При получении объекта по URI учитывать допустимые адреса, размер ответа, тайм-ауты, запрет рекурсивного получения и защиту от угадывания URI.

Статус — «Предлагаемый стандарт» (Proposed Standard); согласно предоставленным метаданным, RFC не обновляет и не отменяет другие RFC. JAR защищает запрос авторизации и не заменяет требования OAuth 2.0 и TLS; шифрование объекта необязательно, подпись обязательна. Передача по request_uri требует отдельного контроля рисков подмены URI, отказа в обслуживании, повторного использования и отслеживания пользователей. Явное указание typ=oauth-authz-req+jwt помогает разделять назначения JWT, но требование такой маркировки может нарушить совместимость с существующими развёртываниями, особенно OpenID Connect.

Официальная английская аннотация

The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.

Связи документа

Читать полный русский перевод →

Официальный источник · 2021-08-01

Полные импортированные сведения карточки
{
  "id": "RFC9101",
  "number": 9101,
  "title_en": "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)",
  "title_ru": "Механизм авторизации OAuth 2.0: запрос авторизации, защищённый с помощью JWT (JAR)",
  "summary_ru": "RFC 9101 определяет передачу параметров запроса авторизации OAuth 2.0 в объекте запроса (Request Object), представленном JWT. Объект подписывается с помощью JWS для защиты целостности и аутентификации источника; дополнительное шифрование с помощью JWE обеспечивает конфиденциальность. Объект передаётся непосредственно в параметре request либо по ссылке в request_uri. Сервер авторизации проверяет подпись и совпадение client_id во внешнем запросе и объекте, а для обработки использует только параметры из объекта запроса. Документ также рассматривает предотвращение понижения защиты, риски получения объектов по URI, смешения назначений JWT и раскрытия персональных данных.",
  "purpose_ru": "Обеспечить защиту параметров запроса авторизации на прикладном уровне при их передаче через браузер или другой пользовательский агент, где отдельные TLS-соединения сами по себе не обеспечивают сквозную защиту запроса.",
  "use_ru": "Применять при проектировании клиентов и серверов авторизации OAuth 2.0, которым нужна защита целостности и подтверждение источника запроса, а при необходимости — его конфиденциальность. Согласовать поддерживаемые алгоритмы, передавать подписанный объект через request или request_uri и проверять его до обработки параметров авторизации. Для предотвращения обхода JAR обычными запросами OAuth 2.0 использовать метаданные require_signed_request_object. При получении объекта по URI учитывать допустимые адреса, размер ответа, тайм-ауты, запрет рекурсивного получения и защиту от угадывания URI.",
  "full_translation_path": "translations/rfc9101.html",
  "full_translation_checked_at": "2026-10-19",
  "full_translation_source_sha256": "a1400b5b8d27cfabb127325458a88415f83bb04b2ff9e6facbe50b8ef4ea2b60",
  "architect_note_ru": "Статус — «Предлагаемый стандарт» (Proposed Standard); согласно предоставленным метаданным, RFC не обновляет и не отменяет другие RFC. JAR защищает запрос авторизации и не заменяет требования OAuth 2.0 и TLS; шифрование объекта необязательно, подпись обязательна. Передача по request_uri требует отдельного контроля рисков подмены URI, отказа в обслуживании, повторного использования и отслеживания пользователей. Явное указание typ=oauth-authz-req+jwt помогает разделять назначения JWT, но требование такой маркировки может нарушить совместимость с существующими развёртываниями, особенно OpenID Connect.",
  "topics_ru": [],
  "translation_state": "reviewed",
  "verification_level": "primary_source_reviewed",
  "verification_level_ru": "Проверено по первичному тексту и реестру RFC Editor",
  "verification_note_ru": "Полный текст и карточка независимо сверены с первоисточником. 2026-10-19",
  "abstract_en": "The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference.",
  "authors": [
    "N. Sakimura",
    "J. Bradley",
    "M. Jones"
  ],
  "organizations": [],
  "publication_date": "2021-08-01",
  "current_status": "PROPOSED STANDARD",
  "current_status_ru": "Предлагаемый стандарт",
  "publication_status": "PROPOSED STANDARD",
  "publication_status_ru": "Предлагаемый стандарт",
  "lifecycle": "active",
  "lifecycle_ru": "Действующий",
  "stream": "IETF",
  "stream_ru": "IETF",
  "area": "sec",
  "area_ru": "Безопасность",
  "working_group": "oauth",
  "source_draft": "draft-ietf-oauth-jwsreq-34",
  "page_count": 25,
  "doi": "10.17487/RFC9101",
  "keywords": [
    "Assertion",
    "Claim",
    "Security Token",
    "OAuth",
    "JavaScript Object Notation",
    "JSON",
    "JSON Web Token",
    "JWT",
    "JSON Web Signature",
    "JWS",
    "JSON Web Encryption",
    "JWE"
  ],
  "formats": [
    "HTML",
    "TXT",
    "PDF",
    "XML"
  ],
  "relations": {
    "obsoletes": [],
    "obsoleted_by": [],
    "updates": [],
    "updated_by": [],
    "is_also": [],
    "see_also": []
  },
  "links": {
    "info": "https://www.rfc-editor.org/info/rfc9101/",
    "html": "https://www.rfc-editor.org/rfc/rfc9101.html",
    "txt": "https://www.rfc-editor.org/rfc/rfc9101.txt",
    "datatracker": "https://datatracker.ietf.org/doc/rfc9101/"
  }
}