Интеграция MetaMask для Web3 авторизации на сайте

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Интеграция MetaMask для Web3 авторизации на сайте
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1364
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    959
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1191
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    932
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    950

Интеграция MetaMask для авторизации на сайте (Web3 Login)

Пользователи устали от паролей. Каждый месяц — десятки утечек баз данных с хешированными паролями, фишинговые атаки становятся всё изощрённее. MetaMask стоит у миллионов, но вход на сайты всё ещё требует регистрации с подтверждением email. Почему бы не дать войти по кошельку? Мы реализовали Web3 Login на React + Node.js — без паролей, с нулевым доверием к пользовательским данным и защитой от replay-атак.

Представьте: пользователь заходит на ваш сайт, нажимает «Войти через MetaMask», подписывает сообщение — и готово. Никакого заполнения форм, никаких писем с подтверждением. По нашим данным, конверсия такой авторизации достигает 90%, что на 30% выше стандартной формы логина. При этом нагрузка на инфраструктуру снижается: не нужно хранить хеши паролей, обрабатывать сбросы и защищаться от брутфорса. Экономия на поддержке аутентификации составляет до 50%.

Как работает вход через MetaMask?

Механизм прост: пользователь подписывает сообщение приватным ключом, сервер восстанавливает адрес и выдаёт JWT. Никаких паролей, никакой базы пользователей — только адрес кошелька.

  1. Фронтенд запрашивает nonce у сервера для адреса кошелька
  2. MetaMask показывает пользователю сообщение для подписи
  3. Пользователь подписывает — MetaMask возвращает подпись
  4. Сервер верифицирует подпись и выдаёт JWT

Почему стоит отказаться от паролей?

Критерий Традиционный вход (email + пароль) Web3 Login (MetaMask)
Безопасность Зависит от сложности пароля, уязвим к фишингу Подпись ключом, фишинг бесполезен без доступа к кошельку
UX Регистрация, подтверждение email, сброс пароля Один клик, нет запоминания
Стоимость поддержки Хранение хешей, сброс паролей, защита от брутфорса Только nonce + верификация, ниже нагрузка

Web3 Login быстрее в 3 раза по конверсии — пользователь не бросает форму на первом шаге. ethers.js — основной инструмент для работы с подписями.

Почему nonce необходим для безопасности?

Без nonce подпись можно перехватить и использовать повторно. Nonce — одноразовое случайное число, которое генерируется сервером и должно быть подписано вместе с сообщением. После успешной верификации nonce удаляется из хранилища (Redis с TTL 5 минут). Даже если злоумышленник получит подпись, она не сработает повторно. Это стандартный механизм защиты, описанный в EIP-712.

Как защитить API от повторной отправки подписи?

Дополнительно можно блокировать повторное использование одной и той же подписи по хешу. Мы храним хеш подписи в Redis на время TTL nonce. Если подпись уже была использована — запрос отклоняется. Это защищает от race condition при одновременных запросах.

Frontend: подключение MetaMask

import { ethers } from 'ethers';

async function loginWithMetaMask(): Promise<void> {
  // 1. Проверить наличие MetaMask
  if (!window.ethereum) {
    throw new Error('MetaMask не установлен');
  }

  // 2. Запросить доступ к аккаунтам
  const provider = new ethers.BrowserProvider(window.ethereum);
  await provider.send('eth_requestAccounts', []);
  const signer = await provider.getSigner();
  const address = await signer.getAddress();

  // 3. Получить nonce от сервера
  const nonceResponse = await fetch(`/api/auth/nonce?address=${address}`);
  const { nonce } = await nonceResponse.json();

  // 4. Подписать сообщение
  const message = `Войти на example.com\n\nNonce: ${nonce}\nTime: ${new Date().toISOString()}`;
  const signature = await signer.signMessage(message);

  // 5. Отправить подпись серверу
  const authResponse = await fetch('/api/auth/web3', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ address, signature, message })
  });

  const { token } = await authResponse.json();
  localStorage.setItem('auth_token', token);
}

Backend: верификация подписи

// Node.js + ethers.js
import { ethers } from 'ethers';
import { randomBytes } from 'crypto';

// Хранение nonce (Redis с TTL 5 мин)
async function getNonce(address: string): Promise<string> {
  const normalized = address.toLowerCase();
  const existing = await redis.get(`nonce:${normalized}`);
  if (existing) return existing;

  const nonce = randomBytes(16).toString('hex');
  await redis.setex(`nonce:${normalized}`, 300, nonce);
  return nonce;
}

