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

171

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

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

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

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

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

oauth bearer-token

— Алекс Бопре
источник

Предположим, я реализую провайдер авторизации. Могу ли я предоставить какую-либо строку для токена на предъявителя? Это может быть случайная строка? Токены доступа выдаются через конечные точки OAuth 2.0 Auth0: / authorize и / oauth / token. Вы можете использовать любую OAuth 2.0-совместимую библиотеку для получения токенов доступа. Если у вас еще нет предпочитаемой библиотеки OAuth 2.0, Auth0 предоставляет библиотеки для многих языков и сред.

— Бхараткумар V

Ответы:

146

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

Токен на предъявителя создается для вас сервером аутентификации. Когда пользователь аутентифицирует ваше приложение (клиент), сервер аутентификации отправляется и генерирует для вас токен. Токены на предъявителя являются преобладающим типом токена доступа, используемого в 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.

— DaImTo
источник

@ Xavier Egea Bearer - это в основном ваш токен обновления, а не токен доступа.

— Ахил

Токен на предъявителя не означает его токен обновления @AqeelSmith tools.ietf.org/html/rfc6750#section-6.1.1

— Суман Кунду

Первый абзац подразумевает, что токен Bearer является токеном обновления, а не токеном доступа. Это не вариант. Из спецификации токена Bearer «В этой спецификации описывается, как делать запросы защищенного ресурса, когда токен доступа OAuth является токеном носителя». RFC6750

— Даниэль

Прочитав ответ, я также подумал, что токены на предъявителя и токены обновления совпадают. Ответ должен быть обновлен, чтобы уточнить это.

— KurioZ7

Этот ответ очень обманчив. Токены на предъявителя НЕ являются токенами обновления, как говорится в первоначальном утверждении этого ответа. Пожалуйста исправьте.

— think01

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

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

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

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

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

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

Authorization: Bearer <access_token>

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

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

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

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

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

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

— Ксавье Эгеа
источник

Я не понимаю эту часть: «Как только Сервер авторизации получит токен доступа, он сможет расшифровать его и прочитать эти пользовательские свойства. Таким образом, пользователь будет проверен и предоставлен во всем приложении». Разве сервер авторизации не предоставляет токен доступа, не получает его? Я пытаюсь разобраться в этом вопросе, и множество примеров ясно показывают разницу между сервером авторизации и сервером ресурсов. Я понял, что вы получаете токен доступа с сервера авторизации, а затем передаете его вместе с каждым запросом, который вы делаете на сервер ресурсов?

— kivikall

@kivikall Вы правы. Я изменил это в ответе. Сервер ресурсов получает токен (токен, который Сервер авторизации зашифровал в процессе создания токена) в каждом запросе и расшифровывает его.

— Ксавье

@kivikall На самом деле для расшифровки токена должно быть что-то, связанное с авторизацией, поэтому оно должно принадлежать серверу авторизации. Вот почему написал это в ответ. Но на практике это будет означать, что при каждом запросе вы должны проверять на сервере авторизации полученный токен (возможно, при выполнении другого запроса). Поэтому, чтобы избежать потери производительности, лучше предоставить некоторые функции для расшифровки токена на сервере ресурсов. Проверьте следующую ссылку: stackoverflow.com/questions/12296017/…

— Ксавье

Но при каждом запросе сервер ресурсов должен проверять, действителен ли предоставленный AccessToken для сервера авторизации. Так что, если роль меняется, изменение может быть немедленно отражено сервером аутентификации, верно? Кроме того, почему мы должны удалить RefreshToken, если AccessToken был скомпрометирован? RefreshToken не может быть рассчитан на основе AccessToken, поэтому, когда он истекает, хакер снова блокируется.

— мандарин

Как я уже сказал, токен доступа содержит информацию о пользователе, например, роль. Если роль пользователя изменяется, это изменение будет отражено в следующем токене, когда истечет текущий токен. Это означает, что в течение короткого периода времени (до истечения срока действия токена доступа) пользователь будет выполнять ту же роль, а сервер авторизации разрешит ее, поскольку токен все еще действителен. Что касается второго вопроса, удаление маркера обновления заставляет пользователя снова вводить свои учетные данные. Это то, что мы хотим, если токен доступа скомпрометирован. В другом случае хакер может быть авторизован до истечения срока действия маркера обновления (в течение 1 месяца)

— Xavier Egea

Токен на предъявителя - это одно или несколько повторений алфавита, цифры, "-", "." , "_", "~", "+", "/" с последующим 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 не определить любую кодировку или декодирование, а просто определить, какие символы можно использовать в части заголовка авторизации, которая будет содержать маркер доступа.

Ссылки

— понедельник
источник

Вы вообще не объясняете назначение токенов на предъявителя.

— Хайме Хаблутцель