В этой статье объясняется, что такое веб-токены Json (JWT), почему их следует использовать и как их можно использовать для обеспечения безопасности в приложении. JSON Web Token (JWT) — это открытый стандарт (RFC 7519) для безопасной передачи требований в условиях ограниченного пространства. JWT определяет простой и компактный способ безопасной передачи информации между двумя сторонами (например, клиентом и сервером) в виде объекта json. Я не собираюсь рассказывать вам кодировку, но, конечно же, я объясню кодировку также в следующей части.
Что такое веб-токены Json?
Веб-токен Json выглядит так — eyJhbGciOiIiLCJ0eXAiOiJKV1QifQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.u8eAOPhMYxbVA344-mqOythdoPqJ4C2gYl1qu0bqehk
Хотя это выглядит сложным, на самом деле это очень компактное и автономное представление утверждений с подписью для проверки их подлинности. JWT — это просто строка в следующем формате — header.payload.signature
Каждая из трех частей разделена точками. Поясним каждый из них.
Заголовок
Заголовок представляет собой объект json, состоящий из двух частей: typ: тип токена, который сам является «JWT», и alg: алгоритм хеширования, используемый для подписи jwt.
{ "alg": "HS256", "typ": "JWT" }
Затем этот объект json кодируется Base64Url для получения первой части токена.
Полезная нагрузка
Полезная нагрузка — это элемент, который содержит все данные, связанные с пользователем. В дополнение к этому есть некоторые зарезервированные утверждения, которые также могут присутствовать в полезной нагрузке.
{ "iss": "own-auth", "name": "John Doe", "admin": true }
Здесь мы добавляем только имя и свойство администратора пользователя. вы можете добавить столько, сколько хотите. iss — это зарезервированное утверждение, которое однозначно идентифицирует сторону, выпустившую JWT. Подробнее об этом можно прочитать здесь. Затем полезная нагрузка также кодируется Base64Url для формирования второй части токена.
Подпись
Подпись вычисляется с использованием алгоритма хеширования на основе закодированного заголовка, закодированной полезной нагрузки и секретного ключа. Secret Key
должен храниться в надежном месте на сервере авторизации и никогда не должен разглашаться. Например, если мы используем алгоритм HMAC SHA256
, подпись будет
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secretKey)
Подпись используется для проверки того, что отправитель JWT является тем, за кого он себя выдает, и для гарантии того, что сообщение не было изменено по пути.
После объединения всех вышеперечисленных трех компонентов мы получаем строку base64, состоящую из трех частей, разделенных точками, которую можно передать в любом запросе html или http. Если вы обнаружите, что все вышеперечисленное немного сложно, вам не о чем беспокоиться, потому что существует множество библиотек, которые выполняют кодирование и хеширование, вам просто нужно передать данные (претензии). Для библиотек — https://jwt.io/#libraries
Почему вам следует использовать веб-токены Json?
Давайте поговорим о том, почему jwt лучше, чем файлы cookie или простые веб-токены. Основные преимущества следующие:
- Поскольку JWT являются автономными токенами, серверу не нужно запрашивать базу данных, чтобы узнать о пользователе, поскольку информация о пользователе уже встроена в токен. Это уменьшает необходимость многократно запрашивать базу данных.
- Вам не нужно хранить разные файлы cookie для разных значений данных, таких как user_id, user_last_login или last_visited_page. Все это можно хранить в одном jwt.
- Токен может истечь, как файлы cookie, но у вас больше контроля над ним.
- Токены работают одинаково как на мобильной платформе, так и на веб-платформе.
Как следует использовать веб-токены Json?
Когда пользователь успешно входит в систему, независимо от механизма аутентификации, такого как электронная почта, oauth или телефон с otp, на стороне сервера создается веб-токен JSON со всеми необходимыми утверждениями и возвращается клиенту, который должен быть сохранен локально на стороне клиента. для авторизации будущих запросов.
Когда пользователь хочет сделать запрос к защищенному API, пользовательский агент должен отправить JWT в заголовке Authorization
следующим образом.
Authorization: Bearer <token>
Этот механизм аутентификации не имеет состояния, поскольку сервер никогда не сохраняет состояние пользователя. Сервер проверяет только заголовок Authorization
и получает токен. Затем сервер проверит токен на соответствие секретному ключу. Если токен действителен, сервер предоставляет разрешение клиенту.
Примечание. Как вы видели, мы только что закодировали и подписали данные, а не зашифровали их. Кодирование используется для преобразования структуры данных. JWT не предназначен для шифрования или сокрытия данных, поэтому JWT не гарантирует никакой безопасности конфиденциальных данных. Цель JWT - проверить, были ли данные подделаны в середине или нет. Лучше зашифровать jwt перед отправкой по проводам, если у вас есть какая-то конфиденциальная информация, такая как access_roles или payment_information. Я объясню это в следующей статье.
Внешние ссылки —
- https://en.wikipedia.org/wiki/JSON_Web_Token
- https://self-issued.info/docs/draft-ietf-oauth-json-web-token.html
- https://tools.ietf.org/html/rfc7519
- https://scotch.io/tutorials/the-anatomy-of-a-json-web-токен
- https://github.com/jwtk/jjwt — библиотека JWT для Java
Надеюсь, вам понравилась эта статья. Нажмите ❤️ ниже, чтобы порекомендовать эту статью, если вы нашли ее полезной. Это позволит другим получить эту статью в своей ленте. Чтобы узнать больше о таких статьях, подпишитесь на me, вы будете уведомлены.
Спасибо за чтение!! 😀 😃