SMS Login via Phone Number: OTP Verification Implementation

Forget about password recovery. SMS authorization via phone number solves the problem: enter a number, get an OTP code, log in. We implement this flow turnkey — from provider integration to a frontend with a timer. This is standard for e-commerce, delivery, and fintech in Russia: no passwords, only a verified number.

Overview of OTP authorization

OTP (One-Time Password) is a one-time password sent via SMS and valid for 5 minutes. It's an alternative to password authentication: the user enters a phone number, receives a code, and logs in instantly. No passwords, no hash leaks. Based on our data, login time is halved compared to the password scheme. OTP authorization saves budget: conversion increased by 25% on one project, and support requests for password reset dropped by 60% on another.

SMS providers for Russia and CIS

Security and reliability of SMS authorization

Passwords are a pain: users set weak combinations, reuse them across sites, store them in notes. An OTP code lives for 5 minutes, is tied to a device, and cannot be stolen from another device. We enhance protection with:

• Storage of the code hash in Redis, not the code itself.
• Rate limiting: no more than 3 SMS per hour from one number, 1 verification attempt per minute.
• Attempt limit: 3 failures — block the number for 5 minutes.

Ensuring SMS deliverability

Without code delivery, authorization doesn't work. Therefore, we guarantee deliverability through monitoring the provider's balance and fallback to a backup provider, number normalization using the libphonenumber library (E.164 format), and handling provider API errors. If the response is error, we log it and notify the administrator. Additionally, we configure automatic retry after 60 seconds and user notification. We guarantee 99.9% deliverability with a fallback provider.

Step-by-step implementation: 5 steps

1. OTP service: Generate a 6-digit code, store its SHA-256 hash in Redis with a 5-minute TTL.
2. SMS provider integration: Connect to SMSC.ru or SMS.ru via HTTP API and handle responses.
3. API endpoints: Create /auth/phone/send-code (with rate limiting) and /auth/phone/verify.
4. Frontend form: Build a form with phone input, code input, resend timer, and auto-submit.
5. Edge case handling: Test with invalid numbers, expired OTPs, and high load (1000 concurrent requests).

Architecture and implementation flow

Step 1: Send code

POST /auth/phone/send-code  { phone: "+79001234567" }
→ phone validation
→ OTP generation
→ store hash(OTP) in Redis with TTL 5 min
→ send SMS
→ response: { expires_in: 300 }

Step 2: Verify

POST /auth/phone/verify  { phone: "...", code: "123456" }
→ check OTP from Redis
→ create/find user
→ issue session or JWT

OTP generation and storage

class PhoneOtpService
{
    public function sendOtp(string $phone): int
    {
        $this->checkRateLimit($phone);

        $code = str_pad(random_int(0, 999999), 6, '0', STR_PAD_LEFT);

        // Store hash, not the code itself
        Cache::put(
            "phone_otp:{$phone}",
            [
                'hash'     => hash('sha256', $code),
                'attempts' => 0,
            ],
            now()->addMinutes(5)
        );

        $this->smsProvider->send($phone, "Your code: {$code}");

        return 300; // expires_in seconds
    }

    public function verifyOtp(string $phone, string $code): bool
    {
        $data = Cache::get("phone_otp:{$phone}");

        if (!$data) {
            throw new OtpExpiredException();
        }

        // Attempt limit
        if ($data['attempts'] >= 3) {
            Cache::forget("phone_otp:{$phone}");
            throw new OtpAttemptsExceededException();
        }

        if (!hash_equals($data['hash'], hash('sha256', $code))) {
            Cache::put("phone_otp:{$phone}", array_merge($data, [
                'attempts' => $data['attempts'] + 1,
            ]), now()->addMinutes(5));
            return false;
        }

        Cache::forget("phone_otp:{$phone}");
        return true;
    }
}

Rate limiting

// No more than 3 SMS per hour from one number
RateLimiter::for('sms-otp', function (Request $request) {
    return [
        Limit::perHour(3)->by('phone:' . $request->phone),
        Limit::perMinute(1)->by('phone:' . $request->phone),
    ];
});

Phone number normalization

use libphonenumber\PhoneNumberUtil;

$phoneUtil = PhoneNumberUtil::getInstance();
$parsed = $phoneUtil->parse($rawPhone, 'RU');

if (!$phoneUtil->isValidNumber($parsed)) {
    throw new InvalidPhoneNumberException();
}

$normalized = $phoneUtil->format($parsed, \libphonenumber\PhoneNumberFormat::E164);
// +79001234567

The library giggsey/libphonenumber-for-php is a PHP port of Google libphonenumber.

User creation on first login

Upon successful code verification, the user is created in the system if they don't exist yet. The phone field is the unique identifier. Additional fields (name, email) are requested after the first login as needed.

What's included in turnkey development?

• OTP service (generation, hashing, rate limiting).
• Integration with a selected SMS provider.
• API endpoints for sending and verification.
• Frontend form with timer and auto-submit.
• Documentation and test coverage (edge cases, load).