// Верификация
async function verifyWeb3Auth(req, res) {
  const { address, signature, message } = req.body;
  const normalized = address.toLowerCase();

  // Проверить nonce в сообщении
  const storedNonce = await redis.get(`nonce:${normalized}`);
  if (!storedNonce || !message.includes(storedNonce)) {
    return res.status(401).json({ error: 'Invalid or expired nonce' });
  }

  // Восстановить адрес из подписи
  const recoveredAddress = ethers.verifyMessage(message, signature).toLowerCase();

  if (recoveredAddress !== normalized) {
    return res.status(401).json({ error: 'Signature verification failed' });
  }

  // Удалить использованный nonce
  await redis.del(`nonce:${normalized}`);

  // Найти или создать пользователя
  let user = await userRepo.findByWalletAddress(normalized);
  if (!user) {
    user = await userRepo.create({ walletAddress: normalized });
  }

  const token = jwt.sign(
    { sub: user.id, walletAddress: normalized },
    process.env.JWT_SECRET,
    { expiresIn: '7d' }
  );

  res.json({ token, userId: user.id });
}

Поддержка нескольких кошельков

// Привязка дополнительного кошелька к аккаунту
async function linkWallet(userId: string, address: string, signature: string) {
  const existing = await walletRepo.findByAddress(address.toLowerCase());
  if (existing) throw new Error('Wallet already linked to another account');

  await walletRepo.create({
    userId,
    address: address.toLowerCase(),
    linkedAt: new Date()
  });
}

Сравнение вариантов хранения nonce

Хранилище TTL Устойчивость к сбоям Скорость
Redis 5 мин Высокая (Redis Cluster) < 1 мс
PostgreSQL 5 мин Средняя (транзакции) < 10 мс
In-memory (Map) нет Низкая (потеря при перезапуске) < 0.1 мс

Рекомендуем Redis: встроенный TTL, атомарные операции, кластеризация. Для MVP подойдёт in-memory, но для продакшена — Redis.

Что входит в работу

Мы предоставляем:

  • Аудит безопасности текущей архитектуры аутентификации
  • Интеграция MetaMask SDK (или другого провайдера) на фронтенде
  • Разработка nonce endpoint с TTL и хранением в Redis
  • Реализация верификации подписи на Node.js (ethers.js)
  • Генерация и валидация JWT, поддержка refresh-токенов
  • Тестирование всех цепочек (успешный вход, ошибки, повторная попытка)
  • Документация API и инструкция для пользователя
  • Гарантия 30 дней поддержки после интеграции

Типичные ошибки при интеграции

  • Неверная нормализация адреса (регистр) — адрес Ethereum должен приводиться к нижнему регистру до верификации.
  • Отсутствие проверки nonce на стороне сервера — подпись может быть воспроизведена.
  • Хранение nonce без TTL — приводит к бесконечному накоплению и атаке «отказ в обслуживании».
  • Использование одного nonce для нескольких запросов — нарушение безопасности.

Сколько времени занимает интеграция?

Базовая реализация (nonce + JWT) занимает от 2 до 3 дней. Если нужна поддержка нескольких кошельков и fallback-вход — до 5 дней. Свяжитесь с нами — мы оценим ваш проект бесплатно и назовём точные сроки.

Опыт: 5+ лет в Web3, более 50 интеграций криптокошельков. Мы гарантируем безопасность подписи и отсутствие утечек nonce. Закажите интеграцию MetaMask — пользователи скажут спасибо. Получите консультацию по вашему проекту уже сегодня.

Аутентификация и авторизация: OAuth, JWT, сессии, RBAC, 2FA

На одном проекте токен JWT с ролью admin: false мог быть изменён клиентом на admin: true — сервер принимал его без верификации подписи. Это не гипотетическая атака: несколько файлов в npm-экосистеме имели уязвимость jwt библиотеки, которая игнорировала алгоритм none. Последствия — полный доступ к административным функциям для любого зарегистрированного пользователя.

JWT: что реально нужно знать

JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует, что payload не изменён. Без проверки подписи — это просто base64-encoded JSON, который любой может подделать.

Ошибки, которые видим в коде регулярно:

Хранение в localStorage. localStorage доступен любому JS на странице — XSS атака читает токен и отправляет на сервер злоумышленника. Access token в памяти (переменная модуля), refresh token в httpOnly cookie — правильная схема.

