Что такое OAuth 2.0 Bearer Token?

Согласно RFC6750 - Структура авторизации OAuth 2.0: использование токена-носителя, токен-носитель:

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

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

• Предположим, я реализую провайдер авторизации. Могу ли я предоставить какую-либо строку для токена на предъявителя?
• Это может быть случайная строка?
• Должна ли быть кодировка base64 некоторых атрибутов?
  Должен ли он быть хеширован?
• И нужно ли поставщику услуг запрашивать у поставщика авторизации для проверки этого токена?

Спасибо за любой указатель.

Токен на предъявителя Токен
безопасности с тем свойством, что любая сторона, владеющая токеном («носитель»), может использовать токен любым способом, которым может владеть любая другая сторона, обладающая этим токеном. Использование токена на предъявителя не требует, чтобы носитель доказывал владение материалом криптографического ключа (доказательство владения).

Токен на предъявителя создается для вас сервером аутентификации. Когда пользователь аутентифицирует ваше приложение (клиент), сервер аутентификации отправляется и генерирует для вас токен. Токены на предъявителя являются преобладающим типом токена доступа, используемого в OAuth 2.0. Токен на предъявителя в основном гласит: «Дай носителю доступ к этому токену».

Токен на предъявителя обычно представляет собой некое непрозрачное значение, создаваемое сервером аутентификации. Это не случайно; он создается на основе того, что пользователь предоставляет вам доступ, а клиент получает доступ к вашему приложению.

Например, для доступа к API вам необходимо использовать токен доступа. Жетоны доступа недолговечны (около часа). Вы используете токен на предъявителя, чтобы получить новый токен доступа. Чтобы получить токен доступа, вы отправляете серверу аутентификации этот токен на предъявителя вместе с идентификатором вашего клиента. Таким образом, сервер узнает, что приложение, использующее токен переноса, является тем же приложением, для которого был создан токен переноса. Пример: я не могу просто взять токен на предъявителя, созданный для вашего приложения, и использовать его с моим приложением, он не будет работать, потому что он не был сгенерирован для меня.

Маркер Google Refresh выглядит примерно так: 1 / mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM

скопировано из комментария: я не думаю, что есть какие-либо ограничения на токены на предъявителя, которые вы предоставляете. Единственное, о чем я могу думать, это то, что приятно допускать более одного. Например, пользователь может аутентифицировать приложение до 30 раз, и старые токены носителя будут работать. о, и если он не использовался, скажем, 6 месяцев, я бы удалил его из вашей системы. Это ваш сервер аутентификации, который должен будет генерировать их и проверять их, так как отформатировать это зависит от вас.

Обновить:

Маркер-носитель устанавливается в заголовке авторизации каждого HTTP-запроса встроенного действия. Например:

POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)

rsvpStatus=YES

Строка "AbCdEf123456"в приведенном выше примере является маркером авторизации канала-носителя. Это криптографический токен, созданный сервером аутентификации. Все токены на предъявителя, отправленные с действиями, имеют поле проблемы, в котором поле аудитории указывает домен отправителя в качестве URL-адреса в форме https: //. Например, если электронное письмо от noreply@example.com, аудитория адресу https://example.com .

При использовании токенов канала-носителя убедитесь, что запрос поступает с сервера аутентификации и предназначен для домена отправителя. Если токен не подтвержден, служба должна ответить на запрос с кодом ответа HTTP 401 (неавторизовано).

Токены на предъявителя являются частью стандарта OAuth V2 и широко используются многими API.

Читая ваш вопрос, я безуспешно пытался найти в Интернете способ шифрования или подписи токенов на предъявителя. Я полагаю, что токены на предъявителя не хэшируются (возможно, частично, но не полностью), потому что в этом случае невозможно будет расшифровать его и извлечь из него свойства пользователя.

Но ваш вопрос, кажется, пытается найти ответы о функциональности токена Bearer:

Предположим, я реализую провайдер авторизации. Могу ли я предоставить какую-либо строку для токена на предъявителя? Это может быть случайная строка? Должна ли быть кодировка base64 некоторых атрибутов? Должен ли он быть хеширован?

Итак, я попытаюсь объяснить, как работают токены Bearer и Refresh:

Когда пользователь запрашивает на сервере токен, отправляющий пользователя и пароль через SSL, сервер возвращает две вещи: токен доступа и токен обновления. .

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

Authorization: Bearer <access_token>

Токен доступа - это зашифрованная строка со всеми желаемыми свойствами пользователя, утверждениями и ролями. (Вы можете проверить, увеличивается ли размер токена, если вы добавите больше ролей или утверждений). Как только сервер ресурсов получит токен доступа, он сможет расшифровать его и прочитать эти пользовательские свойства. Таким образом, пользователь будет проверен и предоставлен вместе со всем приложением.

Токены доступа имеют короткий срок действия (т. Е. 30 минут). Если бы у маркеров доступа был большой срок действия, это было бы проблемой, потому что теоретически нет возможности отозвать его. Итак, представьте пользователя с ролью «Администратор», которая меняется на «Пользователь». Если пользователь хранит старый токен с role = "Admin", он сможет получить доступ до истечения срока действия токена с правами администратора. Вот почему токены доступа имеют короткий срок действия.

Но возникает одна проблема. Если токен доступа имеет короткий срок действия, мы должны отправлять каждые короткие периоды имя пользователя и пароль. Это безопасно? Нет, это не так. Мы должны избегать этого. Вот когда появляются жетоны обновления, чтобы решить эту проблему.

Токены обновления хранятся в БД и имеют длительный срок действия (например, 1 месяц).

Пользователь может получить новый токен доступа (когда он истекает, например, каждые 30 минут), используя токен обновления, который пользователь получил в первом запросе токена. Когда срок действия маркера доступа истекает, клиент должен отправить токен обновления. Если этот токен обновления существует в БД, сервер вернет клиенту новый токен доступа и другой токен обновления (и заменит старый токен обновления новым).

Если маркер доступа пользователя был скомпрометирован, токен обновления этого пользователя должен быть удален из БД. Таким образом, токен будет действителен только до истечения срока действия токена доступа, потому что, когда хакер пытается получить новый токен доступа, отправляющий токен обновления, это действие будет отклонено.

Токен на предъявителя - это одно или несколько повторений алфавита, цифры, "-", "." , "_", "~", "+", "/" с последующим 0 или более "=".

RFC 6750 2.1. Поле заголовка запроса авторизации (формат ABNF (расширенный BNF))

The syntax for Bearer credentials is as follows:

     b64token    = 1*( ALPHA / DIGIT /
                       "-" / "." / "_" / "~" / "+" / "/" ) *"="
     credentials = "Bearer" 1*SP b64token

Это выглядит как Base64, но в соответствии с Должен ли токен в заголовке быть закодирован в base64? , это не.

Окунувшись немного глубже в «HTTP / 1.1, часть 7: аутентификация» **, я вижу, что b64token - это просто определение синтаксиса ABNF, допускающее символы, обычно используемые в base64, base64url и т. Д. Так что b64token не определить любую кодировку или декодирование, а просто определить, какие символы можно использовать в части заголовка авторизации, которая будет содержать маркер доступа.

Ссылки

• RFC 5234 3.6. Повторение переменной: * Правило
• RFC 2616 2,1 дополненной БНФ