Як зробити автентифікацію без стану (без сеансу) та файлів cookie?

Боб використовує веб-додаток, щоб чогось досягти. І:

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

Деякі важливі зауваження:

• у нас є безпека транспорту ( HTTPS та його кращі друзі);
• За шторами веб-додаток передає багато операцій зовнішнім службам від імені поточного користувача (ці системи визнають Боба одним із своїх користувачів) - це означає, що ми повинні переслати їм облікові дані Боба .

Тепер, як ми можемо автентифікувати Боба (на кожен запит)? Який би розумний спосіб здійснити таке?

• грати в теніс з обліковими записами через HTML-форму прихованих полів ... м'яч містить облікові дані ( ім’я користувача та пароль ), а дві ракетки - це браузер і веб-додаток відповідно. Іншими словами, ми можемо транспортувати дані туди-назад через поля форми, а не через cookie-файли. У кожному веб-запиті браузер розміщує облікові дані. Хоча у випадку застосування на одній сторінці це може виглядати як гра в сквош на гумовій стіні, а не в теніс , оскільки веб-форма, що містить облікові дані, може залишатися живою протягом усього життя веб-сторінки. (і сервер буде налаштований так, щоб не пропонувати назад дані).
• зберігання імені користувача та пароля в контексті сторінки - змінні JavaScript тощо. Тут потрібна односторінка, IMHO.
• зашифрована аутентифікація на основі лексеми. У цьому випадку дія входу призведе до генерації зашифрованого маркера безпеки (ім’я користувача + пароль + щось інше). Цей маркер буде повернутий клієнтові, а майбутні запити будуть супроводжуватися маркером. Це має сенс? У нас уже є HTTPS ...
• інші ...
• в крайньому випадку: не робіть цього, зберігайте облікові дані на сесії! Сесія хороша. З печивом або без нього.

Чи виникає у вас на увазі будь-яке занепокоєння щодо веб-безпеки стосовно будь-якої з описаних раніше ідей? Наприклад,

• тайм-аут - ми можемо зберігати часову позначку разом з обліковими даними (time-mark = час, коли Боб ввів свої облікові дані). Наприклад, коли ЗАРАЗ - поріг часу> поріг , ми можемо відмовити в запиті.
• Захист сценаріїв між сайтом - не повинен відрізнятися ні в якому разі, правда?

Дуже дякую, що знайшли час прочитати це :)

Ах, я люблю ці питання - ведення сеансу без сеансу.

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

Один популярний, хоча і не зовсім механізм без громадянства (якщо припустити, що у вас є виконання JavaScript) - вбудувати файли cookie сеансу в JavaScript. Хлопець охорони в мене кричить на це, але насправді це може спрацювати - кожен запит маєX-Authentication-Tokenзаголовка чи щось подібне, і ви позначаєте це на базі даних, зберіганні файлів у пам'яті тощо на бекенді, щоб перевірити користувача. Цей маркер може мати тайм-аут у будь-який час, який ви вказали, і якщо час вичерпається, користувач повинен знову увійти. Це досить масштабовано - якщо ви зберігаєте його в базі даних, його один SQL-оператор виконується, і з правильними індексами, його виконання має зайняти дуже мало часу, навіть з кількома одночасними користувачами. Навантаження тестування тут, безумовно, допоможе. Якщо я правильно прочитав питання, це був би ваш механізм зашифрованого маркера - хоча, я настійно пропоную вам використовувати криптографічно випадковий маркер, наприклад, 32 символи, порівняно з використанням комбінації імені користувача + пароля + будь-чого іншого - таким чином він залишається непередбачувано, але ви все одно можете пов’язати його з ідентифікатором користувача чи якоюсь подібною річчю.

Залежно від того, хто б ви в кінцевому рахунку не скористалися, переконайтесь, що він надійно вам надійний HTTPS захищає вас по всьому каналу, але він не захищає вас, якщо ви пропускаєте маркер сеансу через URL (або ще гірше, облікові дані через URL). Я рекомендую використовувати заголовок, або, якщо це неможливо, щоразу надсилати маркер через POST-запит (це означатиме приховане поле форми у браузері користувача.) Останній підхід використання запиту POST повинен використовувати оборони CSRF, просто на випадок, хоча я підозрюю, що використання маркера саме по собі може бути якимось захистом CSRF.

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

Є деякі інші проблеми щодо безпеки, які я можу придумати, але вони занадто широкі, щоб їх вирішити на цьому етапі - якщо ви пам’ятаєте про всі випадки використання (і зловживань), ви, ймовірно, зможете зробити досить хорошу реалізацію ця система.

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

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

Зауважте, що надсилання облікових даних лише в URL-адресі може бути небезпечним. Наприклад, ви можете випустити маркер через заголовок HTTP-реферала або навіть хтось, хто просто перевіряє ваш трафік або дивиться ваш комп'ютер.

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