Аутентификация и авторизация

01Сессии или токены

После входа сервер должен узнать вас при следующем запросе. С сессиями сервер хранит состояние входа (в Redis или базе данных) и выдаёт браузеру случайный id сессии в cookie — как номерок в гардеробе. Сам по себе номерок ничего не значит; сервер ищет по нему запись. Выход из системы — это просто: удалить сессию. С токенами сервер выдаёт клиенту подписанный токен, который сам содержит claims — например, id пользователя и срок действия, — и сервер проверяет подпись вместо поиска. Сессии — лучший вариант по умолчанию для сайтов на вашем собственном домене. Токены подходят мобильным приложениям, сторонним клиентам и вызовам между сервисами. Многие продукты используют и то, и другое.

• Сессионная cookie: HttpOnly, Secure, SameSite=Lax (или Strict), короткий таймаут бездействия.
• Перегенерируйте id сессии при входе, чтобы предотвратить session fixation.
• Cookies требуют защиты от CSRF; bearer-токены в заголовках требуют защиты от XSS.

02JWT: access-токены, refresh-токены и отзыв

JWT (JSON Web Token) состоит из трёх частей: заголовка, payload с claims и подписи. Payload может прочитать кто угодно, поэтому никогда не кладите туда секреты; подпись лишь доказывает, что токен не изменяли. Для вызовов API используйте короткоживущий access-токен (5–15 минут), а для получения новых access-токенов — долгоживущий refresh-токен, который хранится безопасно. Ротируйте refresh-токены: каждое использование выдаёт новый и аннулирует старый. Если старый refresh-токен когда-нибудь используют снова, считайте, что его украли, и отзывайте всё семейство токенов. Поскольку JWT действителен до истечения срока, отзыв требует дополнительной работы: denylist id токенов (jti) в Redis, версия токена у пользователя или повторная проверка пользователя на каждом запросе. Когда токены проверяют несколько сервисов, предпочитайте асимметричную подпись (RS256 или EdDSA) и всегда проверяйте alg, iss, aud и exp.

1// Verify an access token (jose library)
2import { jwtVerify, createRemoteJWKSet } from 'jose';
3 
4const jwks = createRemoteJWKSet(new URL('https://auth.example.com/.well-known/jwks.json'));
5 
6export async function verifyAccessToken(token: string) {
7  const { payload } = await jwtVerify(token, jwks, {
8    issuer: 'https://auth.example.com',
9    audience: 'api.example.com',
10    algorithms: ['RS256'],
11  });
12  if (await denylist.has(payload.jti as string)) throw new Error('Token revoked');
13  return payload;
14}

03OAuth2, OpenID Connect и вход через соцсети

OAuth2 — стандарт делегированного доступа: пользователь позволяет приложению действовать от его имени, не отдавая ему пароль. OpenID Connect (OIDC) — слой поверх него, который добавляет идентичность: ID-токен, сообщающий, кто пользователь. «Войти через Google» или «Войти через Apple» — это OIDC. Для веб- и мобильных приложений используйте Authorization Code flow с PKCE (Proof Key for Code Exchange), который защищает код от перехвата; старый Implicit flow устарел. Всегда проверяйте параметр state против CSRF, проверяйте подпись ID-токена, issuer, audience и nonce и связывайте аккаунты соцсетей по стабильному subject id провайдера, а не только по email. iOS-приложения, которые предлагают сторонний вход через соцсети, обязаны предлагать и вариант с упором на приватность, например Sign in with Apple (правило App Store 4.8).

04Пароли, OTP и 2FA

Никогда не храните пароли — храните хэши. Используйте Argon2id (минимум по OWASP: 19 MiB памяти, 2 итерации, параллелизм 1) или bcrypt с cost 10 и выше; учтите, что bcrypt использует только первые 72 байта. Фреймворки делают это за вас: фасад Hash в Laravel или пакет argon2 в Node. Проверяйте новые пароли по спискам известных утечек и ограничивайте частоту попыток входа. Одноразовые пароли по SMS или email удобны на рынках, где всё завязано на телефон: генерируйте случайный 6-значный код, храните только его хэш с коротким сроком действия (около 5 минут), разрешайте несколько попыток и ограничивайте отправки на номер и на IP, чтобы не допустить злоупотребления стоимостью SMS. Двухфакторная аутентификация добавляет второе подтверждение: TOTP-приложения, passkeys (WebAuthn) или SMS как более слабый запасной вариант. Требуйте 2FA для персонала и администраторов.

