Запрет авторизации через иностранные сервисы: что делать бизнесу

Что происходит

С 7 июля 2026 года вступает в силу Федеральный закон от 26.06.2026 № 199-ФЗ, который вводит в КоАП РФ статью 13.55 и впервые закрепляет реальные штрафы за нарушение правил авторизации пользователей на российских сайтах, в приложениях и информационных системах.

Само требование проводить авторизацию пользователей из РФ только разрешёнными способами действует ещё с 1 декабря 2023 года — это поправки в 149-ФЗ «Об информации…». Но без санкционной нормы оно носило скорее декларативный характер. Теперь за неисполнение введена административная ответственность, а контролировать соблюдение будет Роскомнадзор.

На практике это значит, что привычные кнопки «Войти через Google», «Sign in with Apple» и вход через аккаунты зарубежных соцсетей на ресурсах, доступных пользователям из России, становятся прямой путь к штрафу. Разберёмся, кого конкретно это касается, что именно запрещено и какие есть технические пути решения.

Кого касается новый закон

Закон адресован владельцам ресурсов, а не конечным пользователям. Ответственность несут:

• владельцы сайтов и страниц в интернете;
• владельцы информационных систем;
• владельцы программ для ЭВМ (мобильных и десктопных приложений), работающих на территории РФ.

Обычных пользователей штрафы не касаются — закон не запрещает им использовать иностранные аккаунты. Бремя ответственности полностью лежит на стороне ресурса.

Важный нюанс: обязанность проводить авторизацию разрешёнными способами возникает только тогда, когда доступ к информации предоставляется после авторизации. Если сайт или приложение отдаёт контент свободно, без обязательной регистрации, — требование на него не распространяется. Под риском находятся те, кто закрывает часть функционала за логином, но при этом предлагает только иностранные способы входа.

Что именно запрещено

Закон запрещает не любую связь с иностранными сервисами, а конкретно авторизацию через иностранные OAuth-провайдеры. Это важно понимать, чтобы не выбросить работающий функционал.

Коротко: что такое OAuth и делегированная авторизация

Делегированная авторизация — схема, при которой пользователь разрешает одному приложению получить доступ к своим данным или идентичности в другом сервисе, не сообщая ему пароль. OAuth 2.0 — открытый протокол, реализующий эту схему и ставший стандартом де-факто в интернете.

Когда пользователь жмёт «Войти через Google», происходит примерно следующее:

1. Приложение перенаправляет его на страницу Google.
2. Пользователь входит там и подтверждает согласие.
3. Google возвращает приложению access-token — временный «пропуск», удостоверяющий личность пользователя и права приложения.
4. Приложение использует токен, чтобы получить данные аккаунта (email, имя) и открыть сессию у себя.

Пользователю не нужно создавать и помнить новый пароль для каждого сайта, а приложению — самостоятельно проверять учётные данные: это делает доверенный IdP. Именно эту модель и регулирует закон: если доверенный IdP иностранный, использовать его для российских пользователей нельзя.

Запрещается:

• кнопки «Войти через Google», «Sign in with Apple ID» и аналогичные;
• OAuth-вход через аккаунты в иностранных социальных сетях (Facebook, X и т. п.);
• авторизация через зарубежные облачные IdP (Microsoft / Entra ID, Auth0, Cognito, Firebase Auth и др.), если провайдер не соответствует критериям российского контроля;
• передачу российских пользовательских учётных данных иностранным лицам в целях аутентификации.

Не запрещено использовать адрес иностранной почты как логин в паре «логин-пароль» — при условии, что сама аутентификация выполняется вашей российской системой, а не через OAuth иностранного сервиса. То есть поле email со значением user@gmail.com допустимо, а вот кнопка «Войти через Google», по которой Google подтверждает личность пользователя, — нет.

Разрешённые способы авторизации

Для пользователей, находящихся на территории России, владелец ресурса обязан предоставить как минимум один из способов входа:

1. По номеру мобильного телефона — с подтверждением через SMS или push в приложение оператора.
2. Через ЕСИА («Госуслуги») — единую систему идентификации и аутентификации.
3. Через Единую биометрическую систему (ЕБС).
4. С помощью иных российских информационных систем, владельцем которых является гражданин РФ или российское юрлицо, находящееся под российским контролем более чем на 50 %.

