CC BY
17
УДК 004.85
Макаров Д.А. студент
факультет «Информатика и системы управления» Московский государственный технический университет имени Н.Э. Баумана Россия, г. Москва МЕХАНИЗМ АВТОРИЗАЦИИ С ИСПОЛЬЗОВАНИЕМ
ТЕХНОЛОГИИ JWT
Аннотация: в данной статье рассмотрено использование веб-токена JWT. Определяются области применимости JWT. Также рассмотрена общая структура веб-токена и назначение его составляющих. В конце определяются основные функции и преимущества использования JWT.
Ключевые слова: JWT, JSON, токен, сервер, заголовок, полезная нагрузка, аутентификация.
Makarov D.A. student
Faculty of Informatics and Management Systems Moscow State Technical University named after N.E.
Bauman Russia, Moscow
AUTHORIZATION MECHANISM USING JWT TECHNOLOGY
Abstract: this article discusses the use of the JWT web token. Areas of JWT applicability are determined. The general structure of the web token and the purpose of its components are also considered. At the end, the main features and benefits of using JWT are identified.
Keywords: JWT, JSON, token, server, header, payload, authentication.
Наибольшим преимуществом JWT по сравнению с управлением сеансами пользователей с использованием случайного токена в памяти является то, что они позволяют делегировать логику аутентификации стороннему серверу, который может быть:
• централизованным внутренним сервером аутентификации;
• или даже полностью внешним сторонним поставщиком аутентификации, таким как, например, AuthO.
Внешний сервер аутентификации может быть полностью отделен от нашего сервера приложений и не должен делиться каким -либо секретным ключом с другими элементами сети - а именно с нашим сервером приложений. На нашем сервере не установлен секретный ключ, чтобы он не мог быть случайно потерян или украден. Кроме того, для работы аутентификации не требуется прямой связи между сервером аутентификации и сервером приложений.
Что такое JWT
Веб-токен JSON (или JWT) - это просто полезная нагрузка JSON, содержащая определенную заявку. Ключевое свойство JWT заключается в том, что для подтверждения их действительности нам нужно только взглянуть на сам токен. Нам не нужно связываться со сторонней службой или хранить JWT в памяти между запросами, чтобы подтвердить, что заявка, которую они несут, действительна - это возможно потому, что они несут код аутентификации сообщения или MAC [1].
JWT состоит из 3 частей: заголовка, полезной нагрузки и подписи. Давайте рассмотрим каждый из них, начиная с полезной нагрузки.
Полезная нагрузка JWT
Полезная нагрузка JWT - это простой объект Javascript. В этом случае полезная нагрузка содержит идентификационную информацию о данном пользователе, но в целом полезной нагрузкой может быть что-либо еще, например, информация о банковском переводе.
Нет ограничений на содержимое полезной нагрузки, но важно знать, что JWT не зашифрован. Таким образом, любая информация, которую мы помещаем в токен, по-прежнему доступна для чтения любому, кто перехватывает токен. Поэтому важно не помещать в полезную нагрузку любую пользовательскую информацию, которую злоумышленник может использовать напрямую.
Содержимое полезной нагрузки затем проверяется получателем путем проверки подписи. Но существует несколько типов подписей, поэтому получателю необходимо знать, например, какой тип подписи искать. Информация о технических метаданных этого типа о самом токене помещается в отдельный объект Javascript и отправляется вместе с полезной нагрузкой.
Как мы видим, это также простой объект Javascript. В этом заголовке мы видим, что тип подписи, используемый для этого JWT, был RS256. [2] Подробнее о множественных типах подписей в данный момент, сейчас давайте сосредоточимся на понимании того, что делает наличие подписи с точки зрения аутентификации.
Подписи JWT
Последняя часть JWT - это подпись, которая является кодом аутентификации сообщения (или MAC). Подпись JWT может быть произведена только кем-то, кто обладает как полезной нагрузкой (и заголовком), так и заданным секретным ключом. Вот как подпись используется для обеспечения аутентификации:
• пользователь отправляет имя пользователя и пароль на сервер аутентификации, который может быть нашим сервером приложений, но обычно это отдельный сервер;
• сервер аутентификации проверяет комбинацию имени пользователя и пароля и создает токен JWT с полезной нагрузкой, содержащей технический идентификатор пользователя и метку времени истечения;
• затем сервер аутентификации берет секретный ключ и использует его для подписи «Заголовок и полезная нагрузка» и отправляет его обратно в
браузер пользователя;
• браузер берет подписанный JWT и начинает отправлять его с каждым HTTP-запросом на наш сервер приложений;
• Подписанный JWT эффективно действует как временное удостоверение пользователя, которое заменяет постоянное удостоверение, которое является комбинацией имени пользователя и пароля;
И вот что сервер приложений делает с токеном JWT:
• наш сервер приложений проверяет подпись JWT и подтверждает, что действительно кто-то, владеющий секретным ключом, подписал эту конкретную полезную нагрузку;
• Полезная нагрузка идентифицирует конкретного пользователя через технический идентификатор;
• Только личный сервер обладает секретным ключом, а сервер аутентификации выдает токены только тем пользователям, которые предоставили правильный пароль;
• Поэтому наш сервер приложений может быть уверен, что этот токен действительно был предоставлен данному конкретному пользователю сервером аутентификации;
• Сервер продолжает обработку HTTP-запроса, предполагая, что он действительно принадлежит этому пользователю.
Единственный способ для злоумышленника выдать себя за пользователя - это украсть его имя пользователя и пароль для входа в систему, либо украсть секретный ключ подписи с сервера аутентификации. Как мы видим, подпись действительно является ключевой частью JWT.
Эта подпись позволяет серверу, не имеющему состояния, быть уверенным в том, что данный HTTP-запрос принадлежит данному пользователю, просто взглянув на токен JWT, присутствующий в самом запросе, не каждый раз отправлять пароль вместе с запросом.
Создание сервера без сохранения состояния является приятным побочным эффектом, но ключевое преимущество JWT заключается в том, что сервер аутентификации, который вернул JWT, и сервер приложений, который проверяет JWT, могут быть двумя совершенно разными серверами.
Это означает, что на уровне сервера приложений требуется только минимальная логика аутентификации - нам нужно только проверить JWT. Для полного кластера приложений было бы возможно делегировать вход или регистрацию одному серверу аутентификации. Это означает, что серверы приложений проще и безопаснее, поскольку большая часть функций аутентификации сосредоточена на сервере аутентификации и повторно используется в приложениях.
Использованные источники:
1. Официальный сайт технологии JWT. [Электронный ресурс]. Режим доступа: https://jwt.io/ (дата обращения: 19.01.2020)
2. RFC 7519. JSON Web Token (JWT). [Электронный ресурс]. Режим доступа: https://tools.ietf.org/html/rfc7519 (дата обращения: 19.01.2020)