1// Laravel: OTP verification with rate limiting
2$key = 'otp:'.$request->phone;
3if (RateLimiter::tooManyAttempts($key, 5)) {
4    abort(429, 'Too many attempts, try again later.');
5}
6RateLimiter::hit($key, 600);
7 
8$otp = OtpCode::where('phone', $request->phone)
9    ->where('expires_at', '>', now())
10    ->latest()->first();
11 
12if (! $otp || ! Hash::check($request->code, $otp->code_hash)) {
13    throw ValidationException::withMessages(['code' => 'Invalid or expired code.']);
14}
15$otp->delete();
16RateLimiter::clear($key);

05Роли, права и API-ключи

RBAC (role-based access control, управление доступом на основе ролей) назначает пользователям роли (owner, manager, cashier), а роли несут права (orders.refund, menu.edit). В коде проверяйте права, а не названия ролей: «может делать возврат» переживёт появление новых ролей, а «является менеджером» — нет. Держите проверки на сервере в одном месте, например в политиках и гейтах Laravel или в guards NestJS, а скрытие кнопок в UI используйте только для удобства. В мультитенантных приложениях каждая проверка учитывает и тенанта: менеджер компании A не имеет прав в компании B. Для машинных клиентов выдавайте API-ключи со scope: генерируйте длинный случайный ключ, показывайте его один раз, храните только хэш, добавляйте видимый префикс для идентификации (например, live_ или test_) и поддерживайте истечение срока, ротацию и лимиты запросов на ключ. Логируйте, кто каким ключом пользовался.

06Чек-лист безопасных настроек по умолчанию

Большинство багов авторизации — в деталях. Ставьте cookies с HttpOnly, чтобы JavaScript не мог их прочитать, Secure, чтобы они передавались только по HTTPS, SameSite=Lax или Strict против CSRF и узким Path. По возможности используйте префикс __Host- для сессионных cookies. Возвращайте одну и ту же ошибку для «неизвестного пользователя» и «неверного пароля», чтобы нельзя было перебирать аккаунты. Ограничивайте частоту входа, OTP и сброса пароля. Делайте ссылки для сброса одноразовыми и короткоживущими. Логируйте события безопасности (входы, неудачные попытки, смену ролей, имперсонацию) и настройте алерты на всплески. Имперсонацию для поддержки ограничивайте по времени, требуйте указать причину и записывайте в аудит.

1Set-Cookie: __Host-session=9f8c...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200

07Где живут токены: браузеры, паттерн BFF и хранилище на мобильных

Любой токен, который может прочитать JavaScript, может украсть XSS-баг. Поэтому хранить access и refresh токены в localStorage для одностраничного приложения рискованно. Паттерн Backend-for-Frontend (BFF) полностью убирает токены из браузера: тонкий сервер на вашем домене выполняет OAuth-поток, хранит токены на сервере и отдаёт браузеру только сессионную cookie с HttpOnly, Secure и SameSite. Вызовы API идут через BFF, который прикрепляет access token. На мобильных нет хранилища cookie, на которое можно опереться, поэтому храните refresh токены в защищённом хранилище платформы — Keychain на iOS и хранилище на базе Keystore на Android, — а не в обычных preferences. OAuth 2.0 Security Best Current Practice (RFC 9700, январь 2025) также рекомендует по возможности токены с привязкой к отправителю, например DPoP (RFC 9449), который связывает токен с ключом клиента, так что украденный токен сам по себе бесполезен.

• SPA на вашем собственном домене: сессионная cookie или BFF, а не localStorage.
• Мобильные: защищённое хранилище плюс ротация refresh токенов с привязкой к устройству.
• Сервис–сервис: client credentials или mTLS, короткоживущие токены.

