Чи потрібно зберігати претензії користувачів у маркері JWT?

Я використовую маркери JWT у заголовках HTTP для автентифікації запитів на сервері ресурсів. Сервер ресурсів і сервер auth - це дві окремі робочі ролі в Azure.

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

Прикладами претензій є: CanEditProductList, CanEditShopDescription, CanReadUserDetails.

Причини, за які я хочу використовувати для них маркер JWT:

Кращий захист від редагування претензій на стороні клієнта (тобто злому списку претензій).
Не потрібно шукати претензії на кожен запит.

Причини, за якими я не хочу використовувати маркер JWT:

Тоді авторський сервер повинен знати список претензій, орієнтованих на додаток.
Маркер стає єдиною точкою входу.
Я прочитав кілька речей, які говорять про те, що маркери JWT не призначені для даних на рівні додатків.

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

ПРИМІТКА. Я буду використовувати HTTPS для всіх запитів API, тому мені здається, що маркер буде безпечним "достатньо". Я використовую AngularJS, C #, Web API 2 та MVC5.

— Астравагрант
джерело

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

— Seabizkit

Відповіді:

У моєму jwt я зберігаю лише претензії на ідентифікатор (userid тощо) (зашифровані).

Тоді, коли я отримую маркер на сервері (API), я можу зробити сторону сервера пошуку (db або виклик api локальної мережі) та отримати всі асоціації до userid (програми, ролі тощо)

Однак якщо ви хочете вкласти більше у jwt, будьте обережні з розміром, оскільки він, ймовірно, буде надісланий у кожному запиті, але обов'язково зашифруйте конфіденційні дані претензії.

— wchoward
джерело

Ура, DL. Ви кешуєте ролі тощо на сервері API, або просто натискаєте БД двічі кожен раз, коли отримуєте запит? (тобто один раз для ролей та один раз для фактичних запитуваних даних). Якщо ви кешуєте це, мені буде цікаво дізнатися, який метод ви використовуєте. Також ти маєш на увазі, що ти додатково шифруєш userid "всередині" вже зашифрованого маркера? Спасибі.

— Астравагрант

Я ще не ввійшов так далеко в свою реалізацію :), але так, я думав про використання кешування-сервера, щоб таким чином я не вдарявся до db так часто, і якщо зміна ролі кеш може бути видалений, щоб дозволити нове роль запитується для завантаження збереженого кешу. У моєму випадку я б, ймовірно, використовував Amazon AWS elsticache, який базується на відкритому запам’ятовуваному, але простіший у налаштуванні та використанні.

— wchoward

Я також думаю, що краща ідея отримати всю необхідну інформацію на ресурсному сервері, а не зберігати їх у маркері.

— Матеуш Мігала

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

— Seabizkit

Це звучить як автентифікація (хто це користувач), так і авторизація (що користувачеві дозволено робити) не так чітко розділені, як ви хотіли б.

Якщо ви не хочете, щоб сервер автентифікації знав, на що має право користувач, то обмежте претензії в цьому JWT на користувальницьку так, як це запропонував wchoward. У вас може бути інший сервер, відомий як сервер авторизації, шукати, на що має право користувач.

Крок авторизації може бути виконаний сервером ресурсів, коли вперше представлений клієнтом маркер аутентифікації. Потім сервер ресурсів надішле токен клієнту, що містить претензії на авторизацію.

Примітка. Обидва JWT повинні бути підписані різними ключами.

Плюси:

Аутентифікацією та авторизацією управляються окремо.
Сервер ресурсів не повинен шукати авторизацію для кожного запиту.
Інтерфейс користувача має доступ для перегляду авторизації, але не для редагування.

Con:

Клієнту потрібно обробити два маркери замість одного.
Додавання сервера авторизації додає ще одну рухому частину для управління.

— Чад Кларк
джерело

Не забувайте, що навіть коли ви перевіряєте авторизацію в інтерфейсі, вам все одно доведеться перевіряти авторизацію на стороні сервера, коли надходить запит.

— Чад Кларк