RFC6750 · Фреймворк авторизации OAuth 2.0: использование токенов предъявителя
The OAuth 2.0 Authorization Framework: Bearer Token Usage
RFC 6750 определяет применение токенов предъявителя (Bearer) в HTTP-запросах для доступа к защищённым ресурсам OAuth 2.0. Любая сторона, владеющая таким токеном, может использовать его без доказательства владения криптографическим ключом, поэтому токен необходимо защищать от раскрытия при хранении и передаче. Документ устанавливает способы передачи токена, требования к заголовку WWW-Authenticate и кодам ошибок, а также меры против подмены, раскрытия, перенаправления и повторного использования токенов. TLS обязателен для реализации и использования этой спецификации.
IETF · RFC
Назначение
Стандартизировать общий HTTP-метод авторизации с токенами предъявителя для доступа к ресурсам, защищённым этими токенами; метод может применяться к токенам из любого источника и был разработан для OAuth 2.0.
Применение
Применяйте при проектировании клиентов и серверов ресурсов: клиентам СЛЕДУЕТ (SHOULD) выполнять аутентифицированные запросы с токеном предъявителя через поле заголовка запроса "Authorization" по схеме аутентификации "Bearer"; серверы ресурсов ДОЛЖНЫ (MUST) поддерживать этот способ. Передачу в теле формы или URI допускайте только в установленных документом условиях; способ с параметром URI НЕ СЛЕДУЕТ (SHOULD NOT) использовать из-за рисков раскрытия, если только передать токен через поле заголовка запроса "Authorization" или тело HTTP-запроса невозможно. Серверам токенов СЛЕДУЕТ (SHOULD) выдавать краткоживущие токены предъявителя — один час или менее — и токены с ограничением аудитории для предполагаемой доверяющей стороны или набора таких сторон. Клиенты ДОЛЖНЫ (MUST) всегда использовать TLS при запросах с токенами предъявителя и проверять цепочку сертификатов TLS при запросах к защищённым ресурсам; реализации НЕ ДОЛЖНЫ (MUST NOT) хранить такие токены в cookie, способных передаваться открыто.
Это документ IETF Standards Track со статусом Proposed Standard; он описывает общий HTTP-метод, применимый к токенам предъявителя из любого источника для ресурсов, защищённых этими токенами, хотя спроектирован для OAuth 2.0. Токен предъявителя не подтверждает владение ключом: компрометация токена предоставляет доступ. RFC 6750 обновлён RFC 8996 и RFC 9700; при проектировании следует учитывать их актуальные требования и рекомендации.
Официальная английская аннотация
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]
{
"id": "RFC6750",
"number": 6750,
"title_en": "The OAuth 2.0 Authorization Framework: Bearer Token Usage",
"title_ru": "Фреймворк авторизации OAuth 2.0: использование токенов предъявителя",
"summary_ru": "RFC 6750 определяет применение токенов предъявителя (Bearer) в HTTP-запросах для доступа к защищённым ресурсам OAuth 2.0. Любая сторона, владеющая таким токеном, может использовать его без доказательства владения криптографическим ключом, поэтому токен необходимо защищать от раскрытия при хранении и передаче. Документ устанавливает способы передачи токена, требования к заголовку WWW-Authenticate и кодам ошибок, а также меры против подмены, раскрытия, перенаправления и повторного использования токенов. TLS обязателен для реализации и использования этой спецификации.",
"purpose_ru": "Стандартизировать общий HTTP-метод авторизации с токенами предъявителя для доступа к ресурсам, защищённым этими токенами; метод может применяться к токенам из любого источника и был разработан для OAuth 2.0.",
"use_ru": "Применяйте при проектировании клиентов и серверов ресурсов: клиентам СЛЕДУЕТ (SHOULD) выполнять аутентифицированные запросы с токеном предъявителя через поле заголовка запроса \"Authorization\" по схеме аутентификации \"Bearer\"; серверы ресурсов ДОЛЖНЫ (MUST) поддерживать этот способ. Передачу в теле формы или URI допускайте только в установленных документом условиях; способ с параметром URI НЕ СЛЕДУЕТ (SHOULD NOT) использовать из-за рисков раскрытия, если только передать токен через поле заголовка запроса \"Authorization\" или тело HTTP-запроса невозможно. Серверам токенов СЛЕДУЕТ (SHOULD) выдавать краткоживущие токены предъявителя — один час или менее — и токены с ограничением аудитории для предполагаемой доверяющей стороны или набора таких сторон. Клиенты ДОЛЖНЫ (MUST) всегда использовать TLS при запросах с токенами предъявителя и проверять цепочку сертификатов TLS при запросах к защищённым ресурсам; реализации НЕ ДОЛЖНЫ (MUST NOT) хранить такие токены в cookie, способных передаваться открыто.",
"full_translation_path": "translations/rfc6750.html",
"full_translation_checked_at": "2026-10-10",
"full_translation_source_sha256": "9dc385cf4ecdd85024e5a95e447ede9230e11700bf35251906b25b37557d604b",
"architect_note_ru": "Это документ IETF Standards Track со статусом Proposed Standard; он описывает общий HTTP-метод, применимый к токенам предъявителя из любого источника для ресурсов, защищённых этими токенами, хотя спроектирован для OAuth 2.0. Токен предъявителя не подтверждает владение ключом: компрометация токена предоставляет доступ. RFC 6750 обновлён RFC 8996 и RFC 9700; при проектировании следует учитывать их актуальные требования и рекомендации.",
"topics_ru": [],
"translation_state": "reviewed",
"verification_level": "primary_source_reviewed",
"verification_level_ru": "Проверено по первичному тексту и реестру RFC Editor",
"verification_note_ru": "Полный текст и карточка независимо сверены с первоисточником. 2026-10-10",
"abstract_en": "This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a \"bearer\") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]",
"authors": [
"M. Jones",
"D. Hardt"
],
"organizations": [],
"publication_date": "2012-10-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-v2-bearer-23",
"page_count": 18,
"doi": "10.17487/RFC6750",
"keywords": [
"Client",
"Resource Owner",
"Authorization Server",
"Resource Server",
"Token Endpoint",
"Authorization Endpoint",
"Authorization Request",
"Authorization Grant",
"Protected Resource",
"Access Token",
"Refresh Token",
"Authorization Code",
"Implicit Grant",
"Client Identifier",
"Access Token Scope",
"Bearer Authorization Header",
"Bearer Access Token Type"
],
"formats": [
"TXT",
"HTML"
],
"relations": {
"obsoletes": [],
"obsoleted_by": [],
"updates": [],
"updated_by": [
"RFC8996",
"RFC9700"
],
"is_also": [],
"see_also": []
},
"links": {
"info": "https://www.rfc-editor.org/info/rfc6750/",
"html": "https://www.rfc-editor.org/rfc/rfc6750.html",
"txt": "https://www.rfc-editor.org/rfc/rfc6750.txt",
"datatracker": "https://datatracker.ietf.org/doc/rfc6750/"
}
}