Каковы характеристики токена OAuth?

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

OAuth не указывает формат или содержимое токена. Мы просто используем зашифрованные пары имя-значение в качестве токена. Вы можете использовать любые символы в токене, но с ним гораздо проще обращаться, если токен защищен от URL-адресов. Мы достигаем этого, кодируя зашифрованный текст с безопасным для URL-адресом Base64.

Как уже отмечало большинство людей. Спецификация OAuth не дает вам точных указаний, но они говорят...

цитата из: http://tools.ietf.org/html/draft-hammer-oauth-10#section-4.9

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

«Конечно, серверам рекомендуется проявлять осторожность и разумно использовать самые длинные секреты».

с другой стороны, вы должны учитывать максимальную длину URL-адреса браузеров:

см.: http://www.boutell.com/newfaq/misc/urllength.html< /а>

Если вы читаете спецификацию, там написано:

Сервер авторизации выдает зарегистрированному клиенту идентификатор клиента
— уникальную строку, представляющую информацию о регистрации
, предоставленную клиентом. Идентификатор клиента не является секретом
; он доступен владельцу ресурса и НЕ ДОЛЖЕН использоваться
отдельно для аутентификации клиента. Идентификатор клиента уникален
для сервера авторизации.

Эта спецификация
не определяет размер строки идентификатора клиента. Клиенту следует избегать предположений о размере
идентификатора. Серверу авторизации СЛЕДУЕТ документировать размер
любого идентификатора, который он выдает.

Во-вторых, токен доступа следует отправлять как заголовок, а не как параметр URL.

Авторизация: носитель ‹ токен>.

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

  unreserved = ALPHA, DIGIT, '-', '.', '_', '~'

Все, что не является незарезервированным, получает %-кодирование.

Я не уверен, что вы просто говорите о параметре oauth_token, который передается. Обычно также необходимо хранить и передавать дополнительные параметры, такие как oauth_token_secret, oauth_signature и т. д. Некоторые из них имеют разные типы данных, например, oauth_timestamp — это целое число, представляющее секунды с 1970 года (закодированное в десятичных цифрах ASCII).

Допустимые символы для токена OAuth ограничены ограничениями на значение заголовка HTTP, поскольку токен OAuth часто отправляется в HTTP-заголовке «Авторизация».

Допустимые символы для заголовков HTTP указаны в https://tools.ietf.org/html/rfc7230#section-3.2.6. В качестве альтернативы вы можете проверить код проверки HTTP-заголовков некоторых популярных HTTP-клиентских библиотек, например, см. Headers.checkNameAndValue() утилиту OkHttp framework: https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Headers.java

И это не все. Я бы не стал включать разделитель заголовков HTTP (; и многие другие), пробельные символы (' ' и '\t') и двойные кавычки (") (см. https://tools.ietf.org/html/rfc7230#section-3.2.6), поскольку перед использованием потребуется экранировать токен OAuth. в заголовке HTTP. Часто токены используются людьми в запросах на тестирование curl, поэтому хорошие генераторы токенов не добавляют такие символы. Но вы должны проверить, какие символы может создавать генератор токенов Oauth, с которым работает ваш сервис, прежде чем делать какие-либо предположения.

Чтобы быть конкретным, даже если спецификация Oauth ничего не говорит, если вы используете java и mysql, тогда это будет 16 символов, поскольку мы обычно генерируем токены с использованием UUID и сохраняем их как BINARY (16) в базе данных. Я знаю эти детали, так как недавно занимался разработкой с использованием OAuth.