Я працюю над впровадженням OAuth 2.0 JWT access_token на своєму сервері аутентифікації. Але мені не зрозуміло, у чому різниця між audзаявою JWT та client_idзначенням заголовка HTTP. Вони однакові? Якщо ні, чи можете ви пояснити різницю між ними?

Я підозрюю, що audслід посилатися на сервер (и) ресурсів, а він client_idповинен відноситись до одного з клієнтських додатків, визнаних сервером аутентифікації (тобто веб-додатком або додатком iOS).

У моєму теперішньому випадку сервер моїх ресурсів також є моїм клієнтом веб-додатків.

Як виявляється, мої підозри були правильні. audПретензія аудиторії в JWT має на увазі посилання на сервери ресурсів, які повинні прийняти маркер.

Оскільки цей пост просто висловлюється так:

Аудиторія токена - призначений одержувач маркера.

Значення аудиторії - це рядок - як правило, базовий адресу ресурсу, до якого здійснюється доступ, наприклад https://contoso.com.

В client_idOAuth посилається на клієнтську програму, яка запитуватиме ресурси з Сервера ресурсів.

Клієнтська програма (наприклад, ваша програма iOS) запитає JWT від вашого сервера аутентифікації. При цьому він передає це client_idі client_secretразом з будь-якими обліковими записами користувачів, які можуть знадобитися. Авторизації Сервер перевіряє клієнта , використовуючи client_idі client_secretі повертає JWT.

JWT буде містити audпретензію, яка визначає, для яких серверів ресурсів JWT є дійсним. Якщо він audмістить www.myfunwebapp.com, але клієнтська програма намагається використовувати JWT увімкнено www.supersecretwebapp.com, то доступ буде відмовлено, оскільки сервер ресурсів побачить, що JWT не призначений для нього.

audПретензія JWT (аудиторія)

Відповідно до RFC 7519 :

Заявка "ауди" (аудиторія) ідентифікує одержувачів, для яких призначено JWT. Кожен принципал, призначений для обробки JWT, ОБОВ'ЯЗКОВО визначити себе зі значенням претензії на аудиторію. Якщо основна особа, яка обробляє претензію, не ідентифікує себе зі значенням претензії "aud", коли ця претензія присутня, тоді JWT ОБОВ'ЯЗКОВО бути відхилений. У загальному випадку значення "aud" - це масив чутливих до регістру рядків, кожен з яких містить значення StringOrURI. У спеціальному випадку, коли у JWT є одна аудиторія, значення "aud" МОЖЕ бути єдиною чутливою до регістру рядком, що містить значення StringOrURI. Інтерпретація цінностей аудиторії, як правило, специфічна для програми. Використання цієї претензії НЕОБХІДНО.

Заява про аудиторію ( aud), як визначено специфікацією, є загальною та є специфічною для програми. Передбачуване використання - це ідентифікація призначених одержувачів маркера. Що означає одержувач, це конкретний додаток. Значення аудиторії - це або список рядків, або це може бути одна рядок, якщо є лише одна audпретензія. Творець жетону не застосовує audправильну перевірку, відповідальність покладається на те, щоб визначити, чи слід використовувати маркер.

Яким би не було значення, коли одержувач перевіряє JWT і він хоче перевірити, що маркер призначений для використання в його цілях, він ОБОВ'ЯЗКОВО визначає, яке значення в audідентифікує себе, а маркер повинен перевірятись лише якщо заявлений ідентифікатор одержувача є присутній у audпозові. Не має значення, чи це URL-адреса чи інша рядок програми. Наприклад, якщо моя система вирішує ідентифікувати себе в audрядку: api3.app.comтоді вона повинна приймати JWT лише у тому випадку, якщо audпретензія міститься api3.app.comв її списку значень аудиторії.

Звичайно, одержувачі можуть вирішити ігнорувати aud, тому це корисно лише в тому випадку, якщо одержувач бажає позитивної перевірки того, що маркер створений саме для нього.

Моя інтерпретація, що базується на специфікації, полягає в тому, що audзаява корисна для створення спеціально створених JWT, які є дійсними лише для певних цілей. Для однієї системи це може означати, що ви хочете, щоб маркер був дійсним для деяких функцій, але не був дійсним для інших. Ви можете видавати маркери, обмежені лише певною "аудиторією", використовуючи все ті ж ключі та алгоритм перевірки.

Оскільки в типовому випадку JWT генерується довіреною службою та використовується іншими довіреними системами (системами, які не хочуть використовувати недійсні маркери), цим системам просто необхідно узгодити значення, які вони будуть використовувати.

Звичайно, audце абсолютно необов’язково, і його можна ігнорувати, якщо ваш випадок використання цього не вимагає. Якщо ви не хочете обмежувати маркери використанням певних аудиторій або жодна з ваших систем насправді не підтвердить audмаркер, то це марно.

