В России снова обсуждают вход на сайты через Google, Apple ID, GitHub и другие иностранные аккаунты. Повод — подписанный закон № 199-ФЗ от 26.06.2026, который добавил в КоАП штрафы за нарушение правил авторизации пользователей.
Но сам запрет появился не сейчас. Базовая норма пришла ещё с 406-ФЗ от 31.07.2023 и с 1 декабря 2023 года живёт в ч. 10 ст. 8 закона № 149-ФЗ «Об информации». Новое в том, что теперь за нарушение есть отдельная статья КоАП — 13.55:
для граждан 10–20 тысяч рублей,
для должностных лиц 30–50 тысяч,
для юрлиц 500–700 тысяч.
Обычного пользователя не штрафуют за сам факт наличия Gmail, Apple ID или GitHub. Но если этот пользователь одновременно владелец российского сайта, приложения или сервиса и оставил там вход через иностранный аккаунт, он уже не «просто пользователь», а «субъект обязанности по 149-ФЗ».
Снаружи всё выглядит как борьба с иностранными кнопками входа, на деле можно разглядеть спор о том, кто держит ключ от аккаунта пользователя.
Главная проблема — старые аккаунты
Новая регистрация — не самая страшная часть этой истории. Новый пользователь как‑нибудь зарегистрируется: через пароль, телефон, passkey, российский ID или просто уйдёт.
Сложнее со старыми аккаунтами.
У сайта уже есть пользователи. У них уже есть заказы, подписки, баланс, серверы, домены, документы, комментарии, избранное, история обращений. И часть этих пользователей годами входила одной кнопкой: Google, Apple, GitHub, Microsoft.
Теперь эту кнопку надо убрать, но аккаунт пользователя нельзя потерять.
Поэтому задача звучит не как «сделать новую авторизацию». Задача звучит так: аккуратно привязать к старому аккаунту новый разрешённый способ входа.
Это совсем другой проект. Нужно найти пользователей, у которых единственный способ входа — иностранный провайдер. Нужно дать им сценарий: «вы вошли через Google, добавьте пароль, passkey, телефон или другой разрешённый способ, чтобы не потерять доступ». Новый способ должен привязываться к тому же локальному user_id, а не создавать второй аккаунт.
Иначе получится классика: кнопку убрали, пользователь не вошёл, поддержка получила поток писем «где мои заказы, серверы и деньги на счёте».
Как это было раньше
Раньше у владельца сайта было два обычных пути авторизации.
Первый — заводить для юзеров «свой» аккаунт: логин, пароль, восстановление доступа, база пользователей, свои сессии, свои ошибки, свои утечки. Зато ни на кого не полагаясь, и делая что душа пожелает, если с этим согласится пользователь и потом проверяющий.
Второй — внешний вход, все эти «Войти через Google», «Войти через Apple», «Войти через GitHub», «Войти через Microsoft». Обычно это делается через OAuth 2.0 и OpenID Connect. Строго говоря, OAuth 2.0 сам по себе не про вход пользователя, а про выдачу доступа; для логина поверх него обычно используют OpenID Connect.
Для маленького проекта такая схема была удобной. Пользователь не заводит ещё один пароль. Сайт не хранит пароль. Большой провайдер уже умеет MFA, восстановление доступа, антифрод, подозрительные входы и всё то, что небольшой команде делать дорого и скучно.
В спокойной среде это выглядело разумно: зачем писать свою систему входа, если можно доверить проверку пользователя Google, Apple или GitHub? Минимум уже потому, что у крупных провайдеров есть выделенные команды, которые следят за безопасностью.
Что изменилось после санкций и блокировок
После 2022 года стало заметно, что внешний провайдер входа — это не только удобство, но и зависимость.
Если у российского сервиса вход завязан на Google, Apple, Microsoft или GitHub, часть работоспособности сервиса зависит от компании, которая находится в другой юрисдикции и живёт по своим правилам комплаенса. Она может изменить условия API, ограничить работу аккаунта, закрыть консоль разработчика, отключить платёжный профиль, перестать работать с отдельной компанией или с целым классом клиентов.
Звучит дико, но российский IT уже проходил похожее с облаками, CDN, магазинами приложений, сертификатами, доменами, репозиториями, корпоративными SaaS и платёжными системами. И нет, это не про «кто первый начал», а про то, в какой реальности мы живём.
С авторизацией проблема особенно неприятная. Если на сайте сломался виджет комментариев, подтягивающий данные с другого сайта, — плохо, но сайт ещё жив. Если сломался вход — для пользователя сервис перестал существовать.
Поэтому у государства была понятная претензия: российский сервис не должен полностью зависеть от иностранной компании в такой базовой операции, как вход пользователя в аккаунт.
С этим тезисом можно спорить политически, но технически он имеет смысл.
Что теперь требует закон
Часть 10 статьи 8 149-ФЗ говорит, что владелец сайта, страницы сайта, информационной системы или программы для ЭВМ, если это российское юрлицо или гражданин РФ и он работает в интернете на территории России, должен проводить авторизацию пользователей, находящихся в России, одним из четырёх способов.
Первый — через абонентский номер российского оператора мобильной связи.
Второй — через ЕСИА, то есть «Госуслуги».
Третий — через ЕБС, единую биометрическую систему.
Четвёртый — через иную информационную систему, которая обеспечивает авторизацию, соответствует требованиям ст. 16 149-ФЗ по защите информации и принадлежит гражданину РФ без второго гражданства или российскому юрлицу под российским контролем.
Последний пункт важнее всего. Закон, грубо говоря, не говорит: «все обязаны идти в VK ID». Он говорит: можно использовать любую российскую систему входа, если её владелец подходит под требования закона.
Сюда потенциально попадают VK ID, Яндекс ID, Сбер ID, T‑ID, МТС ID, региональные системы вроде mos.ru, корпоративные российские SSO, а также собственная система входа владельца сайта.
Но «потенциально» — ключевое слово. Закон написан широко, а правоприменение будет смотреть не на то, как разработчик у себя в голове классифицирует систему, а на то, как именно пользователь получает доступ к закрытой части сайта.
Почему «войти через Госуслуги» — не универсальный ответ
Отдельно стоит сказать про ЕСИА, то есть вход через «Госуслуги».
На бумаге это один из разрешённых способов авторизации. В комментариях его легко упомянуть так, будто владелец сайта может просто заменить «Войти через Google» на «Войти через Госуслуги» и закрыть вопрос. На практике это не так.
ЕСИА — это не обычный OAuth‑провайдер для всех желающих. Это государственная система с регламентом информационного взаимодействия, заявками, технологическим порталом, требованиями к информационному взаимодействию и защите информации. Там появляются не только разработческие задачи, но и организационные: кто заявитель, какая информационная система подключается, какие данные запрашиваются, кто отвечает за сопровождение, как проходить изменения и что делать при изменении регламента.
Для банка, университета, медицинской организации или сервиса, где нужна юридически значимая личность, такой путь может быть оправдан. Для форума, небольшого SaaS, интернет‑магазина, личного кабинета хостинга или сайта сообщества — часто нет.
Есть и практическая сторона. Интеграция с государственными системами редко сводится к «взяли библиотеку с GitHub и за вечер прикрутили кнопку». Часто бизнес покупает готовый модуль или услугу у подрядчика, потому что самому поддерживать это дорого и неприятно. С ЕСИА вопрос бюджета будет заметен сразу.
И здесь развилка. Если после запрета иностранных кнопок небольшой сайт выбирает между VK ID, Яндекс ID, ID от операторов, телефоном и ЕСИА, пользователь получает не «больше безопасности», а меньше выбора. Телефон слаб как способ восстановления важного аккаунта. ЕСИА слишком тяжела для обычных сервисов. Крупные российские ID‑провайдеры собирают лишние метаданные в свои копилки. А собственный вход возвращает владельцу сайта всё, от чего он когда‑то уходил к Google: пароли, MFA, восстановление доступа, логи, персональные данные, обновления и ответственность за ошибки.
Именно поэтому вопрос не в том, какую кнопку поставить вместо Google. Вопрос в том, как не потерять старые аккаунты и не загнать пользователей в один новый обязательный вход.
Что, вероятно, хотели получить авторы закона
Если читать закон не как злой умысел, а как попытку решить государственную задачу, логика примерно такая.
Первое: убрать зависимость российских ресурсов от иностранных компаний, которые могут выключить или ограничить вход не по техническим причинам, а из‑за санкций, комплаенса или политики платформы.
Второе: сократить передачу метаданных за рубеж. Внешний провайдер входа обычно не видит содержимое сайта, но видит сам факт входа: какой сервис запросил авторизацию, когда, с какого устройства, с какого IP, под каким аккаунтом. Это уже поведенческий граф.
Третье: вернуть ответственность в российскую юрисдикцию. Если вход обеспечивает российская система, её можно проверять, штрафовать, обязывать выполнять требования по персональным данным и защите информации.
Четвёртое, неофициальное: создать рынок для российских провайдеров входа. Это уже не только безопасность, но и промышленная политика. Когда иностранные кнопки входа запрещены, спрос на российские ID‑сервисы возникает не только из‑за удобства, но и из‑за страха штрафов.
Мотивация понятна. Но из понятной мотивации не следует, что выбранное решение хорошее.
Почему замена Google на VK или Яндекс не решает проблему
Если сайт убрал «Войти через Google» и поставил «Войти через VK», он не избавился от посредника — он его сменил.
Раньше информацию о входах мог видеть Google. Теперь её может видеть VK. Раньше пользователь зависел от иностранной экосистемы. Теперь он зависит от российской экосистемы. Раньше одна большая компания помогала собрать поведенческий профиль. Теперь это может делать другая большая компания. И не сказать, чтобы было понятно, кому в меньшей степени хочется отдавать это делать.
Да, с точки зрения государства разница принципиальная: российская компания находится в российской юрисдикции, хотя бы формально. А вот с точки зрения приватности пользователя картина не становится автоматически лучше.
То же касается Яндекса: технически у него сильная инфраструктура, но это крупная рекламная и поведенческая экосистема. Делать связку VK ID с Яндекс ID универсальным ключом ко всему Рунету — значит усиливать концентрацию данных у игроков, которые и без того знают о пользователе очень много.
Поэтому правильный вывод не «Google плохой, ВК/Яша хорошие». Правильный вывод другой: чем меньше независимых способов входа остаётся у пользователя, тем выше риск, что весь Рунет постепенно сведут к нескольким крупным поставщикам аккаунтов.
Это может быть удобно государству и крупному бизнесу. Но это не обязательно хорошо для пользователя.
Почему телефон — плохой фундамент для доверия
Самый массовый разрешённый способ — номер телефона. Для чиновника он выглядит понятным: номер выдан оператором, оператор знает абонента, даже смотрел в его паспорт, значит — всё нормально. Особенно на бумаге нормально.
Но технически номер телефона — не сказать чтобы железобетонная основа для проверки входа.
Номер не принадлежит человеку в том смысле, как ключ от квартиры, который лежит у него в кармане. Номер выдан человеку на время действия договора. Номер обслуживается оператором. SIM‑карту можно перевыпустить. Номер можно перенести. Договор можно переоформить. Номер могут отключить, отдать другому абоненту, заблокировать из‑за проблем с данными или ошибиться при обслуживании.
Ах да, и за вот эти, вполне болезненные для клиента действия, оператору обычно не потребуется ни заплатить штраф, ни даже извиниться.
Есть отдельный класс атак — SIM swap, когда злоумышленник добивается перевыпуска SIM‑карты или переноса номера и начинает получать звонки и SMS жертвы. Именно поэтому в современных рекомендациях SMS давно считается не лучшим вторым фактором. Например, NIST SP 800–63B относит проверку через телефонную сеть к restricted‑методам и рекомендует учитывать признаки вроде смены SIM, переноса номера и другого подозрительного поведения.
Но рекомендовать не значит жениться настаивать на выполнении, да и документ этот американский.
То есть закон говорит: «можно входить через номер телефона». Инженерная практика говорит: «номер телефона — это терпимый запасной вариант, но плохой первичный ID аккаунта». Разработчики, в том числе и госсайтов, пилят свой код, встраивают телефон везде и всюду как уникальный ID, сдают поделку в работу — и, конечно, никто переделывать не станет.
Если сайт с рецептами или небольшой форум просит телефон только потому, что так проще выполнить закон, это ещё можно пережить.
Если телефон становится главным способом восстановления доступа к важному аккаунту, получаем ещё более лихо закрученный парадокс: государство запрещает Google, который, будем говорить, довольно параноидален насчёт данных для входа, как недостаточно надёжного посредника и предлагает вместо него оператора связи, который сам является посредником, да ещё и не особо старается быть безгрешным: ошибается, переоформляет номера и на любые попытки что‑то выяснить может ответить в духе «вы сами это сделали, через отправку USSD, но когда и какого — у нас логов нет».
Итог, или что делать владельцам сайтов
Первое: найти пользователей, которые входят только через иностранного провайдера, и дать им миграционный сценарий до отключения кнопки. Если человек годами входил через Google или Apple, новый способ входа должен привязаться к старому user_id, а не создать ему новый пустой аккаунт.
Второе: найти все способы входа. Смотреть надо не только на большую кнопку «Войти через Google», но и на менее заметные места.
Проверьте:
Telegram Login Widget, если считать его иностранной системой — см. оговорку про правоприменительную практику;
magic link на Gmail;
сброс пароля через иностранную почту;
корпоративный вход через Microsoft Entra ID, Okta или Google Workspace;
старые мобильные приложения, где кнопка входа осталась в UI;
API‑клиенты, где пользователь получает доступ через внешний OAuth.
Третье: отделить email как контакт от email как проверки доступа. Адрес Gmail в профиле сам по себе не обязан быть проблемой. Проблема появляется, когда владение этим ящиком становится способом входа или восстановления доступа: magic link, одноразовый код, сброс пароля.
Самый осторожный вариант: email оставить как контактный адрес, но не делать иностранную почту единственным способом доказать, что пользователь — это он.
Четвёртое: вернуть нормальный локальный вход. Логин, пароль, MFA, passkeys/WebAuthn, нормальные сессии, rate limit, защита от перебора, аудит восстановления доступа. «В жизни всегда есть место подвигу», потому что сделать это нужно быстро.
Пароли не умерли. Просто их нельзя хранить и обслуживать как в 2008 году. Минимум — Argon2id, запрет слабых паролей по словарям, защита от credential stuffing, журналирование подозрительных входов, отзыв сессий и понятный recovery.
Пятое: не делать один российский ID единственным способом входа. Если вы подключаете VK ID, Яндекс ID, Сбер ID, T‑ID или МТС ID, оставьте пользователю независимый вариант: локальный аккаунт, passkey, TOTP, телефон как запасной способ. Чисто на всякий случай, потому что шансы встретить динозавра увидеть отказ от ВК/Яндекса никогда не равны нулю.
Шестое: не использовать «Госуслуги» там, где они не нужны. ЕСИА хороша для юридически значимых действий: госуслуги, финансы, медицина, образование, подтверждение статуса. Для форума, медиа, небольшого SaaS или интернет‑магазина это слишком тяжёлый инструмент. Тем более не цепляйтесь за ЕСИА‑авторизацию через прокси‑посредников.
Чем «сильнее» идентификатор, тем выше цена ошибки. Не везде нужно знать, кто человек юридически. Часто сайту достаточно понимать, что это тот же пользователь, который вчера оставил настройки и заказ.
И да, нужно критически пройтись по текстам на своём сайте, в том числе разделам помощи и юридическим документам, и поправить формулировки насчёт того, что и как сайт хранит и для чего использует.
Что делать пользователям
Пользователю надо понимать: Gmail, Apple ID и GitHub не становятся запрещёнными аккаунтами. Меняется то, какие кнопки входа российский сайт имеет право показывать пользователю из России.
Практически стоит сделать несколько вещей.
Если важный российский аккаунт завязан только на Google, Apple или GitHub, добавьте другой способ входа заранее.
Используйте парольный менеджер. Локальных аккаунтов станет больше, а значит снова вырастет соблазн повторять пароли. Это плохая идея.
Включайте MFA. Лучше TOTP или passkey. Вариант с SMS будет лучше, чем использовать один пароль, но хуже, чем нормальный криптографический ключ или приложение‑аутентификатор.
Не несите всё в VK ID или Яндекс ID просто потому, что так быстрее. Если сайт даёт локальный аккаунт с passkey, это часто более приватный вариант.
Проверяйте восстановление доступа. Самая слабая часть аккаунта часто не вход, а способ вернуть доступ. Если аккаунт можно восстановить через старую иностранную почту или через номер, который легко перевыпустить, именно это и есть слабое место.
Через кого можно входить, кроме VK/Яндекс
Вариантов больше, чем кажется.
Самый нейтральный — собственный вход сайта: логин, пароль, MFA, passkey. Для многих проектов это лучший вариант, если он сделан нормально.
Телефон — привычный, массовый, но спорный способ. Его можно использовать как запасной канал, но лучше не делать единственной опорой аккаунта.
ЕСИА — для сервисов, где нужна юридически значимая личность.
ЕБС — для редких случаев, где биометрия действительно оправдана.
Сбер ID, T‑ID, МТС ID и региональные системы вроде mos.ru — если аудитория и сценарий использования действительно к ним подходят.
Корпоративный российский SSO — для внутренних систем и B2B, если владелец и инфраструктура укладываются в требования закона.
Собственный OIDC‑провайдер — для группы своих сайтов или закрытого сообщества, если есть кому его администрировать и отвечать за безопасность.
Можно ли запилить свой OAuth/OIDC‑сервер
Тут важно сначала уточнить термин. Если речь о входе пользователя, лучше говорить не просто «OAuth2-сервер», а OIDC‑провайдер. OAuth 2.0 отвечает за выдачу доступа, а OpenID Connect добавляет слой аутентификации пользователя.
Если у вас один сайт, отдельный OIDC‑провайдер обычно не нужен. Проще сделать нормальный локальный вход прямо в приложении.
Если у вас несколько своих сервисов — блог, форум, wiki, Git, Nextcloud, личный кабинет, админка, API‑панель, — свой OIDC‑провайдер уже имеет смысл. Его можно поднять на Keycloak, Authentik, Authelia, Ory или Zitadel. Тогда получится примерно такой же блок входа, как раньше давали Google или GitHub, только свой: единый аккаунт, MFA, passkeys, единая политика сессий, единое отключение пользователя.
Но здесь есть неприятная честность: вы получаете «себе в руки» всё то, от чего когда‑то уходили к Google. Теперь вы сами отвечаете за хранение паролей, восстановление доступа, MFA, passkeys, логи, резервные копии, обновления, уязвимости, персональные данные, политику обработки, требования закона и работу поддержки. Вы становитесь не просто владельцем сайта, а маленьким поставщиком входа для своих же сервисов.
Есть и юридическая часть. По букве ч. 10 ст. 8 149-ФЗ «иная информационная система» подходит только если её владелец — гражданин РФ без гражданства другого государства или российское юрлицо под российским контролем. Система также должна соответствовать требованиям защиты информации из ст. 16 149-ФЗ.
Отсюда неприятные выводы.
Гражданин РФ без второго гражданства, который поднял OIDC для своих проектов, выглядит самым понятным случаем. У него есть аргумент: система российская, владелец подходит под требование, данные и администрирование под его контролем.
Гражданин РФ со вторым гражданством — плохой случай. Закон прямо говорит: гражданин РФ, не имеющий гражданства другого государства. Значит, как владелец такой системы он под этот вариант не подходит.
Иностранец, живущий в России, например гражданин Белоруссии или Аргентины, тоже не подходит как физлицо. Он не гражданин РФ и не российское юрлицо. Даже если он создаст российское юрлицо, придётся отдельно смотреть, кто его контролирует.
Для семейного сервера (того же Nextcloud) или маленького закрытого сообщества ситуация мутная. Если это не публичный ресурс, не коммерческий сервис, не площадка с регистрацией пользователей и не деятельность в интернете на территории РФ, практический риск ниже. Но красивого исключения «для homelab и родственников» в норме не видно.
Поэтому самодельный OIDC — не обход закона, а один из возможных способов входа. Но только если владелец системы проходит по требованиям и готов объяснить, как у него устроена защита информации (объяснить, разумеется, не в комментариях на Хабре, а на бумаге).
Отдельная ловушка — думать, что задачу можно решить любым «формально подходящим» OAuth2/OIDC‑провайдером: владелец нужного гражданства, юрлицо в нужной юрисдикции, серверы где положено, документы выглядят благонадёжно — «задача на 20 минут, войдём и выйдем». Т.е., сделать-то так можно, и, надо думать, технически работать вполне будет.
Но требования могут меняться. Сегодня достаточно одного набора условий, а «завтра» — мало ли? — добавят что-то поинтереснее: размер уставного капитала, круглосуточную поддержку, интеграцию с очередной государственной системой, обязательный аудит, рекомендованный SDK или ещё что-нибудь из мира, где кнопку входа проектирует не разработчик, а комиссия.
Плюс остаётся вопрос доверия. Даже если провайдер проходит по всем бумажкам, почему пользователь должен начать ему доверять?
Хабр как авторизатор
Условно, вот Хабр допилит свой авторизатор до функций полноценного oauth2 провайдера. Для входа на сам сайт и его сервисы использовать такое совершенно логично: он отвечает за свои аккаунты, комментарии, черновики, карму и публикации. Но есть ли резон использовать этот же авторизатор для входа в личный кабинет хостинга, где лежат серверы, домены, счета и что‑нибудь рабочее? Тут уже нужно крепко думать.
Дело не в недоверии именно к Хабру. Просто авторизация как внешний сервис — это отдельный бизнес, отдельная эксплуатация, отдельная безопасность, отдельная поддержка и отдельное обязательство жить годами. У медиа‑площадки или профессионального сообщества может быть отличный сайт, сильная аудитория и узнаваемый бренд, но это не делает её автоматически надёжным поставщиком входа для чужих критичных сервисов. Особенно если развитие самого сайта в последние годы выглядит (скажем прямо) скорее осторожным поддержанием жизни, чем активным развитием платформы. Кроме того, такой «внешний сервис авторизации должен уметь работать и с политическими „вызовами времени“ — скажем, давлением со стороны регулирующих органов, да и со стороны конкурентов.»
Провайдер входа — это не просто красивая кнопка на форме логина. Это посредник, через которого пользователь доказывает сайту, что он действительно владелец аккаунта. Если этот посредник закроется, введёт плату, сломает API, начнёт требовать новые согласия, продастся крупному игроку, сменит приоритеты или просто перестанет развивать продукт, проблема вернётся: вчера человек мог войти в аккаунт с покупками и услугами, сегодня не может.
Замена одного внешнего провайдера на другого не решает проблему зависимости. Она только меняет адрес, по которому находится рубильник, управляющий доступом, а доверие к новому адресу всё равно остаётся вопросом для доверяющего.
Практичный вариант для большинства
Для большинства сайтов разумная схема выглядит так:
Базовый способ — собственный аккаунт сайта.
Пароль хранится нормально, с Argon2id или сопоставимым современным подходом.
Для MFA есть TOTP и passkeys/WebAuthn.
Телефон используется как запасной канал, но не как единственный корень аккаунта.
Иностранная почта остаётся контактным адресом, но не единственным способом входа и восстановления.
ЕСИА подключается только там, где действительно нужна юридически значимая личность.
Российский ID‑провайдер можно добавить для удобства, но не делать единственной дверью.
Для группы своих проектов можно поднять свой OIDC, если владелец подходит под закон и готов отвечать за безопасность.
Для сообщества общий ID имеет смысл только как серьёзный проект с юрлицом, аудитом и прозрачными правилами, а не как «давайте поднимем Keycloak на VPS».
Что будет дальше
Скорее всего, первым делом сайты начнут просто убирать иностранные кнопки входа. С утра тикет для фронтендеров, в обед созвон по итогам, вечером созвон по жалобам и выловленным багам. Так быстрее и дешевле.
Потом вырастет вход по телефону. Это самый понятный для бизнеса способ, хотя с точки зрения безопасности он спорный.
Крупные российские ID‑провайдеры получат дополнительный рынок. VK, Яндекс, Сбер, Т‑Банк, МТС и региональные системы станут чаще появляться там, где раньше был Google.
Потом начнутся споры: можно ли использовать иностранный email как логин; можно ли magic link; что делать с корпоративным SSO; как определять, что пользователь находится в России; подпадают ли мобильные приложения; что делать с пользователями, зарегистрированными до запрета; считается ли семейный сервер с фоточками «информационной системой».
И где‑то неизбежно появятся перегибы. Кто‑то начнёт требовать телефон там, где он не нужен. Кто‑то запретит Gmail даже как контактный адрес. Кто‑то решит, что безопаснее всего загнать пользователей в один крупный российский ID. Это будет не безопасность, а комплаенс по принципу «лишь бы не прилетело».
Вывод
У государства была понятная претензия: не надо строить вход на российские ресурсы так, чтобы ключ от аккаунта лежал у иностранной платформы, которая может изменить правила или отключить доступ.
Но правильный ответ на эту претензию — не массовый перевод всех в VK ID или Яндекс ID. Это просто смена одного большого посредника на другого.
Правильный ответ — аккуратно перенести старые аккаунты на новые способы входа и не загонять пользователя в одну новую обязательную дверь: локальный аккаунт, passkeys, TOTP, аккуратное восстановление доступа, минимум лишних данных и несколько независимых способов входа.
Свой OIDC‑провайдер может быть хорошей альтернативой, особенно для группы своих сервисов. Но он не избавляет от ответственности. Наоборот, он возвращает её владельцу: хранение паролей, защита ключей, персональные данные, логи, обновления, соответствие закону и готовность к следующему переезду, если правила снова поменяются.
Закон заставляет убрать иностранные кнопки, и это не дискуссия о необходимости такого шага, изменение уже случилось.
Теперь вопрос в другом: сайты воспользуются этим как поводом привести вход в порядок или просто заменят одну большую кнопку на другую?
