Я создал аутентификацию на основе JWT в своем приложении веб-API. Я не могу понять разницу между
- Базовый токен
- Жетон на предъявителя
Кто-нибудь может мне помочь?
Базовая проверка подлинности веб-API и носитель
Ответы:
Схемы базовой и дайджест-аутентификации предназначены для аутентификации с использованием имени пользователя и секрета (см. RFC7616 и RFC7617 ).
Схема аутентификации Bearer предназначена для аутентификации с использованием токена и описана в RFC6750 . Даже если эта схема исходит из спецификации OAuth2, вы все равно можете использовать ее в любом другом контексте, где токены обмениваются между клиентом и сервером.
Что касается аутентификации JWT, и поскольку это токен, лучшим выбором является схема аутентификации Bearer. Тем не менее, ничто не мешает вам использовать нестандартную схему, которая может соответствовать вашим требованиям.
Обычная проверка подлинности передает учетные данные в виде пар идентификатора пользователя и пароля, закодированных с использованием base64. Клиент отправляет HTTP-запросы сAuthorizationзаголовком, который содержит словоBasicword, за которым следует пробел, иbase64-encodedстроку имя пользователя: пароль.
Авторизация: Базовая ZGVtbzpwQDU1dzByZA ==
Примечание. Для базовой аутентификации, поскольку идентификатор пользователя и пароль передаются по сети в виде открытого текста (кодировка base64, но base64 - обратимая кодировка), базовая схема аутентификации небезопасна. HTTPS / TLS следует использовать вместе с базовой аутентификацией.
Аутентификация на предъявителя (также называемая аутентификацией токена ) имеет токены безопасности, называемые токенами на предъявителя. Имя «Аутентификация на предъявителя» можно понимать как « предоставить доступ носителю этого токена ». Токен-носитель - это загадочная строка, обычно генерируемая сервером в ответ на запрос входа в систему. Клиент должен отправить этот токен в заголовке авторизации при выполнении запросов к защищенным ресурсам:
Авторизация: предъявитель <жетон>
Примечание. Как и обычная проверка подлинности, проверку подлинности носителя следует использовать только через HTTPS (SSL) .
так что оба они являются авторизацией, а не авторизацией. В первом вы отправляете строку в кодировке base64 и получаете авторизацию, а во втором вы получаете обратно токен и используете его для доступа к ресурсу
—
мозговой штурм
в чем преимущество передачи токена по имени пользователя / паролю?
—
Мухаммад Умер,
@MuhammadUmer вы можете отозвать токены, а также предоставить им детальный доступ (т.е. доступ только для чтения).
—
Михай
Я нашел ответ, и он заключался в том, что вам не нужно читать db с токеном, вы можете использовать криптографию для проверки токена, лучше всего для микросервисов, у которых нет общего состояния сеанса, хотя есть балансировщик нагрузки, который может исправить одного пользователя одна услуга, но она все еще эффективна.
—
Мухаммад Умер