Понимание JSON веб-Токен (JWT) в контексте веб-аутентификации

Question

Некоторые заявления в отношении JWT в контексте аутентификации веб-клиент-сервер:

1. JWT не являются безопасными против человека в середине атак. Отправка JWT от безопасности клиента к серверу по безопасности равна отправке хешированного пароля.
2. JWT может нести данные пользователя как полезную нагрузку. Использование этих данных без доступа к фактическим данным в БД приводится как одна функция JWT. Однако данные JWT не будут отменять/обновлять данные, если данные БД меняются.
3. В соответствии с 2. полезная нагрузка JWT в некоторых ситуациях должна быть проверена в отношении БД и/или временная метка должна быть установлена ​​с умом, чтобы аннулировать JWT через некоторое время.

Пример реального мира, когда клиент должен выполнить несколько вызовов API, чтобы выполнить только один рабочий процесс: пользователь хочет узнать цену кратчайшего маршрута от A до B. Мы используем два типа JWT и «authJWT» & «обычный JWT».

• ЕСЛИ клиент имеет authJWT: клиент запрашивает API0 (API аутентификации) с authJWT. API0 проверяет подпись authJWT & Полезная нагрузка пользовательских данных от DB & timestamp < 2 дня. Возвращает новый «обычный» JWT.
  ELSE: клиентские запросы API0 (auth API) с паролем & для JWT с меткой времени. API0 проверяет пароль & Вход в систему для БД и возвращает authJWT & «обычный» JWT.
  В обоих случаях: все последующие API будут вызываться с «нормальным» JWT и проверять достоверность только через подпись и временную метку, но не против пользовательской БД.
• Клиент запрашивает API1 дважды, чтобы получить наилучшее соответствие для строки поиска для места A и места B. Сервер проверяет подпись JWT & timestamp < 10s и использует пользовательские данные JWT, когда это необходимо.
• Клиент запрашивает API2 для получения кратчайшего маршрута из места A в место B. Сервер проверяет подпись JWT & timestamp < 10 секунд и использует пользовательские данные JWT, если необходимо.
• Клиент запрашивает API3, чтобы получить цену за короткий маршрут. Сервер проверяет подпись JWT & timestamp < 10s и использует пользовательские данные JWT, если необходимо.

Это означает, что мужчина в середине должен поймать вызов API0, чтобы получить реальный доступ. Захват «нормального» JWT имеет небольшой эффект, поскольку он истекает через 10 секунд. Вероятно, звонки в API 1-3 могут даже проходить через простой HTTP без SSL-шифрования, но это, конечно, зависит от вашего варианта использования. Во всех случаях пользовательские данные в JWT лучше шифруются отдельно.

Какие недостатки имеет этот дизайн? Что можно улучшить?

Answer 1

Ваш пост является большим, так что извините, если я неправильно что-то

Кажется, вы говорите о чем-то вроде маркер доступа и токенов обновления. См. this и this статьи auth0.Google oauth2 использует что-то подобное:

• маркер доступа: Авторизовать доступ к защищенному ресурсу. Ограниченный срок службы. Следует держать в секрете, соображения безопасности менее строгие из-за их более короткой жизни.
• refresh token: Позволяет вашему приложению получать новые токены доступа, не требуя повторной аутентификации. Длительный срок службы. Хранить в защищенном длительного хранения

В этом post вы можете найти Рекомендации по использованию:

• веб-приложений: обновить маркер до истечения этого срока, каждый раз, когда пользователь открыть приложение и каждый фиксированной период (1 час?)

• Мобильные/родные приложения: Вход в систему один раз. Обновить токен не истекает и может быть обменен на действительный JWT. Примите во внимание специальные события, как изменить пароль

Отвечая на ваш вопрос, я думаю, API0 выступает в качестве маркера сервера обновления и API1,2 и 3 лексем потребности доступа. Избегайте ManInTheMiddle с HTTPS, в целом с API0