Что является более безопасным, JWT в сеансах HTTP или JWT в заголовке запроса клиента?

Question

Я пытаюсь внедрить систему аутентификации на основе JWT в один из моих проектов, и я застрял между двумя вариантами, где мне нужны некоторые разъяснения.Я предложил два подхода для реализации JWT:

Подход 1

• Клиент отправляет учетные данные для входа в систему
• Сервер проверяет учетные данные
• Сервер генерирует два токена, токен авторизации и токен обновления
• Сервер сохраняет эти токены на своем сервере redis как [ключ] = токен обновления и [значение] = токен авторизации
• Поскольку HTTP-соединения между клиентом и сервером всегда активны, Сервер устанавливает токен авторизации в сеансах http и отправляет в ответ токен обновления.
• Клиент сохраняет токен обновления в локальном хранилище браузера и использует его.всякий раз, когда http-соединение закрывается между клиентом и сервером для восстановления аутентификации.
• Кроме того, с помощью refresh-токена мы можем легко обновить auth-токен без выхода пользователя из системы.

подход 2

• Клиент отправляет учетные данные для входа в систему
• Сервер проверяет учетные данные
• Сервер генерирует токен авторизации и выполняетnds в ответ клиенту
• Клиент устанавливает токен в заголовке запроса для каждого запроса к серверу

Answer 1

Это хорошее объяснение https://auth0.com/learn/refresh-tokens/

Обновить Жетоны являются долгоживущими. Это означает, что когда клиент получает один из сервер, этот токен должен храниться надежно, чтобы он не был используется потенциальными злоумышленниками, поэтому хранить их небезопасно их в браузере. Если токен обновления пропущен, его можно использовать для получить новые токены доступа (и получить доступ к защищенным ресурсам) до черный список. Жетоны обновления должны быть выданы одному аутентифицированному клиент для предотвращения утечки токенов другими лицами. Доступ Жетоны также должны храниться в секрете, но благодаря более короткому сроку службы безопасность соображения менее критичны.

Также сеансы могут быть угнаны или зафиксированы.

Если вы используете SSL, все заголовки зашифрованы.

Поэтому я предпочту собственный механизм JWT и уделю внимание хранению токена аутентификации на стороне клиента.

Answer 2

Вот некоторые из моих разъяснений,

• Хранение долгосрочных сеансов на стороне браузера всегда рискованно
• Позвольте серверу выполнить ЗАДАНИЕ для проверки токена, отправленного третьей стороной или приложением. Убедитесь, что отправляемый токен не поврежден и действителен.
• Я предпочту подход, чтобы всегда отправлять токен в заголовках через HTTPS. Это делает его более простым и безопасным, поскольку сервер собирается проверить ваш токен w.r.t в пользовательском сеансе.