В этой статье объясняется, что такое веб-токены 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. Я объясню это в следующей статье.

Внешние ссылки —

  1. https://en.wikipedia.org/wiki/JSON_Web_Token
  2. https://self-issued.info/docs/draft-ietf-oauth-json-web-token.html
  3. https://tools.ietf.org/html/rfc7519
  4. https://scotch.io/tutorials/the-anatomy-of-a-json-web-токен
  5. https://github.com/jwtk/jjwt — библиотека JWT для Java

Надеюсь, вам понравилась эта статья. Нажмите ❤️ ниже, чтобы порекомендовать эту статью, если вы нашли ее полезной. Это позволит другим получить эту статью в своей ленте. Чтобы узнать больше о таких статьях, подпишитесь на me, вы будете уведомлены.

Спасибо за чтение!! 😀 😃