Як працює автентифікація на основі файлів cookie?


210

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

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


Відповіді:


162

Файл cookie - це лише предмет у словнику. Кожен елемент має ключ і значення. Для аутентифікації ключ може бути таким, як "ім'я користувача", а значенням буде ім'я користувача. Кожен раз, коли ви робите запит на веб-сайт, ваш веб-переглядач буде включати файли cookie у запит, а хост-сервер перевірятиме файли cookie. Тож автентифікацію можна зробити автоматично.

Щоб встановити файл cookie, потрібно просто додати його до відповіді, яку сервер надсилає назад після запитів. Потім браузер додасть файл cookie після отримання відповіді.

Існують різні параметри, які можна налаштувати на сторону сервера файлів cookie, наприклад, терміни придатності або шифрування. Зашифрований файл cookie часто називають файлом cookie, який підписується. В основному сервер шифрує ключ і значення в елементі словника, тому лише сервер може використовувати інформацію. Тож cookie буде безпечним.

Веб-браузер збереже файли cookie, встановлені сервером. У заголовку HTTP кожного запиту, який браузер робить на цей сервер, він додасть файли cookie. Він додасть файли cookie лише для доменів, які їх встановлюють. Example.com може встановити файл cookie, а також додати параметри в заголовку HTTP для браузерів, щоб пересилати файли cookie назад на субдомени, наприклад sub.example.com. Неприпустимо, щоб браузер ніколи не надсилав файли cookie в інший домен.


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

1
Ви можете встановити параметри у заголовку HTTP для того, як браузер обробляє піддомени.
Конор Патрік

288

Я усвідомлюю, що це запізнилося на роки, але я подумав, що зможу розширити відповідь Конора і додати ще трохи до дискусії.

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

Крок 1: Клієнт> Реєстрація

Перш за все, користувач повинен зареєструватися. Клієнт розміщує на сервері запит HTTP, що містить його ім’я та ім’я користувача.

Крок 2: Сервер> Обробка реєстрації

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

Крок 3: Клієнт> Вхід користувача

Тепер ваш користувач входить у систему. Він / вона надає їх ім’я користувача / пароль, і знову це розміщується як сервер HTTP-запиту.

Крок 4: Сервер> Підтвердження входу

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

Крок 5: Сервер> Генерування маркера доступу

Якщо все перевіриться, ми створимо маркер доступу, який однозначно визначає сеанс користувача. Ще на сервері ми робимо дві речі з маркером доступу:

  1. Зберігайте його в базі даних, пов’язаній з цим користувачем
  2. Приєднайте його до файлу cookie-відповіді, який потрібно повернути клієнту. Обов’язково встановіть дату / час закінчення терміну дії, щоб обмежити сеанс користувача

Відтепер файли cookie будуть додані до кожного запиту (та відповіді), зробленого між клієнтом та сервером.

Крок 6: Клієнт> Створення запитів на сторінку

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

Це має розпочати роботу. Обов’язково очистіть файли cookie після виходу!


10
Дякуємо за опис Мені просто цікаво, як маркер доступу забезпечує безпеку? Чи може зловмисник, якщо вкраде файл cookie, представляти себе автентично зареєстрованим користувачем? Або це захищено SSL?
Рішек

6
@Richeek SSL забезпечує перехоплення під час запитів / відповідей, але зловмисник може отримати доступ до ваших файлів cookie в кінцевих точках (наприклад, у вашому браузері). Теоретично вони можуть представляти себе зареєстрованим користувачем до закінчення терміну дії файлу cookie. Я кажу "теоретично", тому що вищезгадана реалізація не справляється з цим. У вищевказаній реалізації зловмисник матиме доступ до моменту доступу до вашої бази даних (тобто наступного входу).
pllx

14
Ви можете визнати недійсним маркер доступу після закінчення терміну дії, можливо, у вашій базі даних "дата закінчення терміну дії". Або ви можете подумати про використання веб- токенів JSON (JWT) , які є як маркери доступу, але можуть обробляти термін дії маркера серед іншого. Більше про JWT тут. Зловмисник все одно матиме доступ до вашого облікового запису на короткий проміжок часу, якщо він має ваш маркер доступу / JWT, тому ви також повинні забезпечити свої кінцеві точки.
pllx

3
Мені довго довелося сказати спасибі! Дякуємо за ваше пояснення
Richeek

4
@ManuChadha, ви можете разом із ключем / сеансом також зберегти ip-адресу користувача разом з іншими ідентифікаційними параметрами, такими як user-agent тощо. Якщо запит надходить із дійсним файлом cookie, але з неправильного IP-адреса, браузера тощо, тоді ви відмовити у запиті та перенаправити користувача на сторінку входу для повторної аутентифікації.
FalcoGer

18

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

Аутентифікація на основі файлів cookie працює нормально у цих 4 кроки-

  1. Користувач надає ім’я користувача та пароль у формі для входу та натискає Увійти.
  2. Після того, як запит зроблений, сервер перевіряє користувача на бекенді, здійснюючи запит у базі даних. Якщо запит дійсний, він створить сеанс, використовуючи інформацію користувача, отриману з бази даних, і зберігає їх, для кожного сеансу створюється унікальний ідентифікатор, який називається Id сесії, за замовчуванням ідентифікатор сесії буде наданий клієнтові через браузер.
  3. Веб-переглядач буде надсилати ідентифікатор сеансу на кожен наступний запит, ідентифікатор сеансу перевіряється у відповідності до бази даних, на основі цього ідентифікатора сеансу веб-сайт визначатиме сеанс, що належить клієнту, а потім надає запит доступу.

  4. Щойно користувач виходить із програми, сеанс знищується як на стороні клієнта, так і на сервері.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.