Приклад: Доступ проти та оновлення маркерів

Один надуманий (але простий) приклад, про який я можу придумати, - можливо, ми хочемо використовувати JWT для доступу та оновлення лексем без необхідності впровадження окремих ключів шифрування та алгоритмів, а просто хочемо гарантувати, що маркери доступу не перевірятимуться як оновлення маркерів, або пороку -верса.

За допомогою audми можемо вказати претензію refreshна оновлення жетонів та заявку accessна доступ до лексем при створенні цих маркерів. Коли робиться запит на отримання нового маркера доступу з маркера оновлення, нам потрібно перевірити, що маркер оновлення був справжнім маркером оновлення. audПеревірки , як описано вище , покаже нам , чи був маркер на насправді дійсний маркер поновлення, подивившись спеціально для претензії refreshв aud.

Ідентифікатор клієнта OAuth проти audпретензії JWT

Ідентифікатор клієнта OAuth абсолютно не пов'язаний і не має прямої кореляції з audпретензіями JWT . З точки зору OAuth, лексеми - це непрозорі об'єкти.

Програма, яка приймає ці лексеми, несе відповідальність за розбір і перевірку значення цих лексем. Я не бачу великої цінності у визначенні ідентифікатора клієнта OAuth у audпретензії на JWT .

Якщо ви прийшли сюди шукати OpenID Connect (OIDC): OAuth 2.0! = OIDC

Я розумію, що це позначено як oauth 2.0, а не OIDC, однак між двома стандартами часто виникає зв'язок, оскільки обидва стандарти можуть використовувати JWT та audпретензію. І один (OIDC) в основному є розширенням іншого (OAUTH 2.0). (Я наткнувся на це питання, шукаючи OIDC сам.)

Токени доступу OAuth 2.0 ##

Для лексем OAuth 2.0 доступні відповіді досить добре висвітлюють його. Додатково тут є один відповідний розділ з OAuth 2.0 Framework (RFC 6749)

Для публічних клієнтів, що використовують неявні потоки, ця специфікація не забезпечує жодного методу для визначення клієнтом, якому клієнту видано маркер доступу.
...
Аутентифікація власників ресурсів для клієнтів виходить за межі для цієї специфікації. Будь-яка специфікація, яка використовує процес авторизації як форму делегованої автентифікації кінцевого користувача клієнту (наприклад, послуга входу третьої сторони), НЕ МОЖЕТЕ використовувати неявний потік без додаткових механізмів захисту, які б давали змогу клієнту визначити, чи має доступ маркер виданий для його використання (наприклад, обмеження аудиторії маркером доступу).

Токени ідентифікатора OIDC ##

OIDC має маркери ідентифікаторів на додаток до маркерів доступу. Специфікація OIDC явна щодо використання audпретензії в токенах ID. ( openid-connect-core-1.0 )

АУД
ПОТРІБНО. Аудиторія, для якої призначений цей маркер ідентифікатора Він ОБОВ'ЯЗКОВО повинен містити OAuth 2.0 client_id Поважаючої сторони як цінність аудиторії. Він може також містити ідентифікатори для інших аудиторій. У загальному випадку значення аудиту - це масив чутливих до регістру рядків. У загальному спеціальному випадку, коли є одна аудиторія, значення аудиту МОЖЕ бути єдиним рядком, що чутливим до регістру.

крім того, OIDC вказує azpпретензію, яка використовується разом із, audколи audмає більше ніж одне значення.

azp
ОПЦІЙНО. Уповноважена сторона - сторона, якій видано маркер ID. Якщо він присутній, ОБОВ'ЯЗКОВО містити ідентифікатор клієнта OAuth 2.0 цієї партії. Ця претензія потрібна лише тоді, коли токен ідентифікатора має єдину цінність аудиторії і ця аудиторія відрізняється від уповноваженої сторони. ЇЇ МОЖЕ бути включено навіть тоді, коли уповноважена сторона є такою самою, як одиночна аудиторія. Значення azp - це регістр, що відрізняється від регістру, що містить значення StringOrURI.

Хоча це старе, я вважаю, що питання справедливе і сьогодні

Я підозрюю, що аудит повинен посилатися на сервер (и) ресурсів, а client_id має посилатися на одне з клієнтських додатків, розпізнане сервером аутентифікації

Так, аудит має стосуватися сторони, що споживає маркер. І client_id посилається на сторону отримання лексеми.

У моєму теперішньому випадку сервер моїх ресурсів також є моїм клієнтом веб-додатків.

За сценарієм ОП, веб-додаток та сервер ресурсів належать одній стороні. Отже, це означає, що клієнт і аудиторія повинні бути однаковими. Але можуть бути ситуації, коли це не так.

Подумайте про SPA, який споживає захищений ресурсом OAuth. У цьому сценарії SPA є клієнтом. Захищений ресурс - це аудиторія маркера доступу.

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