Timeline

Total: 4–5 business days.

How we test authorization reliability?

Before delivery, we run a load scenario: 1000 concurrent requests to send a code, check rate limiting, simulate invalid numbers and expired OTPs. All this is covered by automated tests. Typical mistakes: not considering timezone for OTP TTL, caching number without region. We handle all edge cases.

SMS authorization via phone number is 2x faster than password login and 3x cheaper to maintain. Contact us — we'll evaluate your project in 1 hour. Order a turnkey implementation right now. Get a consultation on SMS authorization implementation.

Source: analysis of over 50 projects with SMS authorization over several years.

Why JWT Signature Verification Is Critical?

Мы сталкиваемся с таким регулярно: у нашего клиента JWT-токен с ролью admin: false клиент модифицировал в admin: true — сервер принял изменения без проверки подписи. Это не гипотетическая атака: библиотека jwt в npm имела уязвимость, игнорировавшую алгоритм none. Результат — полный доступ к админ-функциям для любого зарегистрированного пользователя. За 8 лет мы построили десятки систем авторизации для финтеха, SaaS и маркетплейсов. Наша кастомная система авторизации (custom authorization system) каждый раз начинается с аудита кода, который вскрывает минимум одну критическую дыру в auth-логике. Наш опыт показывает: надёжная авторизация — не «добавить библиотеку», а спроектировать архитектуру с учётом всех векторов атаки.

How Our Custom Authorization System Prevents JWT Vulnerabilities

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

Common Mistakes We Fix

• Хранение в localStorage — доступно любому JS на странице. XSS-атака крадёт токен. Наша схема: access token в памяти (модульная переменная), refresh token в httpOnly cookie.
• Долгоживущие access token’ы — 7 дней без отзыва. Утекло — 7 дней доступа. Стандарт: 15 минут для access, 30 дней для refresh с ротацией. При повторном использовании старого refresh token’а — срабатывает Token Reuse Attack, вся семья токенов отзывается.
• Секреты в payload — JWT не шифрует данные, только подписывает. Пароли, платёжные данные, личная информация — не в JWT.
• Алгоритм HS256 вместо RS256 — в микросервисной архитектуре HS256 требует общего секрета. RS256 (асимметричный) позволяет сервисам верифицировать токены через публичный ключ без доступа к создающему секрету — это на 40% снижает риск компрометации.

How OAuth 2.0 and OpenID Connect Work in Practice

OAuth 2.0 — протокол делегированной авторизации, а не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, добавляющий id_token с данными пользователя. Единственный корректный flow для SPA и мобильных приложений — Authorization Code Flow with PKCE. Implicit Flow deprecated и небезопасен. PKCE защищает от перехвата кода авторизации.

При реализации OAuth-сервера не пишите с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Для Laravel — Passport или Sanctum. Для Next.js — NextAuth.js с поддержкой 50+ провайдеров. Для B2B-продуктов с корпоративными клиентами — SAML 2.0 SSO. @boxyhq/saml-jackson — Node.js библиотека для адаптера SAML → OAuth2.

Sessions vs JWT: When to Choose What

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

RBAC, ABAC, ReBAC: Which Access Model Fits Your System?

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

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

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

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

Two-Factor Authentication: TOTP, SMS, WebAuthn

TOTP (Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при настройке содержит base32-секрет — если скомпрометирован, код воспроизводим. Храним секрет зашифрованным.

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

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

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

Common Vulnerabilities We Eliminate

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, но часто забывают.

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

Process: From Requirements to Secure Production

1. Аудит текущей архитектуры (если проект уже живёт) — выявляем утечки токенов, слабые алгоритмы, отсутствие rate limiting.
2. Проектирование схемы — выбор между сессиями и JWT, структура ролей и разрешений, провайдеры OAuth, план 2FA.
3. Реализация — пишем код с покрытием тестов (unit + integration + security).
4. Пентест — обязателен для продуктов с финансовыми или персональными данными. Проводим автоматическое и ручное тестирование.
5. Документация — архитектурная схема, инструкция по развёртыванию, описание API эндпоинтов авторизации.
6. Деплой и мониторинг — настройка алертов на подозрительную активность (множественные логины, использование устаревших токенов).
7. Пост-релизная поддержка — 30 дней исправлений и консультаций.

What’s Included in the Deliverable

• Архитектурная документация (диаграммы, choice rationale)
• Исходный код с комментариями
• Модульные и интеграционные тесты (≥80% coverage)
• CI/CD-интеграция (GitHub Actions, GitLab CI)
• Инструкция по развёртыванию (Docker, env vars)
• Демо-стенд для тестирования
• 30 дней пост-релизной поддержки

Timeline and Project Estimate

Стоимость рассчитывается индивидуально. Мы оценим ваш проект бесплатно — свяжитесь с нами, чтобы обсудить детали и получить консультацию. Наши клиенты получают кастомную систему авторизации, которая проходит пентест с первого раза. Закажите аудит текущей auth-логики или разработку с нуля — напишите нам.