Custom Authentication and Registration Module for 1C-Bitrix

We are a team with over 10 years of experience in Bitrix development, having completed more than 50 projects on authentication customization. We often encounter requests that go beyond the standard bitrix:system.auth.form component. Business requires phone number authentication with OTP, login via Gosuslugi (ESIA), two-factor authentication, single sign-on for multiple sites (SSO), custom registration fields with verification. The cost of developing an authentication module depends on the feature set, but you can always get a free project assessment. We implement the module in 1–10 weeks. Want to know more? Contact us for a consultation.

Why the Standard Authentication Component Is Insufficient

The standard component handles basic tasks but does not support OTP authentication, ESIA integration, flexible 2FA, or SSO. Real projects need custom scenarios: legal entity registration with INN verification, soft social network binding, login attempt quotas. Developing your own module gives full control over logic and security. Savings on license fees when using a custom module can reach 50% per year.

How Authentication Works in Bitrix

Bitrix provides several extension points for the authentication system. One-time password (OTP) is a key mechanism for phone number confirmation.

Social authentication is implemented via the socialservices module. Providers are extended through a class inheriting \Bitrix\SocialServices\Base. For non-standard providers (Telegram, Gosuslugi), a custom class is created. See Bitrix documentation on social services for details.

Token/API-key authentication — via the OnBeforeUserLogin event handler or middleware in OnPageStart.

Event model: key events for extending authentication:

• OnBeforeUserLogin — before login (can block)
• OnAfterUserLogin — after successful login
• OnUserLoginAttempt — for each attempt (logging, rate limiting)
• OnBeforeUserRegister — before registration
• OnAfterUserRegister — after successful registration

How to Implement Phone Number Authentication with OTP

The most common request. Workflow:

1. User enters phone number.
2. Server generates OTP code (6 digits), saves in session or cache with TTL 5 minutes.
3. Sends SMS via provider (SBOL, Infobip, SMS.ru).
4. User enters code.
5. Server verifies code, finds user by field UF_PHONE or PERSONAL_PHONE, logs in via CUser::Authorize($userId).

// OTP verification and authorization public function verifyOtp(string $phone, string $code): bool { $session = Application::getInstance()->getSession(); $stored = $session->get('otp_' . md5($phone)); if (!$stored || $stored['code'] !== $code || $stored['expires'] < time()) { return false; } $session->delete('otp_' . md5($phone)); // Find user by phone $user = UserTable::getRow([ 'filter' => ['=PERSONAL_PHONE' => $phone, '=ACTIVE' => 'Y'], 'select' => ['ID'], ]); if ($user) { CUser::Authorize($user['ID']); return true; } // Auto-register if needed return $this->autoRegister($phone); } 

Integration with Gosuslugi (ESIA)

Authentication via Gosuslugi uses ESIA (Unified Identification and Authentication System) with OAuth 2.0 + OpenID Connect protocol. Features:

• Requires registration of the information system in the Ministry of Digital Development registry.
• Requires PKCS#7/GOST-R signature of requests (Cryptopro or OpenSSL with Russian algorithms).
• ESIA test environment is available at a separate URL.

The integration is implemented as an authentication provider inheriting \Bitrix\SocialServices\Base or as a separate handler with redirect URI.

Single Sign-On (SSO) for Multiple Sites

In a multisite configuration, Bitrix supports SSO through the "Session Storage" mechanism. For sites on different domains, it is implemented via:

• Common second-level domain (.example.ru) with cookies on that domain.
• OAuth2 server on the main site + clients on child sites.
• JWT tokens in URL parameters for cross-domain transition.

Two-Factor Authentication (2FA)

Time-based One-time Password (TOTP) — standard algorithm compatible with Google Authenticator, Yandex.Key. 2FA is implemented via the OnAfterUserLogin handler:

public static function onAfterUserLogin(array &$params): void { $userId = $params['USER_ID']; if (self::is2FAEnabled($userId)) { // Save flag "2FA required" in session $session = Application::getInstance()->getSession(); $session->set('2fa_required', true); $session->set('2fa_user_id', $userId); // Log out current session and redirect to code input page CUser::Logout(); LocalRedirect('/auth/2fa/'); } } 

Custom Registration Fields

Registration form fields are extended via user fields UF_* of the user module. Specific tasks:

• INN/OGRN verification for legal entity registration — via the Federal Tax Service API or dadata.ru.
• Email confirmation via unique link — standard Bitrix mechanism plus email customization.
• Document upload during registration — via UF_ fields of file type with moderation.

Authentication Method Comparison

Custom OTP authentication reduces server load by 3 times compared to constant redirection to external services. A custom module is 2–3 times faster for specific scenarios than the standard solution.

Typical Development Timelines

The module is tested for compliance with security requirements: brute force protection (rate limiting), CSRF protection, proper session termination, token storage in hashed form.

What You Get as a Result

• A fully functional authentication and registration module ready for use.
• Commented source code.
• Installation and configuration documentation.
• Administrator instructions for the site.
• 30-day support guarantee from the date of delivery.

Contact us for a project assessment — we will offer the optimal solution for your tasks. Request the development of an authentication module and get a consultation.