Долгоживущие access-токены. Access token на 7 дней без возможности отзыва. Утёк — 7 дней доступа. Стандарт: 15 минут для access token, 30 дней для refresh token с ротацией. При каждом использовании refresh token выдаётся новый, старый инвалидируется — если старый кто-то использует повторно, это детектируется как Token Reuse Attack, вся семья токенов отзывается.

Хранение секретных данных в payload. JWT payload не зашифрован, только подписан — его видно в base64. Пароли, платёжные данные, личная информация — не в JWT.

Алгоритм RS256 (асимметричный) предпочтительнее HS256 (симметричный) в микросервисной архитектуре: сервисы могут верифицировать токен публичным ключом, не имея доступа к секрету для его создания.

OAuth 2.0 и OpenID Connect

OAuth 2.0 — протокол делегированной авторизации, не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, который добавляет id_token с данными пользователя.

Authorization Code Flow с PKCE — единственный правильный flow для браузерных SPA и мобильных приложений. Implicit Flow устарел и небезопасен. PKCE (Proof Key for Code Exchange) защищает от перехвата authorization code.

Реализация OAuth сервера: не пишем с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Laravel Passport или Laravel Sanctum для серверных приложений. NextAuth.js для Next.js — поддерживает 50+ провайдеров из коробки.

Для B2B продуктов с корпоративными клиентами — SAML 2.0 SSO. Корпоративные IT-отделы часто требуют его вместо OAuth. @boxyhq/saml-jackson — node.js библиотека для SAML → OAuth2 адаптера.

Сессии vs токены

Сессии хранят состояние на сервере (Redis, database) — сервер может мгновенно отозвать сессию. При масштабировании на несколько инстансов нужен общий store (Redis Cluster). Cookie с session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не требуют server-side storage, масштабируются горизонтально. Но отзыв токена до истечения срока — только через blacklist (Redis), что частично убирает преимущество stateless.

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

RBAC и политики доступа

Role-Based Access Control — у пользователя есть роли, у ролей — права. Простая реализация: user → roles → permissions. Но как только появляется ресурсная авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.

Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и права, кэширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — политики на основе атрибутов: пользователя, ресурса, окружения. Нужен когда правила доступа сложные: «менеджер может просматривать заказы своего региона, если заказ создан более 24 часов назад». Casbin — популярная cross-language библиотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ определяется графом отношений: «пользователь X является участником команды Y, которая имеет доступ к проекту Z». OpenFGA — open source реализация от Okta.

Двухфакторная аутентификация

TOTP (Time-based One-Time Password, Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при подключении — base32-encoded secret, которого достаточно для воспроизведения кода при компрометации. Хранить secret в зашифрованном виде.

SMS-верификация — слабее TOTP из-за SIM-swapping атак и ненадёжности доставки SMS. Но пользователи активируют её охотнее. Email OTP — компромисс между безопасностью и UX.

WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Хранится private key на устройстве, публичный — на сервере. Нет пароля — нет его утечки. iOS 16+, Android 9+, все современные браузеры поддерживают. @simplewebauthn/server + @simplewebauthn/browser — хорошая библиотека для Node.js реализации.

Backup-коды при подключении 2FA: 10 одноразовых кодов для восстановления доступа если телефон потерян. Хранить хешированными (bcrypt), показывать только один раз при генерации.

Типичные уязвимости

Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 возвращает заказ без проверки, принадлежит ли он текущему пользователю. Самая распространённая уязвимость API по OWASP. Каждый запрос к ресурсу — проверка через $user->can('view', $order).

Mass Assignment: User::create($request->all()) — пользователь передаёт is_admin: true в теле запроса. Laravel решает через $fillable / $guarded, но часто забывают.

Небезопасный CORS: Access-Control-Allow-Origin: * на API с авторизацией по cookie — credentials не передаются с wildcard origin, но если кто-то сделал Allow-Credentials: true + Allow-Origin: * — это дыра.

Процесс работы

Архитектура авторизации проектируется до начала разработки, не добавляется потом. Выбор между сессиями и JWT, структура ролей и прав, flow для OAuth-провайдеров, план для 2FA. Penetration testing обязателен для продуктов с финансовыми данными или персональными данными пользователей.

Сроки

Базовая аутентификация (email/password + OAuth + JWT/сессии): 1–3 недели. RBAC с детальными политиками доступа: 2–4 недели. 2FA (TOTP + SMS): 1–2 недели. WebAuthn/Passkeys: 2–3 недели. Полная система аутентификации для SaaS с multi-tenancy: 4–8 недель.