Пользователь бросает регистрацию, если форма перегружена или валидация задерживается. По данным Baymard Institute, до 23% посетителей уходят из-за сложности формы. Каждое лишнее поле снижает конверсию на 4–8%. Мы проектируем формы, которые пользователь заполняет менее чем за 30 секунд. Для этого используем мгновенную клиентскую валидацию, минимальный набор полей (email + пароль) и кнопки OAuth, строго соответствующие гайдлайнам провайдеров.
Форма авторизации должна поддерживать вход по email и через социальные сети. Дизайн логина часто включает кнопки Google, Apple и GitHub. Дизайн формы регистрации должен быть минималистичным — только email и пароль.
Почему floating label экономит место, но создаёт проблемы?
Floating label (метка внутри поля, уплывающая при фокусе) популярен в мобильных интерфейсах. Он экономит вертикальное пространство, но плохо совместим с автозаполнением браузера: label и значение накладываются. Для большинства сайтов надёжнее статичный label сверху поля.
| Аспект |
Floating label |
Static label |
| Экономия места |
Да |
Нет |
| Совместимость с автозаполнением |
Проблемы |
Надёжно |
| Универсальность |
Требует анимации |
Работает на чистом CSS |
| Рекомендация |
Короткие формы на мобильных |
Большинство сайтов |
Как снизить трение при регистрации?
Минимизируйте количество полей: регистрация через email требует только email и пароль. Имя, телефон, день рождения собирайте после первого входа в onboarding-флоу. Если предусмотрен вход через Google, GitHub или Apple, кнопки должны строго соответствовать брендбукам. Google требует белый фон, логотип SVG и текст «Sign in with Google» без сокращений. Apple — чёрный или белый вариант, без цветных модификаций. Нарушение правил может привести к блокировке OAuth-приложения.
Какие состояния формы нужно проработать?
Дизайн охватывает не только пустую форму, но весь набор состояний:
- Placeholder и label (inline vs floating label)
- Focus-состояние с явным outline
- Ошибка валидации (inline, под полем, красный border) — появляется после потери фокуса, а не после отправки
- Успешное заполнение (зелёная галочка или нейтральный индикатор)
- Состояние загрузки кнопки (spinner + disabled)
- Успешное завершение (success screen или редирект)
Каждое состояние уменьшает когнитивную нагрузку: пользователь понимает, что происходит, без догадок.
Как мы проектируем форму: процесс работы
- Аналитика — изучаем контекст, аудиторию, сценарии. Фиксируем текущие проблемы.
- Проектирование — создаём wireframes, user flow, отмечаем все состояния.
- Дизайн — разрабатываем визуал, адаптив под desktop и mobile, прорабатываем анимации.
- Тестирование — проводим юзабилити-тесты и A/B-тестирование вариантов.
- Передача — готовим макеты Figma, спецификации, style guide и документацию.
Среднее время проектирования — от 1 до 3 рабочих дней. При хорошо спроектированной форме количество обращений в поддержку снижается на 20–30%.
Сравнение состояний поля
| Состояние |
Описание |
Визуальный cue |
| idle |
Поле пустое, label виден |
Серый border, label сверху или внутри |
| focus |
Пользователь кликнул |
Ярко-синий outline, label уходит вверх |
| typing |
Ввод данных |
Нет изменений, плавающая подсказка |
| error |
Невалидный ввод |
Красный border, сообщение под полем |
| success |
Данные корректны |
Зелёная галочка или зелёный border |
| loading |
Кнопка отправки загружается |
Spinner, кнопка disabled |
| completed |
Успешная авторизация |
Верный экран или редирект |
Что включает двухфакторная аутентификация?
При проектировании форм стоит учитывать двухфакторную аутентификацию. Она добавляет шаг ввода кода из SMS или TOTP-приложения. Дизайн должен предусматривать отдельное поле для кода, таймер повторной отправки и обработку ошибок. Это повышает безопасность без значительного ухудшения юзабилити при правильной реализации.
Проектирование UX регистрации включает анализ пользовательского пути и устранение точек трения. Мы используем данные A/B-тестов для выбора оптимального расположения полей и кнопок.
Пример из практики: для интернет-магазина с 10 000 ежедневных посетителей замена стандартной формы на оптимизированную с OAuth и мгновенной валидацией увеличила конверсию регистрации на 18% за месяц.
Что входит в результат
- Макеты Figma для desktop и mobile (до 10 экранов)
- Набор всех состояний для каждого элемента
- Style guide полей, кнопок, иконок
- Документация по взаимодействию (ошибки, анимации)
- Обучение команды (по запросу)
- Поддержка на этапе вёрстки
Гарантируем учёт всех состояний и соответствие современным стандартам accessibility. Опыт проектирования форм для более чем 30 проектов.
Свяжитесь с нами, чтобы получить консультацию по проектированию форм. Закажите проектирование формы — мы учтём все состояния и проведём A/B-тестирование.
Аутентификация и авторизация: 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 недель.
