Аутентифікація токена проти файлів cookie

Яка різниця між аутентифікацією маркера та автентифікацією за допомогою файлів cookie?

Я намагаюся реалізувати демонстрацію Ember Auth Rails Demo, але я не розумію причин використання аутентифікації токенів, як описано в FAQ Ember Auth на запитання "Чому автентифікація токена?"

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

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

Однак, утримуючи стан клієнта, також іноді можна вводити проблеми одночасності, яких просто немає в ситуаціях без громадянства . Ember.js, однак, також займається цією проблемою для вас, зокрема, дані Ember будуються з урахуванням цього. У висновку ember.js є основою призначена для зберігають стану клієнтів.

Ember.js не працює як типовий веб-додаток без громадянства , де сеанс , стан та відповідні файли cookie майже повністю обробляються сервером. Ember.js тримає його стан повністю у javascript (у пам'яті клієнта, а не в DOM, як деякі інші рамки), і не потрібен сервер для управління сеансом. Це призводить до того, що Ember.js стає більш універсальним у багатьох ситуаціях, наприклад, коли ваша програма перебуває в офлайн-режимі.

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

На мій погляд, головна причина , чому використання маркера аутентифікації замість печива , як зазначено в Ember Auth FAQ , перш за все , з - за характеру структури ember.js , а також тому , що вона більше підходить з урахуванням стану парадигми веб - додатки. Тому механізм cookie - не найкращий підхід при створенні програми Ember.js.

Я сподіваюся, що моя відповідь дасть більше значення вашому питанню.

HTTP є без громадянства. Щоб авторизувати вас, вам потрібно "підписати" кожен запит, який ви надсилаєте на сервер.

Аутентифікація маркера

• Запит на сервер підписується "токеном" - зазвичай це означає встановлення конкретних заголовків http, однак вони можуть бути надіслані в будь-яку частину запиту http (тіло POST тощо)

• Плюси:

  • Ви можете авторизувати лише ті запити, які ви хочете авторизувати. (Файли cookie - навіть файли cookie авторизації надсилаються для кожного запиту.)
  • Immune to XSRF (Короткий приклад XSRF - я надішлю вам посилання електронною поштою, яке виглядатиме так <img src="http://bank.com?withdraw=1000&to=myself" />, і якщо ви увійдете через автентифікацію файлів cookie на bank.com, а bank.com не має засобів XSRF захист, я зніму гроші з вашого рахунку просто тим, що ваш веб-переглядач запустить авторизований запит GET до цієї URL-адреси.
  • Файли cookie прив’язані до одного домену. Файл cookie, створений на домені foo.com, не може читати домен bar.com, тоді як ви можете надсилати жетони до будь-якого домену, який вам подобається. Це особливо корисно для додатків на одній сторінці, які користуються кількома послугами, які потребують авторизації, тому я можу створити веб-додаток на домені myapp.com, який може робити авторизовані клієнтські запити на myservice1.com та на myservice2.com.
• Мінуси:
  • Ви повинні десь зберігати маркер; при цьому файли cookie зберігаються "поза коробкою". Місця, які вам спадають на думку, є localStorage (con: маркер зберігається навіть після закриття вікна браузера), sessionStorage (pro: маркер відкидається після закриття вікна браузера, con: відкриття посилання на новій вкладці відобразить цю вкладку анонімні) та файли cookie (Pro: маркер відміняється після закриття вікна браузера. Якщо ви використовуєте cookie сеансу, ви отримаєте автентифікацію, відкривши посилання на новій вкладці, і ви не застраховані від XSRF, оскільки ви ігноруєте cookie для автентифікації, ви просто використовуєте його як сховище токенів. Зрозуміло: файли cookie надсилаються для кожного окремого запиту. Якщо цей файл cookie не позначений як https, ви відкриті для людини в середніх атаках.)
  • Трохи простіше зробити атаку XSS проти аутентифікації на основі лексеми (тобто, якщо я зможу запустити інжектований скрипт на вашому веб-сайті, я можу вкрасти ваш маркер; однак, аутентифікація на основі файлів cookie також не є срібною кулею - в той час як файли cookie позначені як Клієнт не може читати лише http, але він все одно може робити запити від вашого імені, які автоматично включатимуть файл cookie авторизації.)
  • Запит на завантаження файлу, який повинен працювати лише для авторизованих користувачів, вимагає використання файлового API. Цей же запит працює з поля для аутентифікації на основі файлів cookie.

Аутентифікація файлів cookie

• Запит на сервер завжди входить в cookie-авторизацію.
• Плюси:
  • Файли cookie можуть бути позначені як "лише для http", що робить їх неможливим для читання на стороні клієнта. Це краще для захисту від атаки XSS.
  • Виходить з коробки - вам не доведеться реалізовувати жоден код на стороні клієнта.
• Мінуси:
  • Зв'язано до одного домену. (Отже, якщо у вас є програма на одній сторінці, яка надсилає запити на кілька служб, ви можете зробити божевільні речі, як зворотний проксі.)
  • Вразливий для XSRF. Вам доведеться вжити додаткових заходів, щоб захистити свій сайт від підроблених запитів.
  • Надсилаються для кожного запиту (навіть для запитів, які не потребують автентифікації).

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

• Токени потрібно десь зберігати (локальне зберігання / сеанс чи файли cookie)

• Маркери можуть закінчуватися, як файли cookie, але ви маєте більше контролю

• Місцеве / сесійне зберігання не працюватиме в доменах, використовуйте маркерне cookie

• Попередні запити надсилатимуться на кожен запит CORS

• Коли вам потрібно щось передати, скористайтеся маркером, щоб отримати підписаний запит

• З XSS легше боротися, ніж з XSRF

• Маркер надсилається на кожен запит, слідкуйте за його розмірами

• Якщо ви зберігаєте конфіденційну інформацію, зашифруйте маркер

• Веб-маркери JSON можна використовувати в OAuth

• Токени - це не срібні кулі, уважно подумайте про випадки використання дозволу на використання

http://blog.auth0.com/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

Для Googlers :

• НЕ змішувати statefulness з механізмами передачі стану

СТАТЕФУННІСТЬ

• Stateful = зберегти інформацію про авторизацію на стороні сервера, це традиційний спосіб
• Без громадянства = збережіть інформацію про авторизацію на стороні клієнта разом із підписом для забезпечення цілісності

МЕХАНІЗМИ

• Cookie = спеціальний заголовок із особливою обробкою (доступ, зберігання, термін дії, безпека, автоматична передача) браузерами
• Спеціальні заголовки = наприклад Authorization, це лише заголовки без будь-якої спеціальної обробки, клієнт повинен керувати всіма аспектами передачі
• Інші . Можуть бути використані інші механізми передачі, наприклад, рядок запиту був вибором для передачі ідентифікатора автентичності на деякий час, але був залишений через його незахищеність

Порівняння стану

• "Авторизація стану" означає, що сервер зберігає та підтримує інформацію про авторизацію користувача на сервері, роблячи авторизацію частиною стану програми
• Це означає, що клієнту потрібно лише зберігати "ідентифікатор автентичності", і сервер може читати деталі аутентифікації зі своєї бази даних
• Це означає, що сервер зберігає пул активних авторів (користувачі, які ввійшли в систему) і запитуватимуть цю інформацію для кожного запиту
• "Авторизація без громадянства" означає, що сервер не зберігає та не підтримує інформацію про аутентифікацію користувача, він просто не знає, які користувачі ввійшли, і покладається на клієнта для отримання інформації про аутентифікацію
• Клієнт зберігатиме повну інформацію про аутентифікацію, наприклад, хто ви є (ідентифікатор користувача), а також, можливо, дозволи, термін придатності тощо. Це більше, ніж просто ідентифікатор автентичності, тому йому надається новий маркер імені
• Очевидно, що клієнту не можна довіряти, тому автентичні дані зберігаються разом із підписом, згенерованим з hash(data + secret key), де секретний ключ відомий лише серверу, тому цілісність даних лексеми можна перевірити
• Зауважте, що механізм токена забезпечує лише цілісність, але не конфіденційність, клієнт повинен це здійснити
• Це також означає, що для кожного запиту клієнт повинен подати повний маркер, який вимагає додаткової пропускної здатності

ПОРІВНЯННЯ МЕХАНІЗМУ

• "Cookie" - це лише заголовок, але з деякими попередньо завантаженими операціями в браузерах
• Файл cookie може бути встановлений сервером і автоматично збережений клієнтом, і він автоматично надсилатиме для того ж домену
• Файл cookie може бути позначений як httpOnlyтаким чином перешкоджати доступу клієнта до JavaScript
• Попередньо завантажені операції можуть бути недоступні на платформах, окрім браузерів (наприклад, мобільних), що може призвести до додаткових зусиль
• "Спеціальні заголовки" - це лише спеціальні заголовки без попередньо завантажених операцій
• Клієнт несе відповідальність за отримання, зберігання, захист, подачу та оновлення спеціального розділу заголовка для кожного запиту, це може допомогти запобігти простій вкладці зловмисної URL-адреси.

ПІДСУМОК

• Немає ніякої магії, стан аутентифікації потрібно зберігати десь на сервері чи клієнті
• Ви можете реалізовувати стан стану / без громадянства за допомогою файлів cookie чи інших спеціальних заголовків
• Коли люди говорять про ці речі, їх умовно налаштоване налаштування є: штат = маркер + спеціальний заголовок, державний = авторський ідентифікатор + cookie; це НЕ єдині можливі варіанти
• Вони мають плюси і мінуси, але навіть для зашифрованих жетонів не слід зберігати конфіденційну інформацію

Посилання

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

Отже, користувач переживає за те, як Google або Facebook можуть використовувати їх дані cookie, щоб вимкнути файли cookie. Але у них менше причин вимикати Веб-сховище (поки рекламодавці не знайдуть спосіб використовувати це також).

Отже, ось в чому різниця між файлами cookie та маркером, останній використовує Web Storage.

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

Дуже хороша стаття тут:

http://www.toptal.com/web/cookie-free-authentication-with-json-web-tokens-an-example-in-laravel-and-angularjs

Використовуйте маркер, коли ...

Федерація бажана. Наприклад, ви хочете використовувати одного постачальника (Token Dispensor) як видавця маркера, а потім використовувати ваш сервер api як валідатор маркера. Додаток може підтвердити автентифікацію на Token Dispensor, отримати маркер і подати цей маркер на ваш сервер api для підтвердження. (Те саме працює з входом у Google. Або Paypal. Або Salesforce.com тощо.)

Асинхронія потрібна. Наприклад, ви хочете, щоб клієнт надсилав запит, а потім зберігав його десь, щоб діяти окремою системою "пізніше". Ця окрема система не матиме синхронне з'єднання з клієнтом, і вона може не мати прямого підключення до центрального диспансеру маркера. асинхронна система обробки може зчитувати JWT, щоб визначити, чи можна та чи потрібно виконати робочий елемент у цей пізній час. Це певним чином пов'язане з ідеєю Федерації вище. Тут будьте обережні: термін дії JWT закінчується. Якщо чергу, що містить робочий предмет, не буде оброблена протягом життя JWT, тоді заявкам більше не слід довіряти.

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

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

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

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

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

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