Как обрабатывать JWT на клиентском уровне?

Question

Это субъективный вопрос, хотя я считаю, что это не основано на мнении.Единственная причина, по которой я задаю этот вопрос, заключается в том, что я не смог найти удовлетворительный ответ даже после прочтения нескольких статей об аутентификации JWT.

Недавно я начал изучать JWT и обнаружил, что это трехкомпонентный токен, выдаваемый сервером клиенту дляподлинность наряду с передачей данных, таких как область действия пользователя / роли / разрешения и т. д., в формах утверждений.

Однако мой вопрос таков:

1. Часть токена утверждения все еще является base64закодированная строка, которую можно легко проанализировать с помощью atob/btoa.Так действительно ли передача безопасна?Какова реальная выгода здесь?

2. Существует множество статей о создании и отправке токена в пользовательский интерфейс.Тем не менее, почти нет хороших статей о том, что интерфейс делает именно с ним.Является ли обычной практикой декодирование токена с использованием atob и использование содержимого внутри него?Или есть другой способ проверки и извлечения данных из него.

3. Действительно ли безопасно передавать данные через заголовки.Я имею в виду, это безопасно от таких вещей, как MITM, XSS и т. Д.

Я был бы очень признателен за усилия экспертов в решении этих запросов?

Answer 1

Часть утверждения токена по-прежнему является строкой в ​​кодировке base64, которую можно легко проанализировать с помощью atob / btoa.Так действительно ли передача безопасна?Какова реальная выгода здесь?

Передача безопасна (не может быть прочитана / изменена другими), если вы отправляете токен через https.JWT содержит 2 важные части: полезную нагрузку и проверочную подпись.Подпись может быть произведена и проверена только одним лицом и доказывает, что полезная нагрузка является законной для этого лица.Вот простой пример использования:

1. Клиент отправляет учетные данные серверу аутентификации, чтобы получить право на публикацию чего-либо
2. Сервер получает учетные данные и проверяет их через сложный процесс, затемотправить обратно клиенту JWT со словами: {Я даю Клиенту право на публикацию подписанного сообщения об ошибке}
3. Клиент хранит локально токен
4. Когда клиенту нужно опубликовать что-то, он отправляетJWT и работает на сервере B, который совместно использует ключ подписи с сервером аутентификации.
5. Сервер B легко проверяет токен и публикует работу клиента

Другим примером использования является аутентификациятолько по почте.

Существует множество статей о создании и отправке токена в пользовательский интерфейс.Тем не менее, почти нет хороших статей о том, что интерфейс делает именно с ним.Является ли обычной практикой декодировать токен с помощью atob и использовать содержимое внутри него?Или существует другой способ проверки и извлечения данных из него.

Как правило, клиент хочет получить токен с какого-либо сервера, чтобы отправить его позже.Клиент не может проверить подпись, потому что он не разделяет закрытый ключ с сервером, он не является источником доверия.

Действительно ли безопасно передавать данные через заголовки.Я имею в виду, безопасен ли он от таких вещей, как MITM, XSS и т. Д.

С использованием https безопасно: Зашифрованы ли заголовки HTTPS?

Answer 2

Для вопроса № 1 выигрыш не на стороне клиента.Если вы не можете доверять тому, что получили от сервера, вы не можете доверять этому, независимо от того, как оно запутано / закодировано / зашифровано /.Дело в том, что вы отправляете этот токен обратно на сервер.На сервере быстрая проверка покажет, что этот токен является допустимым.Представьте себе сложный сценарий входа в систему, где MegaCorp просматривает разрешения для пользователя в подсистемах 739, объединяет их в одну полезную нагрузку, и затем не нужно делать это снова при последующих запросах.Когда клиент отправляет токен обратно, он проверяет, что вы правильно вошли в систему, и использует разрешения для дальнейшей обработки.

Для # 2 вы можете поместить все, что вам нравится, в эту полезную нагрузку, если это не так.не должно быть слишком безопасным.Я в основном использую его для базовой пользовательской информации и для разрешений приложений.Поэтому я могу нарисовать имя пользователя и предложить ссылку на страницу настроек конкретного пользователя.Я могу проверить, есть ли у пользователя доступ к административной странице или какие разрешения мне нужно проверить.В то время как злонамеренный пользователь может обмануть систему, манипулируя этими данными на стороне клиента, и, следовательно, может, скажем, увидеть страницу администратора, когда вызов возвращается к серверу, чтобы получить данные для этой страницы, токен является нелегитимным изапрос будет отклонен или не будет содержать надлежащих разрешений, и, опять же, он будет отклонен.

Я не знаю достаточно о безопасности, чтобы попытаться ответить на # 3.

---

Некоторые люди используют JWT только для isLoggedIn, что хорошо, но я думаю, что упускает некоторые полезные возможности.При правильном использовании это может быть единый механизм сбора пользовательской информации как для клиента, так и для сервера.Но важной стороной, на мой взгляд, является сервер.Это может быть сделано разными способами на клиенте.Но сложно найти что-то лучшее для сервера.