Что такое тонер-указатель OAuth 2.0 точно?

Ответ 1

  Жетон на предъявителя
Знак безопасности с собственностью, которой владеет любая сторона токен ("носитель") может использовать токен любым способом, каким сторона во владении которой может. Использование токена на предъявителя не требовать предъявителя, чтобы доказать владение материалом криптографического ключа (Доказательство правильности владения).

Токен на предъявителя создается для вас сервером аутентификации. Когда пользователь аутентифицирует ваше приложение (клиент), сервер аутентификации отправляется и генерирует для вас токен. Токены на предъявителя являются преобладающим типом токена доступа, используемого в 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://. Например, если электронное письмо отправлено с [email protected], аудитория будет https://example.com.

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

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

Ответ 2

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

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

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

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

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

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

Authorization: Bearer <access_token>

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

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

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

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

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

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

Ответ 3

Маркер-носитель - это одно или несколько повторений алфавита, цифры, "-", "."., "_", "~", "+", "/", а затем 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 Добавленный BNF