Четвёртый пункт фактически легализует весь пласт российских IdP: self-hosted Keycloak на вашем сервере, корпоративные Яндекс ID, VK ID, Сбер ID, Тинькофф ID и другие — всё это разрешено при условии надлежащего контроля.

Ответственность и штрафы

С 7 июля 2026 года статья 13.55 КоАП РФ предусматривает следующие размеры штрафов:

Для юридических лиц санкции сопоставимы с расходами на полноценное внедрение корпоративной системы авторизации. Проще и дешевле один раз привести инфраструктуру в соответствие, чем попадать под повторные нарушения: их фиксация автоматически увеличивает штраф в два раза.

Стратегии приведения систем в соответствие

Технически способов уйти от иностранных OAuth-провайдеров три, и они не взаимоисключают друг друга:

1. Самостоятельная реализация логики регистрации и входа в продукте.
2. Self-hosted Identity Provider (IdP) — развёртывание готовой системы вроде Keycloak, Authentik или Zitadel на собственной инфраструктуре.
3. Российские сервисы авторизации — интеграция с Яндекс ID, VK ID, Сбер ID, ЕСИА как с внешними поставщиками идентичности.

На практике зрелые решения почти всегда получаются гибридными: ядром выступает собственный IdP (часто Keycloak), а внешние российские сервисы подключаются к нему как федеративные источники. Ниже разберём каждый вариант отдельно, а затем сведём их в сравнительную таблицу.

Вариант 1. Самостоятельная реализация

Подход, при котором команда пишет логику регистрации, входа, восстановления пароля и управления сессиями внутри самого продукта — на базе фреймворка (Laravel, Django, Spring Security, NestJS) или совсем «с нуля».

Что нужно предусмотреть:

• хранение учётных данных и использование защищенных методов хранения паролей;
• подтверждение почтового адреса
• система уведомления пользователя о событиях
• подтверждение номера телефона через SMS-шлюз российского оператора или агрегатора (SMS Aero, Devino, SMS-центр и т. п.);
• сброс пароля с токенами одноразового действия и коротким TTL;
• защиту от перебора паролей и учетных данных (rate-limit, капча, блокировка после N попыток);
• управление сессиями: httponly + secure cookies, JWT с коротким TTL и refresh-токенами в БД;
• двухфакторную аутентификацию (TOTP, SMS, push);
• множество видов атак, список которых пополняется постоянно;
• журналирование входов и аномалий.

Преимущества:

• Максимальный контроль. Никаких внешних зависимостей, все данные остаются внутри продукта.
• Минимальная инфраструктурная сложность. Не нужно поднимать отдельный сервис, разбираться с OIDC/SAML и синхронизировать пользователей.
• Отсутствие лицензионных платежей. Только расходы на SMS и хостинг.
• Гибкая интеграция. Вся реализация зависит только от ваших разработчиков.

Недостатки:

• Высокая нагрузка на команду. Безопасная реализация аутентификации — нетривиальная задача; ошибки здесь стоят дороже всего.
• Высокая стоимость разработки. Создание полноценной системы авторизации занимает ни один месяц и несёт за собой множество расходов на проектирование, разработку и безопасность.
• Дублирование функционала, который в готовых IdP работает «из коробки»: SSO, MFA, федерация, аудит, адаптивные политики.
• Долгая доработка. Появление новых требований (например, биометрия или интеграция с ЕСИА) каждый раз означает отдельный проект.
• Ответственность за уязвимости полностью на вас. Никакого сообщества и регулярных патчей от вендора. Найти сотрудников, которые хорошо разбираются в безопасности и смогут предусмотреть защиты от множества атак также довольно сложно.

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

Вариант 2. Развертывание готового сервиса авторизации IdP: Keycloak и аналоги

Готовая система управления доступом (Identity & Access Management), которую вы разворачиваете на собственных серверах — в своём ЦОД, приватном облаке или у российского провайдера (Yandex Cloud, VK Cloud, Selectel, Cloud.ru). Выбор модели развёртывания зависит от требований к безопасности, комплаенсу и бюджета — подробное сравнение on-premise и облачных подходов мы разбирали в отдельной статье.