08Passkeys и WebAuthn изнутри

Passkey — это пара ключей, которую устройство пользователя создаёт для одного сайта. Приватный ключ никогда не покидает устройство или менеджер паролей пользователя; сервер хранит только публичный ключ. Для входа сервер отправляет случайный challenge, устройство запрашивает отпечаток, лицо или PIN и подписывает challenge. Сервер проверяет подпись сохранённым публичным ключом. Принципиально важно, что браузер включает origin в подписываемые данные, поэтому поддельный сайт на похожем домене не получит действительную подпись: passkeys устойчивы к фишингу так, как SMS-коды и TOTP — нет. Ваш сайт — это relying party, идентифицируемая RP ID, например example.com. Используйте поддерживаемую библиотеку на обеих сторонах, сохраняйте хотя бы один путь восстановления и позволяйте пользователям регистрировать несколько passkeys.

1// Browser, using @simplewebauthn/browser
2import { startAuthentication } from '@simplewebauthn/browser';
3 
4const optionsJSON = await api.post('/webauthn/login/options'); // fresh, single-use challenge
5const assertion = await startAuthentication({ optionsJSON });
6await api.post('/webauthn/login/verify', assertion);
7 
8// Server (@simplewebauthn/server verifyAuthenticationResponse) must check:
9// expected challenge, expected origin and RP ID, the signature against the
10// stored public key, and user verification if your policy requires it.

09Атаки по времени, перебор аккаунтов и credential stuffing

Атакующие учатся на мельчайших различиях. Если «неизвестный email» возвращается за 5 мс, а «неверный пароль» за 80 мс, потому что хэш выполняется только во втором случае, они могут составить список существующих аккаунтов. Выполняйте фиктивный хэш для неизвестных пользователей и возвращайте одно и то же сообщение. Сравнивайте секреты — API-ключи, токены сброса и подписи webhook — функциями с постоянным временем, hash_equals в PHP или crypto.timingSafeEqual в Node, и никогда через ===. Credential stuffing — перебор утёкших с других сайтов пар email и пароля — самая частая атака на формы входа. Защищайтесь слоями: rate limits на аккаунт и на IP, проверка по утёкшим паролям (range API Have I Been Pwned использует k-анонимность, так что вы отправляете только первые пять символов SHA-1 хэша), CAPTCHA после подозрительных паттернов и алерты на всплески неудачных входов. Жёсткие блокировки аккаунта можно использовать, чтобы заблокировать реальных пользователей, поэтому лучше прогрессивные задержки.

1import { createHmac, timingSafeEqual } from 'node:crypto';
2 
3export function isValidSignature(rawBody: Buffer, headerHex: string, secret: string) {
4  const expected = createHmac('sha256', secret).update(rawBody).digest();
5  const received = Buffer.from(headerHex, 'hex');
6  // timingSafeEqual throws on different lengths, so check that first
7  return received.length === expected.length && timingSafeEqual(received, expected);
8}

10Авторизация за пределами ролей: ABAC, ReBAC и фильтрация списков

Роли отвечают на вопрос «что это за пользователь?», но реальные правила часто зависят от большего. Attribute-based access control (ABAC) добавляет условия: менеджер может вернуть деньги только за заказы своего филиала и только до определённого лимита. Relationship-based access control (ReBAC), популяризированный статьёй Google о Zanzibar и реализованный в OpenFGA и SpiceDB, моделирует права как граф: пользователь может редактировать документ, потому что состоит в команде, которой принадлежит его папка. Движки политик вроде OPA или Cedar держат правила вне кода. Самое сложное — списки: проверка каждой строки после загрузки ломает пагинацию и раскрывает количества. Вместо этого встраивайте авторизацию в запрос как scope, добавляющий условия по тенанту, филиалу или владельцу, чтобы база возвращала только строки, которые пользователю разрешено видеть. Тестируйте оба направления: разрешённые пользователи видят данные, все остальные получают 404.