Development of an authorization and registration module for 1C-Bitrix

Authentication and Registration Module Development for 1C-Bitrix

The standard bitrix:system.auth.form component covers most use cases, but businesses regularly arrive with requirements that go beyond its scope: phone number login with OTP, authentication via government identity providers, multi-factor authentication, single sign-on for multiple sites, custom registration fields with verification. A custom authentication module is the answer to these requirements.

How Authentication Works in Bitrix

Bitrix provides several extension points for the authentication system:

Social authentication is implemented via the socialservices module. Providers are extended by a class inheriting \Bitrix\SocialServices\Base. For non-standard providers (Telegram, government portals) a custom class is created.

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

Event model: key events for extending authentication:

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

Phone Number Login with OTP

The most frequent request. How it works:

1. User enters their phone number
2. Server generates an OTP code (6 digits), stores it in session or cache with a 5-minute TTL
3. Sends SMS via a provider (Infobip, SMS.ru, Twilio)
4. User enters the code
5. Server verifies the code, finds the user by UF_PHONE or PERSONAL_PHONE, logs in via CUser::Authorize($userId)

// OTP verification and login
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 number
    $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);
}

Government Identity Provider Integration (ESIA)

Authentication via government portals uses ESIA (Unified Identification and Authentication System) with the OAuth 2.0 + OpenID Connect protocol. Specifics:

• Requires registration of the information system in the Ministry of Digital Development registry
• Requires PKCS#7/GOST-R request signing (cryptographic library CryptoPro or OpenSSL with Russian algorithms)
• The ESIA test environment is accessible at a separate URL

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

Single Sign-On (SSO) for Multiple Sites

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

• A shared second-level domain (.example.com) with a domain-wide cookie
• An OAuth2 server on the primary site + clients on sub-sites
• JWT tokens in URL parameters for cross-domain transitions

Two-Factor Authentication (2FA)

2FA is implemented via the OnAfterUserLogin handler:

public static function onAfterUserLogin(array &$params): void
{
    $userId = $params['USER_ID'];

    if (self::is2FAEnabled($userId)) {
        // Store "2FA required" flag in session
        $session = Application::getInstance()->getSession();
        $session->set('2fa_required', true);
        $session->set('2fa_user_id', $userId);

        // Log out of the current session and redirect to code entry page
        CUser::Logout();
        LocalRedirect('/auth/2fa/');
    }
}

TOTP (Time-based One-Time Password per RFC 6238) — the standard algorithm for compatibility with Google Authenticator and similar apps.

Custom Registration Fields

Registration form fields are extended via UF_* user fields on the user module. Specific use cases:

• Verification of tax IDs (INN/OGRN) at legal entity registration — via tax authority API or dadata.ru
• Email confirmation via unique link — standard Bitrix mechanism + custom email template
• Document upload at registration — via UF_ file-type fields with moderation

Typical Development Timelines

The module is tested against security requirements: brute-force protection (rate limiting), CSRF protection, correct session termination, and hashed token storage.