Такой вариант предполагает использование проверенной системы обычно на базе открытого исходного кода, которая активно поддерживается сообществом. В таких системах уже есть готовый единый вход во множество серисов, управление пользователями, современные стандарты безопасности и множество интеграций.

Популярные open-source решения

• Keycloak — самый зрелый продукт, де-факто стандарт enterprise-сегмента. Поддерживает OIDC, SAML 2.0, OAuth 2.0, Kerberos, LDAP/AD, имеет встроенный пользовательский портал, MFA, social-логины, богатую политику паролей. Его используют множество крупных компаний и банков.
• Authentik — более новая альтернатива на Python/Go, с визуальной настройкой вариантов авторизации, хорошим API и приятным UI.
• Zitadel — облачно-ориентированная архитектура с multi-tenancy из коробки, отлично подходит для SaaS-продуктов.
• Casdoor — лёгкий Go-вариант с поддержкой множества провайдеров social-логина.
• Authelia — простой single-sign-on для домашних и небольших корпоративных сред, работает как reverse-proxy-фильтр.

Из них всех Keycloak наиболее универсальное, стабильное и проверенное временем решение.

Ключевые возможности

• Single Sign-On (SSO) между всеми корпоративными приложениями — пользователь входит один раз без повторного ввода пароля для нескольких систем.
• Подключение к базам пользователей — подключение внешних IdP (ЕСИА, Яндекс ID, VK ID, Сбер ID, корпоративный LDAP/AD) в едином месте.
• Многофакторная аутентификация — поддержка временных кодов из коробки, вход по биометрии и отпечатку пальца на телефоне, TOTP, WebAuthn, SMS, аппаратные ключи.
• Управление пользователями и группами — делегирование, ролевая модель (RBAC), атрибуты, организации/тенанты. Можно изолировать базы пользователей друг от друга для разных проектов и гибко работать с ролями и доступами.
• OAuth 2.0 / OIDC-провайдер — ваш продукт может выступать IdP для сторонних сервисов и другие компании могут использовать вашу систему для входа.
• Аудит и журналирование — кто, когда и откуда входил, какие действия выполнял.
• Адаптивные политики доступа — ограничение по IP, времени, устройству.

Преимущества

• Полный контроль над данными. Вся учётная информация — на вашей территории, в вашей БД.
• Функциональность корпоративного уровня «из коробки», который в самописном решении пришлось бы делать месяцами с огромными вложениями денег.
• Сообщество и регулярные обновления безопасности от разработчиков продукта.
• Небольшие затраты на развертывание и поддержку. Множество разработчиков с опытом использования таких систем. Понятные инструкции по развертыванию, интеграции и поддержке.
• Готовое решение покрывает все потребности в 90% случаев. Также можно доработать модули для новых потребностей.
• Возможность подключения входа через сервисы без доработок. Можно за часы настроить вход через Яндекс ID, ВК и прочие.

Недостатки

• Требуются DevOps-компетенции. Развёртывание, настройка, обновления, резервное копирование, мониторинг — всё это ложится на вашу команду.
• Порог входа для настройки. Понимание OIDC-флоу, маппинга клеймов, клиентских скоупов и политик требует обучения, но это популярные стандартны с множеством материалов в открытом доступе.
• Ответственность за обновления и бэкапы — это уже ваша зона риска.

Использование готового сервиса авторизации — оптимальный выбор для компаний среднего и крупного размера, для SaaS-продуктов со множеством сервисов, а также для тех, кому важна интеграция с корпоративным каталогом (AD/LDAP) или с ЕСИА.

Сэкономьте месяцы разработки собственной системы

Обратитесь к нам и мы спроектируем решение, которое подойдёт вашему бизнесу. Поможем развернуть систему авторизации, проведём переход для существующих систем и настроим хранение данных на РФ серверах для соответствия требованиям регуляторов.

Получить план решения вашей задачи.

Вариант 3. Российские сервисы авторизации

Внешние системы авторизации, которые берут на себя аутентификацию пользователя и возвращают в ваш продукт подтверждённую идентичность. По технической модели они полностью аналогичны «Войти через Google» — только законно.

Основные поставщики

