Який саме маркер носія OAuth 2.0?

Відповідно до RFC6750 -Рамки авторизації OAuth 2.0: Використання маркера носія, маркер носія:

Маркер безпеки із майном, яким будь-яка сторона, що володіє маркером ("пред'явником"), може використовувати маркер будь-яким способом, який може будь-яка інша сторона, якою володіє.

Для мене це визначення розпливчасте, і я не можу знайти жодної специфікації.

• Припустимо, я впроваджую провайдера авторизації, чи можу я поставити будь-який рядок для маркера носія?
• Чи може це бути випадковим рядком?
• Чи повинно бути базове64 кодування деяких атрибутів?
  Чи варто його хешувати?
• І чи повинен постачальник послуг запитувати постачальника авторизації, щоб перевірити цей маркер?

Дякую за будь-який вказівник.

Токен
на носії Маркер безпеки з майном, яке може мати будь-яка сторона, що має маркер ("пред'явник"), використовувати маркер будь-яким способом, який може мати будь-яка інша сторона, якою володіє. Використання маркера носія не вимагає від власника доказування володіння криптографічним ключовим матеріалом (підтвердження володіння).

Маркер Bearer є створений для вас сервером аутентифікації. Коли користувач автентифікує вашу програму (клієнта), сервер аутентифікації виходить та створює для вас маркер. Токени носія - це переважаючий тип маркера доступу, який використовується з OAuth 2.0. Маркер носія в основному говорить "Надати носію доступу до цього маркера".

Знак Bearer - це зазвичай якесь непрозоре значення, створене сервером аутентифікації. Це не випадково; він створюється на основі користувача, який надає вам доступ, і клієнта, до якого додає ваш додаток.

Для доступу до 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:

Припустимо, я впроваджую провайдера авторизації, чи можу я поставити будь-який рядок для маркера носія? Чи може це бути випадковим рядком? Чи повинно бути базове64 кодування деяких атрибутів? Чи варто його хешувати?

Отже, я спробую пояснити, як працюють маркери Bearer і Оновити маркери:

Коли користувач запитує сервер на маркер, що надсилає користувача та пароль через SSL, сервер повертає дві речі: маркер доступу та маркер оновлення .

Маркер доступу - це маркер носія, який вам доведеться додати у всі заголовки запитів, щоб бути автентифікованими як конкретний користувач.

Authorization: Bearer <access_token>

Маркер доступу - це зашифрований рядок зі всіма властивостями користувача, претензіями та ролями, які ви бажаєте. (Ви можете перевірити, що розмір маркера збільшується, якщо ви додасте більше ролей або претензій). Як тільки сервер ресурсів отримає маркер доступу, він зможе розшифрувати його та прочитати ці властивості користувача. Таким чином, користувач буде підтверджений та наданий разом із усім додатком.

Токени доступу мають короткий термін дії (тобто 30 хвилин). Якщо ж маркери доступу мали тривалий термін дії, це буде проблемою, оскільки теоретично немає можливості його відкликати. Тож уявіть користувача з ролями = "Адміністратор", які змінюються на "Користувач". Якщо користувач зберігає старий маркер з role = "Admin", він зможе отримати доступ до закінчення терміну дії з правами адміністратора. Ось чому маркери доступу мають короткий термін дії.

Але одне питання на увазі. Якщо маркер доступу має короткий термін дії, ми повинні надсилати кожен короткий період користувача та пароля. Це безпечно? Ні, це не так. Ми повинні уникати цього. Ось тоді з’являються маркери Refresh для вирішення цієї проблеми.

Токени для оновлення зберігаються в БД і мають тривалий термін дії (приклад: 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 Доповнений BNF