TL; DR: Между стандартами нет противоречий.Токены доступа OAuth могут обычно содержать любой печатный символ ASCII, но , если токен доступа является токеном носителя, он должен использовать синтаксис «token64», чтобы быть совместимым с HTTP / 1.1.
RFC 6749, §1.4 говорит нам: «Маркер доступа является строкой» и «обычно непрозрачен для клиента». §A.12 определяет его как один или несколько печатаемых символов ASCII ([ -~]+ в терминах регулярных выражений).
RFC 6749 определяет различные методы для получения токена доступа, но не заботится о том, как на самом деле использовать токен доступа, кроме как сказать, что вы "представляете его" серверу ресурсов, который должен проверить, а затем принять или отклонить его.
Но RFC 6749 требует, чтобы сервер авторизации сообщал клиенту тип токена (другая строка), который клиент может использовать для определения , как используется токен доступа.
Строка типа токена - это либо имя типа, зарегистрированное IANA (например, Bearer или mac), либо URL-адрес поставщика (например, http://oauth.example.org/v1), хотя URL-адрес простоудобный идентификатор пространства имен и не должен разрешаться ни к чему.
В большинстве развертываний тип токена будет Bearer, семантика которого определена в RFC 6750.
RFC6750 определяет три метода (§§2.1–2.3) представления токена доступа Bearer серверу ресурсов. рекомендуемый метод (который серверы ресурсов должны поддерживать, чтобы быть совместимым со стандартами) должен отправлять его в заголовке авторизации HTTP ( §2.1 ), в этом случаетокен должен быть "b64token" ([-a-zA-Z0-9._~+/]+=* в терминах регулярных выражений).
Это соответствует тому, что спецификация HTTP / 1.1 называет "token68" ( RFC 7235 §2.1 ), и являетсянеобходимо разрешить использование токена без кавычек в заголовке HTTP-авторизации.(Что касается того, почему HTTP / 1.1 допускает эти точные символы, то это связано с историческими причинами, связанными со стандартами HTTP / 1.0 и базовой аутентификацией, а также с ограничениями в текущих и исторических реализациях HTTP. Сетевые протоколы - грязное дело.)
"b64token" ( aka"token68") разрешает подмножество символов ASCII, обычно используемых с кодировкой base64, но (несмотря на имя) токен Bearer не навязывает семантику base64.Это просто непрозрачная строка, которую клиент получает с одного сервера и передает на другой.Реализации могут назначать ему семантику (например, JWT ), но это выходит за рамки стандартов токенов OAuth или Bearer.
RFC 6750 не утверждает, что токен доступа Bearer должен быть токеном b64, если используетсяс другими двумя (не рекомендуемыми) методами, но, учитывая, что клиент должен иметь возможность выбирать метод, было бы бессмысленно давать ему токен не-b64token.
Другие типы токенов OAuthможет не полагаться на то, что передается без кавычек в заголовке HTTP (или они вообще не могут использовать HTTP), и поэтому могут свободно использовать любой печатный символ ASCII.Это может быть полезно, например, для типов токенов, которые не непрозрачны для клиента;Например, в настоящее время я имею дело с настройкой, в которой ответ токена доступа выглядит примерно так:
{
"access_token": "{\"endpoint\": \"srv8.example.org\", \"session_id\": \"fafc2fd\"}",
"token_type": "http://vendor.example.org/",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
}
Здесь токен доступа представляет собой JSON-кодированную структуру данных, которую клиент должендействовать (в соответствии с правилами, связанными с типом токена поставщика) для доступа к защищенному ресурсу.