• ЕСИА («Госуслуги») — государственная система идентификации. Обязательна для ресурсов, подпадающих под отраслевые требования (банки, МФО, страхование, телеком, ресурсы с лицензируемым контентом). Подключение требует регистрации в тестовой и продуктивной среде, выпуска электронной подписи юрлица и сертификата ГОСТ.
• VK ID — простая OAuth-интеграция, подходит для B2C-продуктов массового спроса.
• Яндекс ID — авторизация через аккаунт Яндекса, который у большинства российских пользователей уже есть.
• Сбер ID — банковская идентификация, популярная в финтехе и на маркетплейсах.
• Тинькофф ID — аналогичный сервис от Тинькофф.
• MTS ID и прочие — дополнительные опции для расширения охвата.

Преимущества

• Быстрая интеграция. Несколько дней на чтение документации и подключение вместо недель на развёртывание IdP.
• Нет инфраструктурной нагрузки. Ничего не нужно хостить, обновлять и резервировать.
• Знакомый UX. Пользователю не нужно создавать новый аккаунт — он входит через привычный сервис.
• Гарантированное соответствие требованиям закона — все перечисленные провайдеры квалифицированы как российские.

Недостатки

• Зависимость от провайдера. Если у Яндекса или VK случится сбой — ваши пользователи не смогут войти. Нужна стратегия фолбэка.
• Коммерческие условия. Многие сервисы берут плату за пользователя или за запросы; при больших объёмах это существенная статья расходов.
• Ограниченная кастомизация. Вы не управляете политиками паролей, форматом токенов, сроками жизни сессий.
• Распределённая идентичность. У каждого провайдера свой идентификатор; без связующего слоя (того же Keycloak) возникает проблема связи аккаунтов.
• Нет доступа к пользователям. Все данные хранятся у поставщика и у вас не будет к ним доступа. Для сохранения данных вошедших пользователей потребуется дополнительная разработка

Использование только внешних российских IdP удобно для B2C-продуктов с большой публичной аудиторией, где социальный вход исторически был основным способом регистрации. В B2B и корпоративном сегменте этого почти всегда недостаточно — нужна собственная база пользователей и корпоративные политики.

Сравнение вариантов

Какой подход выбрать

В большинстве зрелых случаев ответ — гибридный: self-hosted Keycloak в качестве центрального IdP, к которому подключаются ЕСИА, Яндекс ID, VK ID и другие нужные российские провайдеры. Такое решение даёт:

• единый каталог пользователей под вашим контролем;
• готовый SSO для всех ваших сервисов и микросервисов;
• точку подключения для любых внешних IdP без переработки продуктов;
• соответствие требованию российского контроля над системой.

Для B2C-продукта с массовой аудиторией часто достаточно связки «своя форма логина-пароля + кнопки российских IdP через Keycloak». Для B2B / enterprise Keycloak становится точкой интеграции с корпоративным серверами учетных данных (Такими как Active Directory), корпоративной почтой и ЕСИА — где это требуется по закону.

Для небольшого продукта без амбиций на интеграции разумно выбрать либо минимальный самописное решение с SMS-подтверждением номера, либо Authentik/Zitadel как лёгкий self-hosted вариант.

Независимо от выбора, общими остаются три принципа:

1. Только российская инфраструктура хостинга (или собственный ЦОД).
2. Российский оператор персональных данных — учётные записи пользователей не должны утекать за рубеж даже в момент аутентификации.
3. Резервное копирование и план восстановления — потерять базу IdP означает парализовать всю компанию.

Заключение

Запрет авторизации через иностранные сервисы — не разовая неудобная поправка, а часть системного курса на суверенизацию ИТ-инфраструктуры: вслед за импортозамещением ПО и переходом на on-premise развёртывание компании последовательно возвращают себе контроль над пользовательскими данными. Срок вступления штрафов в силу (7 июля 2026 года) означает, что времени на «подумать» практически не осталось.

Технически приведение систем в соответствие — задача решаемая. Готовых open-source продуктов и российских IdP достаточно, а миграция с иностранных OAuth обычно занимает от пары недель до пары месяцев в зависимости от сложности продукта. Главное — не откладывать решение в долгий ящик и не сводить его к косметическому удалению кнопок «Войти через Google»: за этим должна стоять продуманная модель управления пользователями.