Несколько лет назад в закон «Об информации...» (149-ФЗ) добавили требования к способам авторизации пользователей.

Многие тогда обратили внимание на новость, но практических последствий почти не было — ответственности за нарушение не существовало. Если не штрафуют, значит +19,9 км/ч разрешается ;)

Теперь, чуть больше недели назад, ситуация изменилась - с 7 июля 2026 года появилась административная ответственность, а штраф для юридических лиц 700 000 рублей.

Почитал новости, комментарии, пообщался с коллегами - оказалось, что не все до сих пор разобрались.

Например мы обсуждали:

• действительно ли теперь запрещен Google OAuth;

• можно ли использовать Gmail как логин;

• касается ли это мобильных приложений;

• нужно ли удалять старые аккаунты пользователей;

• что делать международным сервисам.

Ок, давайте ликбез. Собрал информацию максимально просто, без лишних деталей и сложных формулировок. Кому важно разобраться в деталях - вот закон 149-ФЗ в Консультанте

Что изменилось

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

Основные варианты:

• номер мобильного телефона;

• ЕСИА (Госуслуги);

• Единая биометрическая система;

• российские системы авторизации, соответствующие требованиям законодательства.

За нарушение предусмотрена административная ответственность:

Кого это вообще касается

Это, пожалуй, самый важный вопрос.

Закон применяется одновременно при нескольких условиях.

Если совсем упростить, то он касается случаев, когда:

• владелец сервиса (сайта, приложения) — российское юридическое лицо или гражданин РФ;

• сервис работает на территории России;

• есть личный кабинет или иной функционал, требующий входа;

• пользователь находится на территории РФ.

То есть далеко не каждый сайт автоматически подпадает под действие этих требований.

Что считается "авторизацией через гугл"

Здесь возникает путаница.

Запрещается не использование Google вообще. Запрещается использовать Google как сервис подтверждения личности пользователя.

Например, разрешено:

• email + пароль;

• номер телефона + SMS;

• собственная система учетных записей.

Нельзя использовать:

• Google Sign-In;

• Sign in with Apple;

• Telegram Login Widget;

• GitHub Login;

• Facebook Login;

• Microsoft Login;

• Discord Login.

Какие российские альтернативы существуют

Если вы используете OAuth 2.0 / OpenID Connect, переход не обязательно означает разработку собственной системы аутентификации. Можно использовать варианты:

• ЕСИА (Госуслуги) — государственная система идентификации и аутентификации.

• Authoriza — российская OpenID Connect-платформа.

• VK ID — единая система входа в экосистему VK.

• Яндекс ID — система авторизации сервисов Яндекса.

• Сбер ID — единая учетная запись экосистемы Сбера.

Gmail использовать можно?

Да.

(Это один из самых распространенных вопросов)

Если пользователь зарегистрировался с адресом user@gmail.com, это не является нарушением. Email — всего лишь идентификатор пользователя.

Закон регулирует механизм аутентификации, а не адрес электронной почты.

А Telegram?

Здесь ситуация похожая.

Использовать Telegram как канал уведомлений, бота или способ доставки сообщений закон не запрещает.

Но если есть кнопка Войти через Telegram и именно Telegram подтверждает его личность, это уже атата.

Что делать с существующими пользователями?

Закон не требует удалять уже созданные аккаунты.

На практике логичный сценарий выглядит так:

1. уведомить пользователей;

2. предложить привязать новый способ входа;

3. отключить иностранную авторизацию после окончания переходного периода.

Удалять сами учетные записи не требуется. А как их переводить в новый - фантазируйте и творите! Есть, например, такой вариант перенести пользователей.

Что делать разработчикам мобильных приложений

Если у вас Android или iOS-приложение, требования никуда не исчезают.

Здесь начинаются танцы с собственной "логинкой" - написать свою, поднять кейклоак, подключиться к какому-то OIDC-провайдеру.

Здесь выбор за разработчиком, но я бы рекомендовал все-таки OIDC-провайдера. Потому что приложений много, платформы разные, в каждое встраивать - это гемор неудобно. Ну если, конечно, не категорически хочется повайбкодить или понастраивать инфраструктуру. Кто-то с этого кайфует и у него есть на это время, а зачем я буду портить человеку удовольствие ;)

Что делать международным сервисам

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

Закон распространяется на авторизацию пользователей, находящихся на территории Российской Федерации. На практике это означает, что международные сервисы могут использовать различные способы входа в зависимости от региона пользователя.

Логика может выглядеть следующим образом:

При этом важно, чтобы пользователям, находящимся на территории Российской Федерации, не предоставлялась возможность входа через иностранные сервисы авторизации.

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

При этом не забывайте - если организация не является российской, то требования не обязательны. По крайней мере пока.

Что я бы рекомендовал проверить

Проверьте свои старые сайты и аппы. Может на них никто уже давно не сидит, но какой-нибудь бот-паук найдет кнопку - и придут новые "счета на оплату".

Что изменится дальше

Скорее всего, требования в этой области будут ужесточаться.

Имеет смысл строить систему аутентификации так, чтобы смена провайдера входа не требовала переписывания приложения.

Если на ваш вопрос статья не ответила - задавайте в комментариях.