Мы желаем доброго времени суток всем своим читателям и вновь хотим поделиться с вами собственным опытом. Сегодня речь пойдет о безопасности обмена данных между сервером (на примере REST-full JSON API на Ruby) и клиентом (на примере iOS приложения).
Стандарт RFC 7519 JSON WebTokens (JWT)
Для начала немного скучной информации. В мае 2015 года Всемирная организация разработки технических стандартов Internet Engineering Task Force (IETF) выпустила новый стандарт безопасного обмена данными (по системе взаимоотношений клиент-сервер) RFC 7519 JSON Web Tokens (далее JWT). JWT представляет собой компактное URL-безопасное средство для верификации требований обмена данными. Требования с полезной нагрузкой передаются в JWT, как кодированный объект со структурой JSON веб-подписи (JWS) или как текст со структурой JSON веб-шифрования (JWE). Они скрепляются цифровой подписью или кодовым сообщением аутентификации (MAC) и/или шифруются.
Доступные варианты реализации
Стандарт RFC 7519 реализован широко известной компанией “Auth0” в качестве отдельных библиотек (расширений) для целого ряда языков программирования и технологий. Среди них Ruby, .NET, Python, Node.js, Java, JavaScript, PHP, Perl, Elixir, Go, Haskell, Rust, Lua, Scala, Swift, kdb+/Q, Delphi и др. Поддержка JWT по алгоритмам шифрования также весьма широка:
- HS256, HS384, HS512 (HMAC);
- RS256, RS384, RS512 (RSASSA-PKCS1-v1_5);
- ES256, ES384, ES512 (ECDSA) — с использованием хэш-функций SHA‑256, SHA‑384, SHA-512 соответственно по суффиксам.
Выбор алгоритмов шифрования и их реализация в JWT фактически полностью покрывает требования банковского сегмента и проектов из сферы e-commerce. В JetRuby JWT также используется для аутентификации клиентов мобильных приложений на iOS и Android. В наши ближайшие планы входит применение этого стандарта для кросс-платформенных решений под React Native.
API на Ruby on Rails & приложение на IOS
А теперь давайте рассмотрим серверную имплементацию JWT на примере реализации REST-full JSON API на Ruby.
Для этого нам потребуется один из следующих гемов:
gem ‘json_web_token’
gem ‘jwt’
Каждый из них хорошо нами проверен в процессе неоднократного использования. Остановимся на gem ‘jwt’.
Ставим гем в свой проект, добавляем две переменные в secrets.yml (в Heroku стиле добавляем на сервер переменные окружения и соответственно немного изменяем процесс показанной ниже реализации).
config/secrets.yml
Далее создаем вспомогательный класс и модуль для JWT. По привычке, мы кладем не имеющий отношения к бизнес-логике вспомогательный код в папку lib. В целом, это могут быть концерны, отдельные сервисы или что-то другое. Код класса и модуля немного изменен. Мы вырезали из него некоторые специфические участки по обработке действий, на случай невалидности и окончания срока действия токена. Но он полностью готов к применению в продакшн приложении.
lib/json_web_token.rb
В общем-то, на этом все. Остается добавить пару методов в ApplicationController.
Теперь блюдо готово. Его подают через колбэк для необходимых действий контроллера.
Что касается примера реализации кода на стороне клиента (мобильное приложение под iOS), то мы приведем лишь небольшой фрагмент кода функции на Objective-C. Он вставляет токен, полученный после процедуры аутентификации пользователя (в хэдер HTTP — запроса) и позволяет авторизовать клиента на определенные действия (разграничить доступы). Все, что происходит дальше слишком просто с технической точки зрения. Поэтому мы не будем отвлекать ваше внимание на тривиальные моменты.
RSA или HMAC?
RSA — это криптографический алгоритм с открытым ключем. На нем мы также не будем останавливаться, в виду большого объема информации, размещенной в открытом доступе. В технических университетах многих стран мира этот алгоритм включен в программу изучения высшей математики на начальных курсах.
А вот про HMAC стоит рассказать более подробно. Речь идет об относительно свежем механизме проверки целостности информации (1996 год). HMAC представляет собой алгоритм шифрования с использованием кода аутентификации (проверки подлинности) сообщений (по сути MAC), использующий хэш-функцию.
Нам этот механизм интересен, прежде всего потому что его применяют в JWT. HMAC быстрее, чем RSA с точки зрения проведения расчетов. Он может включать в себя несколько хэш-функций, а также использовать текущую функцию в случае “наложения” алгоритмов. То есть HMAC останется безопасным, даже если злоумышленникам удалось взломать хэш-функцию.
Как правило, оба решения работают без нареканий. А как показывает практика (в том числе наша собственная — компания JetRuby Agency уже работала с защитой информации и криптографией), основной причиной взлома ресурсов является человеческий фактор. Он многолик и может принимать формы неправильного менеджмента приватных и публичных ключей, личной расхлябанности, генерации паролей с привязкой к легко раскрываемым данным и т.д. Поэтому мы завершим статью банальным, но очень полезным советом: будьте внимательны и аккуратны. В таком случае ваши персональные данные не станут легкой добычей для злоумышленников.
