Я хочу понять, что означает аутентификация на основе токенов. Я искал в интернете, но не мог найти ничего понятного.
Ответы:
Я думаю, что это хорошо объяснено здесь - цитируя только ключевые предложения длинной статьи:
Общая концепция системы аутентификации на основе токенов проста. Разрешить пользователям вводить свое имя пользователя и пароль для получения токена, который позволяет им получать определенный ресурс - без использования имени пользователя и пароля. Как только их токен получен, пользователь может предложить токен, который предоставляет доступ к определенному ресурсу на определенный период времени, удаленному сайту.
Другими словами: добавьте один уровень косвенности для аутентификации - вместо того, чтобы выполнять аутентификацию с использованием имени пользователя и пароля для каждого защищенного ресурса, пользователь аутентифицируется таким образом один раз (в течение сеанса ограниченной продолжительности), получая взамен ограниченный по времени токен и использует этот токен для дальнейшей аутентификации во время сеанса.
Преимуществ много, например, пользователь может передать токен, как только он его получит, другой автоматизированной системе, которой он желает доверять в течение ограниченного времени и ограниченного набора ресурсов, но не желает доверять своим именем пользователя и паролю (то есть каждому ресурсу, к которому им разрешен доступ, навсегда или, по крайней мере, до тех пор, пока они не изменят свой пароль).
Если что-то все еще неясно, пожалуйста, отредактируйте свой вопрос, чтобы уточнить, ЧТО не на 100% ясно для вас, и я уверен, что мы можем помочь вам в дальнейшем.
От Auth0.com
Аутентификация на основе токенов основывается на подписанном токене, который отправляется на сервер при каждом запросе.
Каковы преимущества использования токен-подхода?
Кросс-домен / CORS: куки + CORS не очень хорошо работают в разных доменах. Подход на основе токенов позволяет выполнять вызовы AJAX на любом сервере, в любом домене, поскольку вы используете HTTP-заголовок для передачи пользовательской информации.
Отсутствие состояния (масштабируемость на стороне сервера): нет необходимости хранить хранилище сеансов, токен является автономной сущностью, которая передает всю пользовательскую информацию. Остальная часть государства хранится в куки или локальном хранилище на стороне клиента.
CDN: вы можете обслуживать все ресурсы вашего приложения из CDN (например, javascript, HTML, изображения и т. Д.), А ваша серверная часть - это просто API.
Разделение: вы не привязаны к какой-либо конкретной схеме аутентификации. Токен может быть сгенерирован где угодно, поэтому ваш API может быть вызван из любого места с помощью одного способа аутентификации этих вызовов.
Готовность для мобильных устройств: когда вы начинаете работать на собственной платформе (iOS, Android, Windows 8 и т. Д.), Cookie-файлы не идеальны, когда использование подхода на основе токенов упрощает это.
CSRF: поскольку вы не полагаетесь на куки-файлы, вам не нужно защищать от межсайтовых запросов (например, невозможно отсканировать ваш сайт, сгенерировать POST-запрос и повторно использовать существующий куки-файл аутентификации, поскольку их не будет). ).
Производительность: мы не представляем здесь никаких жестких тестов производительности, но сетевой обход (например, поиск сеанса в базе данных) может занять больше времени, чем вычисление HMACSHA256 для проверки токена и анализа его содержимого.
A token- это фрагмент данных, который только Server Xмог быть создан и который содержит достаточно данных для идентификации конкретного пользователя.
Вы можете представить свою регистрационную информацию и задать Server Xдля token; а затем вы можете представить свой tokenи попросить Server Xвыполнить какое-то пользовательское действие.
TokenОни создаются с использованием различных комбинаций различных методов из области криптографии, а также с учетом более широкой области исследований в области безопасности. Если вы решите пойти и создать свою собственную tokenсистему, вам лучше быть по-настоящему умным.
Токен представляет собой фрагмент данных, созданный сервером, и содержит информацию для идентификации конкретного пользователя и допустимости токена. Токен будет содержать информацию о пользователе, а также специальный код токена, который пользователь может передавать на сервер при помощи любого метода, поддерживающего аутентификацию, вместо прямой передачи имени пользователя и пароля.
Проверка подлинности на основе токенов - это метод безопасности, который проверяет подлинность пользователей, которые пытаются войти на сервер, в сеть или в другую защищенную систему, используя токен безопасности, предоставленный сервером.
Аутентификация успешна, если пользователь может доказать серверу, что он или она является действительным пользователем, передав маркер безопасности. Служба проверяет токен безопасности и обрабатывает запрос пользователя.
После того как токен проверен службой, он используется для установления контекста безопасности для клиента, поэтому служба может принимать решения об авторизации или проверке действий для последовательных запросов пользователей.
Основанный на токене (безопасность / аутентификация)
означает, что для того, чтобы доказать, что у нас есть доступ, мы сначала должны получить токен. В реальной жизни токен может быть картой доступа к зданию, ключом к замку в вашем доме. Чтобы вы могли получить карточку-ключ для вашего офиса или ключ от вашего дома, вы должны сначала доказать, кто вы есть, и что у вас действительно есть доступ к этому токену. Это может быть что-то простое, например, показать кому-то свой идентификатор или дать ему секретный пароль. Итак, представьте, что мне нужно получить доступ к моему офису. Я иду в службу безопасности, я показываю им свое удостоверение личности, и они дают мне этот жетон, который впускает меня в здание. Теперь у меня есть неограниченный доступ к тому, что я хочу делать внутри здания, пока у меня есть свой токен.
В чем преимущество безопасности на основе токенов?
Если мы вспомним небезопасный API, то в этом случае нам нужно было предоставить наш пароль для всего, что мы хотели сделать.
Представитьчто каждый раз, когда мы входим в дверь в нашем офисе, мы должны дать каждому, кто сидит рядом с дверью, наш пароль. Теперь это будет довольно плохо, потому что это означает, что любой в нашем офисе может взять наш пароль и выдать себя за нас, и это довольно плохо. Вместо этого мы получаем токен, разумеется, вместе с паролем, но мы получаем его от одного человека. И тогда мы сможем использовать этот токен в любом месте здания. Конечно, если мы потеряем токен, у нас возникнет та же проблема, как если бы кто-то знал наш пароль, но это приводит нас к таким вещам, как, как мы можем быть уверены, что в случае потери токена мы можем отозвать доступ, и, возможно, токен не должен прожить дольше 24 часов, поэтому на следующий день, когда мы приедем в офис, нам нужно снова показать наш ID. Но, тем не менее, есть только один человек, которому мы показываем удостоверение личности,
Вопрос старый и технология продвинулась, вот текущее состояние:
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 или переменными сеанса, поскольку неизвестно, какое устройство или браузер использует клиент для проверки электронной почты.