Різниця між "aud" і "iss" в jwt


13

Я хочу впровадити більш надійний сервіс аутентифікації і jwtє великою частиною того, що я хочу зробити, і я розумію, як написати код, але у мене виникають невеликі проблеми з розумінням різниці між зарезервованими issта audпретензіями. Я розумію, що один визначає сервер, який видає маркер, а другий стосується програми, призначеної для використання. Але те, як я розумію, це те, що моя аудиторія та емітент - це одне й те саме myserver.com- це видавання жетону, щоб люди, які приїжджають, myserver.comмогли бути авторизованими та автентифікованими. Я думаю, я не бачу різниці між двома претензіями, хоча я знаю, що є одна.
Там була написана хороша статтяmsdn щодо всіх зарезервованих претензій, і саме тут я найбільше заплутався, бо їхній емітент та аудиторія були зовсім іншими.


Можливо, вас зацікавить JWT RFC-7519
Laiv

Відповіді:


10

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

Це може не відрізнятися для вашої програми.

Але розглянемо масштабне застосування. Можливо, у вас є сервер OAuth або SSO, який видає сертифікати, і програма, яка хоче маркер, який показує, що сервер SSO перевірив облікові дані користувача і схвалив користувача використовувати його. У такому випадку ви можете мати лексему з "aud": "aud.example.com"і "iss": "sso.example.com".


О Я бачу. З мого боку це було непорозуміння, тому що я подумав дві речі: 1. Ви повинні були мати як "iss", так і "aud" як частина претензій. 2. Вони повинні були бути унікальними один для одного. Це, очевидно, не правда. Отже, якщо у вас є така програма, як моя, ви б навіть включили ці дві претензії у свої jwtабо залишили їх, оскільки вони були б однаковими?
Адам МакГурк

Ви, звичайно, можете їх залишити і додати пізніше, коли у вас є підстави використовувати його
Павло,

буде audіноді третя сторона чи ні?
Енді

Напевно, я також плутаю, чому діапазони не будуть використані для вказівки, що користувач схвалений для даної програми.
Енді

Так, audможе бути єдине значення або масив. Він повинен відповідати кожному призначеному одержувачу чи процесору. Скажімо, ви користувач (або додаток), який хоче зателефонувати на api.example.com для запуску запиту. Якщо api.example.com довіряє службі аутентифікації третьої сторони (наприклад, Auth0) для обробки автентифікації, то ця служба автентифікації повинна заповнюватися aud"api.example.com", а додаток на "api.example.com" повинен підтвердити, що це справа. Області застосування більш детальні, ніж аудиторія, і вони можуть бути також включені до корисного навантаження.
Павло
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.