Автор сценария: Джонатан Браун

В прошлой жизни, до того как я занялся технологией блокчейн, я 10 лет участвовал в сообществе Drupal.

Ближе к концу этого периода я создал интеграцию между Drupal и Mozilla Persona. Persona была попыткой сделать управление учетной записью неотъемлемой частью функциональности веб-браузера. В конце концов, Persona была закрыта.

Позже я узнал о плагине для браузера MetaMask. MetaMask позволяет веб-браузеру запускать приложения на основе Ethereum, по сути позволяя интерфейсным приложениям Javascript (JS) напрямую взаимодействовать с Ethereum.

MetaMask возьмет на себя все обязанности по управлению учетной записью, поэтому оказалось, что между MetaMask и Mozilla Persona есть параллели.

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

Вся суть DApp - сокращение от децентрализованного или распределенного приложения - в том, что у него нет серверной части. Здесь на помощь приходит блокчейн, помогающий отслеживать, сортировать и проверять информацию между узлами или участниками в сети.

В настоящее время JSON Web Tokens (JWT) являются модным решением для управления аутентификацией пользователей.

До JWT веб-сайты должны были поддерживать таблицу базы данных в серверной части, чтобы записывать все активные сеансы, а затем сопоставлять идентификаторы сеансов, хранящиеся в файлах cookie браузера.

JWT - это, по сути, распределенная сессионная таблица. Серверная часть криптографически подписывает некоторые утверждения о пользователе, а сгенерированный токен затем возвращается клиенту.

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

Таким образом, вход в серверную часть с учетными записями Ethereum с использованием JWT кажется очевидным путем вперед.

В качестве доказательства концепции я создал небольшое демонстрационное приложение: https://github.com/vanbexlabs/ethereum-auth-demo

Вы можете выбрать, какую учетную запись Ethereum вы хотите использовать в MetaMask.

При нажатии кнопки «Войти» среда Web3 (MetaMask / Mist) запрашивает подписание сообщения с использованием закрытого ключа учетной записи.

Затем MetaMask предложит пользователю нажать «Подписать». Это должно доказать серверной части, что они владеют закрытым ключом. Теоретически MetaMask может иметь специальный пользовательский интерфейс для входа в систему, но на данный момент все, что требуется, - это подписать сообщение.

Затем адрес учетной записи и подписанное сообщение будут возвращены в серверную часть, где они проверяются и генерируется токен JWT. Этот токен возвращается в браузер для хранения.

Продолжается обсуждение того, где в браузере должны храниться токены JWT, которые можно просмотреть здесь.

Для максимальной безопасности пользователи должны использовать как файлы cookie, так и веб-хранилище HTML5. С веб-хранилищем вы уязвимы для XSS, где JavaScript, внедренный на страницу, может читать токен. При использовании файлов cookie «HttpOnly» их нельзя прочитать из JavaScript, однако они подвержены подделке межсайтовых запросов (CSRF).

Здесь другой веб-сайт обманом заставит веб-браузер сделать запрос в другой домен, для которого у браузера есть файл cookie. Решением этой проблемы является наличие токена CSRF в локальном хранилище HTML5, который необходимо отправить вместе с запросом.

Примечание: этот токен еще не был реализован в демонстрации etherparty.

При нажатии кнопки Кто я в демонстрационном приложении серверная часть проверит токен с помощью express-jwt, и адрес будет возвращен клиенту, отображаемому во всплывающем окне.