Я читав про автентифікацію і став заплутаним щодо класифікації типів.

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

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

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

• печиво (як обговорено вище)
• лексема (JWT як приклад).

З іншого боку, коли ми говоримо про маркер, він може містити будь-яку інформацію ... Ідентифікатор сесії, наприклад ...

То що я пропустив? Чому люди не визначають щось на зразок Cookie-Session-basedабо Token-Claims-basedавтентифікацію, коли говорять про типи аутентифікації?

Я згоден, що називання різних понять заплутано. Якщо говорити про автентифікацію у веб-контексті, слід врахувати кілька аспектів.

Яку інформацію клієнт надсилає при автентифікації?

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

Як клієнт надсилає інформацію про аутентифікацію?

• Печиво . Веб-переглядачі надсилають файли cookie автоматично з кожним запитом після встановлення файлу cookie. Файли cookie вразливі до XSRF.
• Інші заголовки . Зазвичай для цього використовується заголовок авторизації. Ці заголовки не надсилаються браузером автоматично, але повинні бути встановлені клієнтом. Це вразливо для XSS.
• URL запиту . Інформація про автентифікацію включена в URL-адресу. Це зазвичай не використовується.

Який формат інформації про автентифікацію?

• Простий, неподписаний текст . Це можна використовувати для ідентифікаторів сеансу. Ідентифікатор сеансу, як правило, клієнт не може вгадати, тому сервер може довіряти, що клієнт його не підробив.
• Веб-маркер Json . JWT є криптографічно підписаними та містять інформацію про термін дії. Клієнт зазвичай може декодувати маркер, але не може його змінити, не помітивши сервер.
• Будь-який інший підписаний формат . Те саме, що і JWT. Важливим є криптографічний підпис, який заважає клієнту змінювати дані.

Бонус: як клієнт зберігає інформацію локально

• Печиво . Звичайно, це стосується використання файлів cookie для передачі інформації. Але файли cookie також можуть використовуватися як лише механізм зберігання на стороні клієнта. Для цього потрібне читання файлів cookie з сценаріїв, щоб бути корисним. Наприклад, клієнт може прочитати файл cookie з JavaScript і надіслати інформацію за допомогою заголовка авторизації.
• Місцеве зберігання . Це часто єдиний можливий метод, якщо файли cookie недоступні. Потрібне управління за допомогою JavaScript.

Що означають люди, коли кажуть ...

• "Аутентифікація на основі файлів cookie" . Я вважаю, що це зазвичай означає "Ідентифікатор сесії, надіслати файлом cookie, можливо як звичайний текст".
• Msgstr "Аутентифікація на основі маркера" . Зазвичай це означає "Претензії, надсилайте за допомогою заголовка аутентифікації, закодованого як Json Web Token."
• "Аутентифікація на основі претензій" . Може бути що-небудь, крім ідентифікатора сеансу.

Простіше кажучи,

1. Аутентифікація на основі cookie

   • Веб-клієнт (наприклад: веб-браузер) зберігає файли cookie, надіслані веб-сервером після успішної аутентифікації.
   • Файл cookie містить інформацію про користувача, клієнта, часову позначку authN та інші корисні дані з унікальним ідентифікатором для визначення файлу cookie.
   • Зазвичай файл cookie шифрується веб-сервером з набором доменних атрибутів (наприклад:) google.comі надсилає його через веб-клієнт.
   • Щоразу, коли веб-клієнт хоче отримати доступ до ресурсу домену (наприклад:) mail.google.com, він надсилатиме всі файли cookie на основі свого домену (наприклад:) google.comна веб-сервер, який перевіряє / перевіряє та надає / забороняє доступ на основі стану та часової позначки печиво.

2. Аутентифікація на основі сесії

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

3. Аутентифікація на основі маркера

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

4. Аутентифікація на основі претензій

   • Це те саме, що аутентифікація на основі лексеми, лише те, що вона додає ще деякі дані в маркер про клієнта та / або користувача, асоційованого з клієнтом.
   • Ці дані стосуються авторизації, яка розповідає про те, що повинен робити клієнт у межах ресурсу (наприклад: mail.read, mail.delete, Calendar.read).