Я хочу зрозуміти, що означає аутентифікація на основі лексеми. Я шукав Інтернет, але не зміг знайти нічого зрозумілого.
Відповіді:
Я думаю, що це тут добре пояснено - цитуючи лише ключові пропозиції довгої статті:
Загальна концепція системи аутентифікації на основі лексеми проста. Дозволити користувачам вводити своє ім’я користувача та пароль, щоб отримати маркер, який дозволяє їм отримати певний ресурс - не використовуючи ім'я користувача та пароль. Після того, як їх маркер отриманий, користувач може запропонувати маркер - який пропонує доступ до певного ресурсу протягом певного періоду - на віддалений сайт.
Іншими словами: додайте один рівень непрямості для аутентифікації - замість того, щоб автентифікувати з ім’ям користувача та паролем для кожного захищеного ресурсу, користувач аутентифікує це таким чином один раз (протягом сеансу з обмеженою тривалістю), отримує взамін обмежений часом маркер , і використовує цей маркер для подальшої аутентифікації під час сеансу.
Переваг багато - наприклад, користувач може передати токен, як тільки він його отримає, на якусь іншу автоматизовану систему, якій він готовий довіряти протягом обмеженого часу та обмеженого набору ресурсів, але не бажає довіряти своїм ім’ям користувача та паролем (тобто, з кожним ресурсом, до якого вони мають доступ, назавжди чи принаймні, поки вони не змінять свій пароль)
Якщо все ще незрозуміло, відредагуйте своє запитання, щоб уточнити, ЧОМУ вам не на 100% зрозуміло, і я впевнений, що ми можемо вам допомогти далі.
Від Auth0.com
На основі токена аутентифікація покладається на підписаний маркер, який надсилається серверу при кожному запиті.
Які переваги використання підходу на основі лексеми?
Перехресний домен / CORS: файли cookie + CORS не грають добре для різних доменів. Підхід на основі лексем дозволяє вам здійснювати дзвінки AJAX на будь-який сервер, на будь-якому домені, оскільки ви використовуєте заголовок HTTP для передачі інформації про користувача.
Без громадянства (також масштабованість на стороні сервера): немає необхідності зберігати сховище сеансів, маркер - це автономна суть, яка передає всю інформацію про користувача. Решта штату живе у файлах cookie чи локальних сховищах на стороні клієнта.
CDN: ви можете обслуговувати всі активи свого додатка з CDN (наприклад, javascript, HTML, зображення тощо), а ваша сторона сервера - це лише API.
Розв'язка: ви не прив'язані до якоїсь конкретної схеми аутентифікації. Маркер може генеруватися в будь-якому місці, отже, ваш API можна викликати з будь-якого місця, використовуючи єдиний спосіб аутентифікації цих викликів.
Мобільний готовий: коли ви починаєте працювати на рідній платформі (iOS, Android, Windows 8 тощо), файли cookie не є ідеальними, коли використовується підхід на основі токенів, це значно спрощує це.
CSRF: оскільки ви не покладаєтесь на файли cookie, вам не потрібно захищати від запитів між веб-сайтами (наприклад, неможливо було б переглядати веб-сайт, генерувати POST-запит та повторно використовувати існуючий cookie автентифікації, оскільки його не буде ).
Продуктивність: ми не представляємо тут жодних жорстких орієнтирів perf, але мережевий зворотний прохід (наприклад, пошук сеансу в базі даних), швидше за все, займе більше часу, ніж обчислення HMACSHA256 для перевірки маркера та аналізу його вмісту.
A token- це фрагмент даних, який тільки Server Xможливо міг би створити і який містить достатньо даних для ідентифікації конкретного користувача.
Ви можете уявити свою реєстраційну інформацію і задати Server Xдля token; а потім ви можете подати свою tokenзаяву та попросити Server Xвиконати певну дію, що залежить від користувача.
TokenS створюються за допомогою різних комбінацій різних методик з області криптографії, а також за допомогою даних із ширшої галузі досліджень безпеки. Якщо ви вирішили піти і створити свою власну tokenсистему, вам краще було бути справді розумним.
Маркер - це частина даних, створена сервером, і містить інформацію для ідентифікації конкретного користувача та дійсності маркера. Маркер буде містити інформацію користувача, а також спеціальний код маркера, який користувач може передати серверу за допомогою кожного методу, що підтримує автентифікацію, замість того, щоб безпосередньо передавати ім’я користувача та пароль.
Аутентифікація на основі токена - це техніка захисту, яка автентифікує користувачів, які намагаються увійти на сервер, мережу чи іншу захищену систему, використовуючи маркер безпеки, наданий сервером.
Аутентифікація проходить успішно, якщо користувач може довести серверу, що він чи вона є дійсним користувачем, передавши маркер безпеки. Служба перевіряє маркер безпеки та обробляє запит користувача.
Після того, як маркер перевірений сервісом, він використовується для встановлення контексту безпеки для клієнта, тому служба може приймати рішення про авторизацію чи аудиторську діяльність для послідовних запитів користувачів.
На основі маркера (безпека / автентифікація)
означає, що для того, щоб нам довести, що ми маємо доступ, спершу треба отримати маркер. У сценарії реального життя маркер може бути карткою доступу до будівлі, він може бути ключем до замка вашого будинку. Щоб ви могли отримати ключову карту свого офісу або ключ від свого будинку, спочатку потрібно довести, хто ви є, і що ви насправді маєте доступ до цього маркера. Це може бути настільки просто, як показати комусь ваше посвідчення особи або дати йому секретний пароль. Тож уявіть, що мені потрібно отримати доступ до свого офісу. Я спускаюсь до служби охорони, показую їм своє посвідчення, і вони дають мені цей знак, який впускає мене до будівлі. Зараз у мене є необмежений доступ робити все, що я хочу, всередині будівлі, доки я маю свій знак.
Яка користь безпеки на основі токенів?
Якщо ми знову подумаємо про незахищений API, то, що нам довелося зробити в цьому випадку, було те, що нам потрібно було надати свій пароль для всього, що ми хотіли зробити.
Уявіть собіщо кожного разу, коли ми входимо в двері в нашому офісі, ми повинні дати кожному, хто сидить поруч, двері. Зараз це було б дуже погано, адже це означає, що кожен, хто знаходиться в нашому офісі, може прийняти наш пароль і видати себе за себе, і це дуже погано. Натомість ми робимо те, що ми отримуємо маркер, звичайно, разом із паролем, але отримуємо це від однієї людини. І тоді ми можемо використовувати цей маркер де завгодно всередині будівлі. Звичайно, якщо ми втрачаємо маркер, у нас є та сама проблема, як якщо б хтось інший знав наш пароль, але це призводить нас до таких речей, як, як ми переконаємось, що якщо втратимо маркер, ми можемо відкликати доступ, а може і маркер не повинен жити довше 24 годин, тож наступного дня, коли ми приходимо до офісу, нам потрібно знову показати свій посвідчення особи. Але все-таки є лише одна людина, якій ми показуємо посвідчення особи,
Питання старе, і технологія просунулася, ось поточний стан:
JSON Web Token (JWT) - це відкритий стандарт на базі JSON (RFC 7519) для передачі претензій між сторонами в середовищі веб-додатків. Маркери розроблені таким чином, щоб вони були компактними, безпечними для URL-адрес і зручними для використання, особливо в контексті єдиного входу в веб-браузер (SSO).
Це просто хеш, який асоціюється з користувачем у базі даних чи якимось іншим способом. Цей маркер можна використовувати для автентифікації та авторизації вмісту програми, пов’язаної з доступом до користувача. Щоб отримати цей маркер на стороні клієнта, потрібно ввійти. Після першого входу потрібно зберегти отриманий маркер не будь-які інші дані, такі як сеанс, ідентифікатор сеансу, оскільки тут все є маркером для доступу до інших ресурсів програми.
Токен використовується для забезпечення автентичності користувача.
Найбільш кращим підходом на сьогодні для захисту ресурсів Web API є автентифікація користувачів на сервері Web API за допомогою підписаного маркера (який містить достатньо інформації для ідентифікації конкретного користувача), який клієнт повинен надіслати на сервер з кожним і кожен запит Це називається підходом аутентифікації на основі токена.
Аутентифікація, заснована на токені, працює наступним чином:
Користувач вводить ім'я та пароль у клієнта (клієнт означає браузер або мобільні пристрої тощо).
Потім клієнт надсилає ці дані (тобто ім’я користувача та пароль) на сервер авторизації.
Потім Сервер авторизації автентифікує облікові дані клієнта (тобто ім'я користувача та пароль), а потім генерує та повертає маркер доступу. Цей маркер доступу містить достатньо інформації для ідентифікації користувача, а також містить термін дії маркера.
Потім клієнтська програма включає маркер доступу в заголовку авторизації запиту HTTP для доступу до обмежених ресурсів з сервера ресурсів до моменту закінчення терміну дії.
У наступній статті показано, як покроково реалізувати аутентифікацію на основі токена в WEB API.
https://dotnettutorials.net/lesson/token-based-authentication-web-api/
Коли ви реєструєтесь на новому веб-сайті, вам часто надсилається електронний лист для активації облікового запису. Цей електронний лист зазвичай містить посилання, на яке потрібно натиснути. Частина цього посилання, містить маркер, сервер знає про цей маркер і може пов’язати його з вашим обліковим записом. У маркера зазвичай пов’язана дата закінчення терміну дії, тому у вас може залишитися лише годину, щоб натиснути на посилання та активувати свій рахунок. Нічого з цього неможливо за допомогою файлів cookie чи змінних сеансів, оскільки невідомо, який пристрій чи браузер користувач використовує для перевірки електронних листів.