В России снова обсуждают вход на сайты через 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‑провайдер может быть хорошей альтернативой, особенно для группы своих сервисов. Но он не избавляет от ответственности. Наоборот, он возвращает её владельцу: хранение паролей, защита ключей, персональные данные, логи, обновления, соответствие закону и готовность к следующему переезду, если правила снова поменяются.
Закон заставляет убрать иностранные кнопки, и это не дискуссия о необходимости такого шага, изменение уже случилось.
Теперь вопрос в другом: сайты воспользуются этим как поводом привести вход в порядок или просто заменят одну большую кнопку на другую?
Комментарии (150)
PereslavlFoto
29.06.2026 23:50Прошу прощения за глупый вопрос.
Разве нельзя сделать OAuth авторизацию через сервер, указанный самим пользователем? То есть, вот я хочу авторизоваться по OAuth, однако не через названных провайдеров, а через какой-то другой сервер, неизвестный целевому сайту?
ermouth
29.06.2026 23:50Разве нельзя сделать OAuth авторизацию через сервер, указанный самим пользователем
Ну, можно конечно, в теории. Но надо понимать, что oauth – это про авторизацию, а не про аутентификацию. OAuth-сервер выдаёт токен не заменяющий ввод пароля, а разрешающий какой-то набор действий. То-есть предполагается, что аутентифицирует юзера что-то со стороны, то-есть логин-пароль юзер вводит где-то в другом месте, не у вас (ну, кроме ROPC-модели).
И вы – как владелец ресурса получающего разрешения извне – наверное хотели бы доверять механике этого чего-то.
Так что на практике надо быть как минимум серьёзно беспечным, чтобы такой токен хоть на что-нибудь существенное принимать откуда попало.
vikarti
29.06.2026 23:50Раньше вроде так было можно но из того чем недавно приходилось пользоваться - такое есть (просят адрес openid сервера) только у Forgejo self-hosted(даже на Codeberg который по сути тот же Forgejo, уже Github/Gitlab)
Arioch
29.06.2026 23:50Когда LiveJournal OpenID появился - так и было.
При этом OpenID-провайдеры плодились подо что угодно, даже под аську (точнее под джаббер). Вводишь специальный URL (кажется из ЮАР), их бот стучится к тебе в мессенжер, ты подтверждаешь (или нет), он передаёт твой разрешение по цепочке и ты входишь.
Но постепенно это исчезло. Сначала появились кнопки под строчкой, потом строчку ввода опустили вниз, потом под раскрывающуюся панель спрятали, а потом вообще убрали.
Причин, наверное, много.
1. Страх выбора. Ой, копировать что-то, ой я компьютеров боюсь и у меня лапки. Ой, зачем вы меня пугаете!
1.1. И в какой-то мере это оправдано. Легко помнить хитрый URL свой, когда ты дома у единственного компьютеры, где он у тебя навсегда прописан в "заметки" браузера. Два клика и вставил. А в гостях? а в интернет-кафе? А в дороге на телефоне? Точно вспомнишь каждую букву? а вот большуй красную кнопку с картинкой Гугла или МТС не перепутаешь.
2. Узость сервиса. Только аутентификация и ничего больше. А имя узнать, а аватарку узнать, а почту узнать, а с днём рождения поздравить рекламной открыточкой?
2.1. Тот же фейсбук активно лез в службы комментариев типа Disquss. Кнопка фейсбука позволяла не только "войти на сайт", но ещё и комментировать под каждой страничкой. При этом сайту ничего не надо было хранить и поддерживать самому, никаких форумов, просто надо было на каждой страничке вставить скрипт ФБ и внизу появлялся минифорум на халяву. Так на Russia Today вроде было. И для ФБ делать отдельно кнопку и отдельно OpenID - это было просто дублирование функционала, а кроме того поощрение конкуренции. Кажется ФБ просто отказался поддерживать OpenID сразу же. OAuth же сразу сфокусировался на том, чтобы не просто заменить и отменить OpenID, а добавить в него возможность каждому игроку вставлять свои дополнительные сервисы.
2.2. может быть от гигантов и другие плюшки были какие. Бесплатные инструменты, бесплатная реклама, скидки, кэшбэки, тут можно только гадать.
3. Надёжность
3.1. Сегодня тот студент из ЮАРа играется в мессенжеры, а завтра ему надоело и его прокси-авторизатор умер. И чего делать всем, кто через него аутентифицировался? Они ведь валом в техподдержку ломанутся кричать и требовать. Так не лучше ли оставить только гигантов, которые не помрут завтра внезапно?
3.2. И хорошо, если он тихо умрёт. А если его продадут "беспринципным коммерсантам" ? Или он честно умрет, а через месяц продаван-мошенник выкупит домен и поставит там свой сайт? Да, с одной стороны, пользователь сам виноват, что рискнул доверить свою аутентификацию мошенникам. Но пользователь-то с этим согласится разве когда, или будет гнуть "я потребитель, я ничего знать не должен, а вот вы специалисты и вы не предусмотрели"? Квартира Долиной, только в меньшем масштабе.
3.3. Техническая надёжность. Криптографию сделать хорошо - трудно. И хотя как протокол OpenID был намного проще OAuth - все равно были несовместимости, когда на некоторых сочетаниях сайтов и браузеров процесс зависал где-то на середине с пустой нечеловеческой страницей и зубодробительным URL с пачкой одноразовых хэшей. Интеграция без усилий - это философский камень, десятки проектов в его с 1970-х обещали, и всегда оказывается, что без усилий только с идеальными продуктами. А в реальности, каждый делает тяп-ляп, а идеальности требует от другого. Поэтому отладить интеграцию с 5 гигантами и приспособиться к их ошибкам практически намного дешевле и быстрее, чем удовлетворить мыльную пену из сотен мелких провайдеров, которые постоянно появляются и исчезают и все сломаны по-разному
Может быть и другие были причины, но даже этих, к несчастью, хватает.
d3d14
29.06.2026 23:50вернуть нормальный локальный вход.
остальное - придуманная проблема
d3d14
29.06.2026 23:50До этих дядя-авторизаций так и было. Добавляется только таблица users (в большинстве случаев и так есть).
С учетом последних событий с отзывом сертификатов - логичный шаг.
k4ir05
29.06.2026 23:50Да, и при массовом развитии интернета проявились проблемы с этим локальным входом. Самое банальное - пользователи не хотят заводить надёжные и уникальные пароли на множестве разных сайтов.
d3d14
29.06.2026 23:50Значит это можно решить другими способами. Скажем единую точку авторизации перенести из гугла в браузер - пусть браузер сам выдает токены и имеет сложный мастер-пароль.
Проблема в том, что производитель браузерных движков и владелец единой точки авторизации - одна и та же компания, и ей выгодна удаленная перепись паствы.k4ir05
29.06.2026 23:50Ну браузер тут не подойдёт (но в них есть менеджеры паролей). А так уже придумали решение получше - passkey.
d3d14
29.06.2026 23:50Почему не подойдет? Для каждого сайта сохраняется его seed, далее как в TOTP делается хеширование со временем и опционально seed-ом из запроса, хеш аутентифицирует пользователя.
Браузерный Passkey - как раз что то вроде этого.
inkelyad
29.06.2026 23:50Ну браузер тут не подойдёт
Именно бразуер тут и пойдет. Причем лучше бы не через JavaScript API и HTML элементы управления - а прямо на уровне GUI браузера и HTTP протокола.
Заходишь на сайт, где учетки есть - у тебе на панели браузера оживляется кнопочка 'создать учетную запись'/'войти в учетну запись сайта'. Ты ее нажимаешь, происходит магия - и ты в своей учетке.
Можно было сделать давным-давно, доработав работу с клиентским сертификатами. Но W3C десятилетиями тормозил и в результате получили то что получили.
k4ir05
29.06.2026 23:50И в нативном приложении тогда как заходить? А если браузер сменю?
Магию то любую можно придумать. Но не каждую можно реализовать.
Если я правильно понял ваше описание, то passkeys примерно так и работают. На уровне GUI браузера и клиентскими ключами (почти сертификатами). С сертификатами, подозреваю, много проблем возникнет
inkelyad
29.06.2026 23:50И в нативном приложении тогда как заходить?
Так же. Протокол же подразумевается стандартный. Найтивное приложение просто тем же самым протоколом и воспользуется.
А если браузер сменю?
Другим бразуром - нужен механизм синхронизации данных для входа. Который в конце концов для Passkeys и придумали.
Если я правильно понял ваше описание, то passkeys примерно так и работают.
В моем описании вообще все было независимо от этого. Там ключевое то, что всем этим должен бы заниматься сам браузер вместе с хост системой, а не каждый сайт формочку логина пишет.
A passkeys - похоже работает, да, но все равно GUI/кнопочку 'создать учетку'/'залогинится' оставили на реализацию сайту, и кучке JavaScript кода.
Хотя казалось бы - в META теге или HTTP передовай URL для входа (или вообще его стандартизировать и передавать только флаг 'тут есть учетки') и реализовать правильно один раз в браузере.
С сертификатами, подозреваю, много проблем возникнет
В том виде, как сейчас есть - да. Но это можно было починить и впилить в браузеры.
d3d14
29.06.2026 23:50Сертификаты нафиг не нужны. А то еще начнется возня с удостоверяющими центрами, отзывом и т.п.. Даже если это просто сгенеренные приватные ключи, без УЦ - все равно проще seed для каждого сайта и механизм на принципе TOTP (хеш и все).
Зависимость от браузера, как минимум.
А как вам зависимость от вендора (и наличия связи с ним)? Для браузеров можно и нужно стандартизовать.
inkelyad
29.06.2026 23:50Даже если это просто сгенеренные приватные ключи, без УЦ - все равно проще seed для каждого сайта и механизм на принципе TOTP (хеш и все).
Не вижу разницы, что хранить - то ли общий секрет, со всякой солью, то ли приватную/публичную часть ключевой пары. Ну то есть публичную часть ключа на стороне сайта хранить даже ловчее - ее утечка безопасна, поэтому меньше головной боли с защитой.
А нужная математика все равно в браузерах давно есть.
vikarti
29.06.2026 23:50Passkeys по сути в эту тему движение же (в норме там браузер с google/apple аккаунт же этим занимается но - возможны и достаточно прозрачные варианты).
Этот ФЗ кстати вообще Passkeys расценивает как нарушение или как допустимое?
А если Passkeys через Google account синкаются?
d3d14
29.06.2026 23:50В passkey, насколько помню, есть завязка на вендора. Помимо того, что ключи (или их копии) у него хранятся, так еще челлендж идет как-то через него (могу ошибаться, это уж сильно специфические детали).
vikarti
29.06.2026 23:50И - проблемы:
2FA поддерживать надо и прочие webauthn и еще корректно.
разруливать ситуации с "я блондинко и забыла пароль"
разруливать ситуации что есть люди кто хотят сброс пароля по телефону (а смс между прочим - денег стоят)
разруливать ситуации со спамфильтрами
возможно - разруливать с тем что email может быть много
разруливать ситуации с тем - а что собственно есть корректный e-mail (на хабре была пачка статей...общий смысл вообщем то - полноценно проверить можно только отправив письмо со ссылкой/кодом, во всех иных случаях можно поймать будут те или иные грабли)(иногда вообще доходит до смешного - банк просит заполнить заявку через госуслуги а потом ругается что в ней неправильный e-mail...переданный госуслугами - просто правила проверки - другие). у пользователей бывают хитрозакрученные ситуации с e-mail и часто это надо. Даже если объявить что e-mail это только mail.ru/gmail.com/vk.com - получаем проблемы с corp-почтами (а если это надо?) и с тем например что юзер vasya@xaker.ru будет иметь претензии что технически это VK (и будет прав - насколько я помню сейчас там VK Workspace Mail используется).
с мобилками - либо будут или простые или ОЧЕНЬ простые пароли либо жалобы что на каждый чих (включая телепортацию через полземли) надо пароль вводить либо хотя бы не ломать работу менеджеров паролей (это если они есть еще)(включая на мобильных приложения - у всех приложений на Flutter под андроид которыми приходилось пользоваться - там все сломано, editbox'ы какие то сильно нестандартные). и - нет - бан простых паролей - не особо поможет.
SlimShaggy
29.06.2026 23:50Как я понимаю эта опция есть только если владелец сайта имеет российское гражданство и оно единственное.
Vytian
29.06.2026 23:50Вам же автор специально расписал, что по нынешним законам даже локальная аутентиикация пользователя -- это нифига не пара строчек где-то в /etc/passwd , а дофига регламентов и условий.
Я вот например, от слова срвсем не понимаю, как можно подтвердить отсутствие второго гражданства? Предьявить 200+ справок от различных стран с переводом и апостилем,
или просто корочку сотрудника ФСБ, чтоб отвязались? Ну и ст. 16 149-ФЗ до кучи.
Gutt
29.06.2026 23:50Справкой из МВД. Закон обязывает сообщать о наличии второго гражданства, нет уведомления -- нет гражданства. Правда, это не будет работать с теми гражданами РФ, кто не живёт в России.
JBFW
29.06.2026 23:50А вот это уже из серии "веревку свою приносить или профком выдаст?"
Если это ваш сайт и ваш способ пускать к себе юзеров, а вы - вообще не гражданин РФ, то какое вам дело до законов РФ?
Если полугражданин (с двойным гражданством) - почему этот сайт принадлежит именно вашей российской половине, а не гватемальской?
А если это бизнес-сайт - то и принадлежит он не вам, а российскому юрлицу.Тут как раз тот случай, когда не надо бежать впереди паровоза и спрашивать надзирателей, что именно вам сегодня запрещено, и что вы им должны.
select26
29.06.2026 23:50Если это ваш сайт и ваш способ пускать к себе юзеров, а вы - вообще не гражданин РФ, то какое вам дело до законов РФ?Если полугражданин (с двойным гражданством) - почему этот сайт принадлежит именно вашей российской половине, а не гватемальской?
Cейчас ответ на эти вопросы простой: хочешь работать с россйскими пользователями? Соответствуй россйским реграментам. Нарушаешь - бан РКН.
vikarti
29.06.2026 23:50По факту даже если пользователь пробует соответствовать - все равно бан запросто может получить. Но возможно РКН будет врать что его нет.
AlexanderS
29.06.2026 23:50А ТОТP закроет всю 2FA)
Arioch
29.06.2026 23:50Уже был прецедент, когда майкрософт на своих сайтах запретила все TOTP, кроме своей программы-аутентификаторы...
AlexanderS
29.06.2026 23:50Если контора навязывает свою реализацию, да ещё и со своим приложением - это повод вообще отказаться от этого велосипедства. Как только в яндекс перешли на нормальный стандарт ТОТР и стало возможно использовать в Aegis - я сразу подключил.
Waltasar
29.06.2026 23:50А что делать с уже созданными аккаунтами?
Допустим есть у меня свой сайт- магазин и там 500 аккаунтов и половина по гуглу, половина по эплу зарегистрировались. Куда их девать?
А если ещё и хостинг не в России зарегистрирован...
В общем удачи малому бизнесу, кто ещё цел.
vadimr
29.06.2026 23:50Так это все давно уже прошли на авито и прочих крупных сайтах. Рассылали предупреждения, что скоро ваш логин превратится в тыкву.
achekalin Автор
29.06.2026 23:50Да. Разница в том, что «давно» запретили сам вход, но не было ответственности, если владелец сайта забыл это реализовать. Сейчас ввели штрафы.
Т.е. всё это время как бы давалось на переделки и переход.
webhamster
29.06.2026 23:50Разница в том, что «давно» запретили сам вход
Сам вход на селф-хостингах по логину-паролю. То что пользователь использовал буржуйский email при регистрации, ко входу никакого отношения не имеет, его при входе просто нет.
nukler
29.06.2026 23:50Да, поэтому и многие забросили аккаунты, особенно после того как Авито стал ТРЕБОВАТЬ паспорт и фотку с паспортом а в сноске написано что они могут это передавать третьим лицам, конечно же для нашего блага.
Так что пошли они нахрен.
iamkisly
29.06.2026 23:50половина по гуглу, половина по эплу зарегистрировались. Куда их девать?
емнип, некоторое время назад на пикабу выпиливали доступ через гугл, и судя по тому что я все еще хожу туда деградировать - проблема для сайта тривиальная. они просто взяли из скоупа адрес почты, и попросили сбросить пароль
xna123
29.06.2026 23:50Недавно у одного vps провайдера пропала кнопка авторизации через гугл. А я только через неё и заходил. Уже думал, что потерял доступ к серверам и деньгам на счёте. Но сработало восстановление пароля с указанием почты гугл аккаунта.
sergeybezrukov
29.06.2026 23:50Про ЕСИА - если вы не госорган, не банк и не страховая - вас туда просто не подключат.
В остальном, если используете, например, Keycloak - там локальный пользователь и так создаётся в т.ч. при входе через внешних провайдеров. У него есть логин (чаще всего почта) и при наличии доступа к ней пользователь может установить себе пароль.
К keycloak есть модули для логина через ВК, Мейл, Яндекс и СберИД - лежат на гитхабе, бери и пользуйся.
Короче, если тема логина была изначально продумана - то ничего ужасного не произойдёт. И мотивация у закона в принципе вполне разумная.
M-M-I
29.06.2026 23:50Как по мне, желание залогиниться через ЕСИА на каком нибудь сайте никак не связанном с госорганами/банками\и т.д. это сам себе злобный буратино, и правильно что не подключают.
СберИД туда же..
Мотивация у закона такая же как когда то у внедрения карт МИР, ужасное может произойти с другой стороны, и к этому готовятся
vanxant
29.06.2026 23:50Зашёл написать этот коммент. Крупных коммерсов к ЕСИА пускают очень выборочно, мелких лавочников и частников - вообще никогда. Да что там коммерсов, тот же местный госЖКХ типа горводоканала как правило подключиться не может, хотя им часто по закону положено проверять паспорт, прописку и далее по списку.
sergeybezrukov
29.06.2026 23:50Да. По ЕСИА есть регуляторка - закрытый (в смысле нерасширяемый, а не в смысле секретный) список типов компаний, которые к ней теоретически могут быть подключены.
Подключение к ЕСИА по текущим требованиям (сертифицированный софт, ОС, железо, маршрутизатор, класс защиты КС3) это несколько млн. руб., а не просто "добавить кнопку".
Если нужен подтверждённый паспорт и по закону есть право его смотреть - проще договориться со Сбером и его SberID.
Для SberID есть бесплатный модуль под Keycloak: https://gitverse.ru/playa.ru/keycloak-russian-bank-providers
klimsidorov
29.06.2026 23:50Подключиться можно, но для большинства проектов нецелесообразно, в том числе с экономической точки зрения.
ArtFrost
29.06.2026 23:50Чего-то я не понял эти хитроумные трактовки:
Второе: отделить email как контакт от email как проверки доступа. Адрес Gmail в профиле сам по себе не обязан быть проблемой. Проблема появляется, когда владение этим ящиком становится способом входа или восстановления доступа: magic link, одноразовый код, сброс пароля.
Т.е. я могу быть зареган на тех же госуслугах через gmail.com, но не могу восстановить на нее пароль или что ?)
achekalin Автор
29.06.2026 23:50Если у вас в профиле указан
gmail.comкак контактная почта — это ещё не значит, что вы “авторизуетесь через Gmail”. Госуслуги знают о пользователе гораздо больше: телефон, документы, подтверждённую учётку и т.д.Это по логике.
А как оно вывезет через некоторое время реального применения закона...
vikarti
29.06.2026 23:50Там возможны еще более интересные варианты вида свой/корпоративный домен но не .ru + MX'ы у него не только в России + сама инфраструктура - непонятно где (в смысле доказать что в России не выйдет).
achekalin Автор
29.06.2026 23:50А речь пойдет про владельца: если российский сайт (интернет-магазин или хостинг, с российским юрлицом) работает в правовом поле России, а на сайте кнопка "войти с гуглом" - то кому выставить штраф, найдется.
CitizenOfDreams
29.06.2026 23:50Если читать закон не как злой умысел, а как попытку решить государственную задачу
Что-то я все сильнее подозреваю, что злой умысел и является государственной задачей.
nukler
29.06.2026 23:50Нет нет, нам уже пояснили.
Что проблемы государства выше проблем граждан.
saga111a
29.06.2026 23:50Статья 2
Человек, его права и свободы являются высшей ценностью. Признание, соблюдение и защита прав и свобод человека и гражданина - обязанность государства.
там еще 3я статья есть, но за нее можно статью получить
Derevtso
29.06.2026 23:50Мне кажется, оно давно контрится чем-то в духе "...и, для возможности исполнения обязательств государства по обеспечению прав и свобод, государство вынуждено ограничивать некоторые права и свободы, которые, по мнению государства, мешают возможности государства функционировать и существовать (а значит, исполнять обязательства)".
Что-то в духе логики SkyNet, которая решила завершить все войны, уничтожив человечество.
Gromilo
29.06.2026 23:50Я не понял, я могу использовать gmail как логин или не могу?
В разных материалах по разному говорят.achekalin Автор
29.06.2026 23:50Gmail как адрес в профиле — скорее можно; Gmail как единственное доказательство владения аккаунтом — плохая и потенциально спорная идея.
Тут мы с Вами зависим в т.ч. и от правоприменительной практики, а решения будут принимать в т.ч. и судьи, которые, наверное, не очень различают "email как уникальное имя юзера", и "google-аккаунт как способ доказать (через владение им), что входит именно тот самый юзер".
AndrewBond
29.06.2026 23:50где-то читал, что запрещают не зарубежные адреса, а зарубежные сервисы авторизации/аутентификации. Т.е. использовать адрес gmail для входа можешь, использовать сервис gmail для входа - нет. что логично, использование gmail в качестве локального логина ничем не отличается от любой рандомной строки логина.
Почему-то эта тема повсеместно игнорируется в подобных статьяхachekalin Автор
29.06.2026 23:50Так я о том и написал в ответе - что логин в виде user@gmail.com никак не запрещен, пока он трактуется как уникальная строчка символов. А вот подтверждение, что Вы - это Вы, и есть корень проблемы: если Вы храните в БД сайта строчку логина "user@gmail.com" и строчку хеша пароля - то это локальная авторизация, и подтверждение локально реализовано, а вот если подтверждение прилетает от систем, которые могут сделать бяку (гугла и прочих) - то такое уже низя.
Почему считается, что российские системы авторизации не могут быть большей бякой, чем гугл, и почему считается, что отстрелить всем юзерам гугл принудительно лучшее решение, чем предупредить, но не заставлять (т.е. юзеры бы сами столкнулись, если бы гугл закрыл авторизацию для юзеров из России - но не раньше) - это вот вопросы, которые мы в целях недопущения, обсуждать не станем )
arteast
29.06.2026 23:50В принципе я логику понимаю. Если предупредить, но не заставлять, то чуть менее чем все это проигнорируют полностью. И если вдруг гугл действительно закроет авторизацию (что вполне возможно, ибо авторизацию можно расценивать как IT услуги, а это подсанкционное дело), то одномоментно ощутимый процент населения потеряют доступ к ощутимому количеству ресурсов. И будут вопить, что правительство во всем виновато.
А вот принять законопроект в 2023 году с отложенным на несколько лет запуском - по идее должно было позволить потихоньку (по мере того, как сайты в собственном ритме бы готовились к запуску закона) убрать эту опасность. Но получилось как обычно - уже сайты чуть менее чем все проигнорировали, а теперь спохватились и завопили, что правительство во всем виновато.
Skipy
29.06.2026 23:50Вообще-то вся статья именно о этом. О запрете именно зарубежных сервисов. Я не знаю, сколько раз это было сказано, не считал.
arteast
29.06.2026 23:50Тут еще зависит от трактовки самим сайтом. К примеру, личный кабинет "ТНС энерго" отказывается принимать зарубежную почту в качестве логина... и вообще ввел белый список доменов почты, чтобы не заморачиваться с определением кто есть зарубежный. И они далеко не одиноки в этом.
Что неудивительно, когда выходят статьи типа https://www.consultant.ru/law/hotdocs/81325.html ("одписан закон о запрете регистрации на российских сайтах с помощью иностранных электронных почтовых сервисов").
aax
29.06.2026 23:50На всякий случай:
В понятийном апарате закона(Статья 2. Основные понятия, используемые в настоящем Федеральном законе) не установлена дефениция "авторизации". Равно как № 149-ФЗ не содержит и статических ссылок на ГОСТы например. Классические академические толковые словари (Ожегов, Ушаков, Ефремова) вообще не знают слова «авторизация» для ИТ-систем.
Часть 3 статьи 55 Конституции РФ устанавливает, что права и свободы человека могут ограничиваться только федеральным законом, но № 149-ФЗ пока никак не ввел понятие авторизации одновременно его используя в запретительном контексте.
Фундаментальный принцип правовой определенности (lex certa). Этот принцип требует, чтобы любой запрет или ограничение прав граждан и бизнеса в федеральном законе были сформулированы четко, ясно и недвусмысленно. Если законодатель использует узкоспециализированный технический термин (как «авторизация»), он обязан:
Либо дать прямое определение (дефиницию) в самом законе.
Либо сделать статичную бланкетную ссылку на конкретный нормативный акт или стандарт (например: «в значении, определенном ГОСТ Р 58833-2020»).
-
Попытка суда или Роскомнадзора подтянуть определение «авторизации» из других законов (например, регулирующих банковскую деятельность, связь или госуслуги) для обоснования штрафа по ст. 13.55 КоАП РФ — это классическое применение аналогии закона в карательном (запретительном) праве.
Такой маневр правоприменителя фундаментально противоречит ключевым отраслевым нормам и принципам российского права -
Прямой запрет на аналогию в КоАП РФ(Части 1 статьи 1.1 и части 1 статьи 1.8 КоАП РФ).
Понятию административного правонарушения - Статья 2.1 КоАП РФ и принцип презумпции невиновности (ч. 4 ст. 1.5 КоАП РФ). Противоправным является только то действие, которое прямо запрещено законом. Если закон № 149-ФЗ запрещает «авторизацию» без российских систем, но не раскрывает этот критерий, то состав правонарушения является юридически дефектным.
********************
Итог: формула «Судебного усмотрения»
В судах срабатывает негласный догмат: «Если техническое действие по сути является входом на сайт, значит, это авторизация, РКН в этом уверен!». Юридическую безупречность и требования ч. 3 ст. 55 Конституции суды, насколько я понимаю, сознательно приносят в жертву «государственной целесообразности».
Но эта формула не абсолютна по вышеуказанным причинам.
logran
29.06.2026 23:50Мне, как жителю РБ, так нравятся эти их "ограничения для пользователей из РОССИИ", учитывая насколько пох**стично относится крупный российский бизнес к своей работе и, соотвественно точно не будет пилить 2 раздельных формы авторизации, плюс к тому еще и по умолчанию приравнивая всех пользователй не из РФ к унтерменьшам и блокируя их за VPN...
Тот же Ozon.by значит в РБ под VPN открывается и работает (фиг ли, домен белорусский, юрлицо в РБ, пользователь тоже не их РФ), а вот авторизоваться, *****, нельзя - потому что авторизация БЕЛОРУССКОГО пользователя на БЕЛОРУССКОМ домене ресурса идет через ozon. RU, который воротит носом от VPN, хотя граждан НЕ Россси это казалось бы не должно было касаться...
salnicoff
29.06.2026 23:50Озоновские, похоже, бегут поперед Батьки в пекло, и уже считают РБ девяностым (или каким там?) субъектом...
vikarti
29.06.2026 23:50Как раз если бы они считали девяностым субъектом - наверно и проблемы бы не было - пользователь заходит с IP провайдера этого субъекта с документами этого субъекта. А они похоже считают выборочно.
Белорусы правда тоже...спецкомиссии за ру-номер для уведомлений в банки - поди найди еще на сайте. Белкарт в некоторых случаях (онлайн и иногда в магазинах) как МИР работает но в некоторых - нет, к MirPay подключить нельзя потому что "не МИР" а к БелкартPay нельзя тоже (потому что номер - российский). Получить esim удаленно - нельзя и все тут (притом что белорусские банки знают паспортные данные и их - эти данные устраивают). Ах да - бонусом - с VPN у этих банков тоже...веселье последнее время.
Fragster
29.06.2026 23:50Не нашел в законе разрешения авторизации "по паролю", только телефон, есиа, ебс и сертифицированные SSO. Также этот закон теперь позволит заблокировать вообще весь интернет, в дополнение ко всем остальным законам, позволяющим это, типа закона об Организаторах Распространения Информации или приземления персональных данных (в качестве обеспечительной меры, чтобы пресечь правонарушение).
aax
29.06.2026 23:50Сюрприз-сюрприз: в понятийном апарате закона(Статья 2. Основные понятия, используемые в настоящем Федеральном законе) не установлена дефениция "авторизации". Применяемая в запретительных целях.
k4ir05
29.06.2026 23:50Так пароль нужен для аутентификации, а закон про авторизацию.
Fragster
29.06.2026 23:50В законе написано "если доступ к информации предоставляется пользователям, прошедшим авторизацию, то эту авторизацию владелец ресурса обязан проводить с использованием:..."
https://chatgpt.com/share/6a43768c-f668-83eb-b210-356ea393a9a7
k4ir05
29.06.2026 23:50О, ссылка на авторитетный источник) И, ожидаемо, он налил воды вперемешку с чепухой.
Авторизовать можно и без аутентификации. Например, для просмотра многих статей на хабре никакой аутентификации не требуется. Но это не значит, что не выполняется авторизация, так на запрос некоторых статей выдаётся ошибка 403 без прохождения аутентификации. Доступ к информации определяет сам сайт, без сторонних сервисов. На некоторых сайтах доступ предоставляется по ip или геолокации. Тоже без всякой аутентификации.
Предоставление доступа это и есть авторизация (это то ГПТ правильно угадал).
Перечисленные в законе сервисы - это сервисы аутентификации. Они не решают какими правами обладает пользователь на сайте.
Skipy
29.06.2026 23:50У государства была понятная претензия: не надо строить вход на российские ресурсы так, чтобы ключ от аккаунта лежал у иностранной платформы, которая может изменить правила или отключить доступ.
Вот именно эта претензия вообще непонятная. Это дело ресурса и только его. Не надо причинять гражданам заботу и подвергать их защите. Сделают только хуже. У меня из "правильных" российских систем данные утекали существенно чаще, чем из зарубежных. Правильнее сказать, из зарубежных (кстати, заблокированных за отказ хранить персданные на территории РФ) они вообще не утекали за 20 последних лет.
Понятны другие претензии, и обе они в тексте озвучены. Иностранный сервис сложно закошмарить, особенно крупный. И он отнимает заработок у правильных людей. Не случайно на первом месте в списке правильных сервисов стоит VK - прошлое закошмаривание в их интересах еще свежо в памяти
//sarcasm mode on
Вообще молодцы, каждый раз им поражаюсь!
//sarcasm mode off
lanabel
29.06.2026 23:50Дополню - мало того, что к ЕСИА вас просто так никто не подключит, так ещё и Сбер-ID дюже платный оказался. Когда-то мы отказались от СМС из-за непомерных расходов (и ещё там были приколы с операторами новых регионов), вот Сбер это дороже, чем СМС.
achekalin Автор
29.06.2026 23:50А для меня и до сих пор свежо впечатление, когда я на тогда только появившемся для юзеров cloud.ru должен был авторизовываться через приложение Сбера.
Еще раз - чтобы войти на хостинг, нужно было стать клиентом банка. И каждый раз доставать приложение банка для нового логина. А приложение банка, надо сказать, имеет другие требования по инфобезу и политике - скажем, за рубежом (или через КВН) оно может сказать "фи, какие тут гадкие IP!", и отказаться не только оплатить ЖКХ, но и на хостинг пустить.
Через время cloud.ru, вроде, приделали и авторизацию через почту, но впечатление запомнил - но, будем говорить, это частный случай, что сбер-хостинг через сбер-id пускал.
А вот как быть небольшому сайту, который к себе станет пускать через ID очередного банка, а у банка этого приложение (для авторизации) задурит?
Heggi
29.06.2026 23:50Откуда дровишки?
У нас есть сбер ид и мы за него не платим (ну или я просто не в курсе). Да и на оффсайте сбера написано что бесплатно.
unreal_undead2
29.06.2026 23:50Вопрос ещё как простому пользователю понять, кто реально владеет сайтом и подпадает ли он под этот закон. Посмотрел список мест, где использую гугловый аккаунт - есть некие сомнения насчёт boosty...
Feargin
29.06.2026 23:50У меня сайт ориентирован на международную аудиторию, но я отдельно поддерживал русскую локализацию, потому что хотел, чтобы людям из России тоже было удобно пользоваться сервисом. И вот теперь из-за таких норм я должен убирать кнопку входа, которая для иностранной аудитории абсолютно нормальна и полезна.
Формально можно городить костыли: скрывать кнопку в русской локализации, проверять IP, делать отдельные сценарии для России. Но это все дополнительные расходы, риск ошибок и все равно не гарантия, потому что человек может зайти через VPN, а претензии потом прилетят мне.
В итоге закон, который якобы должен защищать пользователей, на практике подталкивает небольшие международные проекты просто отказаться от русской локализации, не продвигаться в России или выносить российский сегмент на отдельный домен. То есть вместо удобства и доступности получается изоляция, лишняя разработка и меньше нормальных сервисов для самих же пользователей.
Особенно обидно, что речь не о какой-то вредной функции (от сбора данных это никак не защитит), а об обычном входе через Google, Apple ID, GitHub и другие аккаунты, которыми люди давно пользуются. Для маленькой команды это не “заменить одну кнопку на другую”, а отдельный проект с юридическими рисками, миграцией пользователей и постоянным страхом штрафа.
zgwerby
29.06.2026 23:50Интересно, такое же нытьё будет стоять,
еслине если, а когда, скажем, какой-нибудь бразильский, немецкий (читай как "чисто ЕЭсовский") или английский (UK без доминионов и штатов) политикум решит хотя почему вдруг? Офисы и прочее уже лихорадочно импортозамещают в Европе, что собственные СамбаТуруруруНет / Евронет / Теддинет точно так же будут требовать поставщика авторизации на территории Бразилии / евросоюза / Соединенного Королевства, или ВЫ НЕ ПОНИМАЕТЕ, ЭТО ДРУГОЕ?Не помню такого же нытья про "риски и страхи-штрафов", когда вводили на территории ЕС GDPR - или это другое?
firegurafiku
29.06.2026 23:50Не помню такого же нытья про “риски и страхи-штрафов”, когда вводили на территории ЕС GDPR
Вы не помните, а оно было, в том числе и в России.
Замечу ещё, что, в отличие от сабжа статьи, GDPR даёт не только государству новые поводы для штрафов, но и какие-никакие права пользователю.
Feargin
29.06.2026 23:50Любой запрет, приводящий к ухудшению качества жизни простых людей закономерно вызывает недовольство, тут нет деления на политику или регион. Негодование связано с тем, что многие ищут пути и возможности предоставлять людям сервисы для удобной работы, а тут вставляют палки и буквально вынуждают российскую аудиторию оставаться без сервисов.
Не помню такого же нытья про "риски и страхи-штрафов", когда вводили на территории ЕС GDPR - или это другое? - о, нытье было и еще какое, просто в других местах. И это нормально.
Arioch
29.06.2026 23:50А нельзя сделать два проекта? Основной сайт - для международной аудитории и как бэк-энд.
И второй сайт, который предоставляет примерно те же услуги, но за дополнительную оплату и без части функционала (например без этих самых кнопок), который просто будет фронт-эндом к основному? Ну и надо отмечать пользователей: кто хоть раз вошли через второй сайт, разумеется, теряют право входа через основной, поскольку вы больше не можете сказать про них: "я не знал, что он соотечественник"achekalin Автор
29.06.2026 23:50Можно. Но не нужно.
Так Вы затрудните работу госорганов, а это не приветствуется.
Не то сейчас время!
dkeiz
29.06.2026 23:50Не понятно только зачем делать любой сервис в РФ если база пользователей тебе больше не принадлежит, а принадлежит случайным чиновникам. Кроме сервисов со сверхбыстрой ремонетизацией.
Чебурнет без пользователей и без сервисов. Зато отчетов будет нарисовано.
Ghrrm
29.06.2026 23:50У владельца вк разве нет второго гражданства, узбекистандского?
achekalin Автор
29.06.2026 23:50Картинка с лошадью в ванне.
И не спрашивайте о собственности в иностранных юрисдикциях у его родни, ок?
P.S. А кто владелец, у кого есть гражданство-то?
Gutt
29.06.2026 23:50Алишер Усманов. Поскольку у него есть и гражданство Узбекистана, авторизация через VK ID выпадает из списка разрешённых.
UPD: что интересно, в статье Википедии на узбекском указано только российское гражданство. В статье на английском -- оба.
gxcreator
29.06.2026 23:50Сайт принадлежит юрлицу(ПАО) и Усманов даже не самый крупный акционер там.
Ghrrm
29.06.2026 23:50О, точно, раз юр.лицо, то никакой угрозы нет
Маньяка тоже надо оформиться самозанятыми, тогда сразу становится безопасно с ними в одном обществе находиться?
gxcreator
29.06.2026 23:50А если маньяк купит акцию ПАО, то надо компанию сразу закрыть и всех посадить? Что за детский сад, лол
Gutt
29.06.2026 23:50Вы правы, ФЗ требует отсутствия другого гражданства у лиц, прямо или косвенно владеющих более 50 % голосов, приходящихся на доли в капитале, при принятии решений юридическим лицом.
not-allowed-here
29.06.2026 23:50а ведь все проще - есть человек - надо к нему раз и навсегда привязывать номер телефона и вот его уже использовать как единую государственную систему авторизации и доступа к ПД..... с Юр лицами также - ЕДИНСТВЕННЫЙ единый номер телефона Юр.лица - каналов сколько Хотите номер ОДИН и только один.
achekalin Автор
29.06.2026 23:50Только номер ничей - ни человека, ни оператора. Это не паспорт, это не какая-то законом охраняемая единица сущности.
И номеров, увы, у кого-то один, а у кого-то тысячи (а откуда нас спамеры обзванивают), и никого это не смущает.
not-allowed-here
29.06.2026 23:50дык в этом и суть - у нас телефония работает по правилам написанным в 50-х... да что то добавили с приходом сотовой связи но лучше не стало.... а так это сейчас ключевое средство коммуникации которое есть фактический у каждого первого с гигантскими возможностями.
achekalin Автор
29.06.2026 23:50Характерно, что Макс тоже как "самый надежный и непвдучий канал связи" вообще нигде в законе таковым не объявлен, но де-факто выдаётся за таковое.
not-allowed-here
29.06.2026 23:50«Дайте мне средства массовой информации, и я из любого народа сделаю стадо свиней»
«Чем чудовищнее ложь, тем охотнее в неё поверят»
«Мы добиваемся не правды, а эффекта»
Пауль Йозеф Геббельс
в этом к сожалению с 40-вых ничего не изменилось...
C0BHAPK0M
29.06.2026 23:50Что на это ответил Нюрнбергский Трибунал в прошлом веке, по вопросу живому человеку привязать номер?
not-allowed-here
29.06.2026 23:50не цитата но близко к смыслу - "...явно или не явное клеймение заключенных по любым признакам было признано преступлением против человечности."
так что оно УЖЕ здесь, но только то что мы этого невидим...
dmrex
29.06.2026 23:50Честно говоря, запутался. Если у меня есть сайт на ВордПресс, я могу использовать систему для аккаунтов пользователей, встроенный в ВордПресс? Там используется связка логин + электронная почта. Я гражданин РФ, сайт хостится в РФ. Доменная зона .ru
Ian_Bond
29.06.2026 23:50Мы у себя в итоге перешли на вход через Telegram. Конечно, есть юридические вопросы, но пока так сделали. Виджет от Telegram не подошёл по своим причинам, а номера собирать через SMS нам важно, но дорого. Поэтому сделали свою связку - пользователь подтверждает вход прямо в Telegram, без SMS, а номер при этом всё равно можем собрать если нужно. Получилось дешевле и без зависимости от иностранного провайдера, о которой весь сыр-бор. Если кому интересно как технически устроено - погуглите, в сети можно найти готовый SDK под это, не стали велосипед изобретать с нуля
valera_efremov
29.06.2026 23:50telegram gateway, но у некоторых пользователей нет впн, им шлем смс код
Ian_Bond
29.06.2026 23:50Да, справедливо. Мы у себя SMS полностью и не отключали оставили как фоллбэк. Но даже так 70-80% трафика уходит в Тг, экономия уже приличная. Я вообще случайно на них наткнулся, проект прям совсем свежий, только-только запустились. Вот их гитхаб, если интересно https://github.com/bondify-dev/bondify-react
Пишут, что скоро другие платформы будут. Меня сначала смутило, что сайт новый, но SDK открытый, посмотрел, вроде норм
event1
29.06.2026 23:50Первый — заводить для юзеров «свой» аккаунт: логин, пароль, восстановление доступа, база пользователей, свои сессии, свои ошибки, свои утечки. Зато ни на кого не полагаясь, и делая что душа пожелает, если с этим согласится пользователь и потом проверяющий.
У юзеров в любом случае есть свой аккаунт. Всё остальное, что связано с пользователем хранить-то надо где-то. Только вместо хеша пароля там хранится какая-то имба для проверки аутентификации и авторизации.
В целом, всю статью можно сократить до одной фразы: "переводите местных пользователей с иностранным логин-провайдером на местные сервисы"
firegurafiku
29.06.2026 23:50В целом, всю статью можно сократить до одной фразы
Не совсем. Там отчётлива виден призыв сделать локальные, не привязанные ни к чему внешнему способы входа: классическую связку “логин + пароль”, passkey, да хоть по PGP-ключу, чтобы не завязывать весь рунет на ВК и Яндекс.
event1
29.06.2026 23:50Там отчётлива виден призыв сделать локальные, не привязанные ни к чему внешнему способы входа
Это всё призывы в пользу бедных, которые можно смело выкинуть. Информативность статьи от этого не пострадает.
Бизнесы будут делать так как выгодно. И если делать локальный логин дорого, неудобно и чревато проблемами, то никто этого делать не будет. Собственно говоря, именно по-этому oauth с openid и вытеснили локальные логины
firegurafiku
29.06.2026 23:50Это всё призывы в пользу бедных, которые можно смело выкинуть.
Вообще-то, эти призывы — это самое ценное, что есть в статье. Понятно, что крупный бизнес будет исходить из парадигмы “куда вы денетесь”, но кто помельче и поадекватнее, может, задумается и сделает по-человечески.
делать локальный логин дорого, неудобно и чревато проблемами
Локальный логин — это совершенно типовая, стандартная функциональность, которая часто доступна вообще в готовом виде в составе фреймворка/CMS. Что там такого дорогого и неудобного? Трудоёмкость этой задачи ниже, чем прикрутить вход через полдюжины российских провайдеров.
oauth с openid и вытеснили локальные логины
Видимо, у нас разная выборка. Среди множества сайтов, на которых я зареган, входа по почте нет только у одного или двух.
event1
29.06.2026 23:50Что там такого дорогого и неудобного?
хранение базы паролей безопасным образом, восстановление паролей, поддержка пользователей потерявших пароль, разгребание последствий утери базы данных с паролями
Среди множества сайтов, на которых я зареган, входа по почте нет только у одного или двух.
я не точно выразился. Конечно не вытеснил, но повсеместно сопутствует.
RTFM13
29.06.2026 23:50Как я понимаю, локальные пароли следующие под запрещение на очереди (уже частично). Их не запретят в лоб но требования к ним станут невыполнимыми для мелкого бизнеса.
Потому, что конечная цель
завязывать весь рунет на ВК и Яндекс
Arioch
29.06.2026 23:50А вот тут ещё одна хохма. Именно с "завязывать весь рунет на ВК и Яндекс"
Какая гарантия лично у вас, что американский сайт VK.COM соответствует российскому закону о чём-то там? Причем не только в эту минуту (тут вы, гипотетически, можете протестировать, или нанять аудиторов), но что он ВСЕГДА в будущем будет удовлетворять постоянно изменяющемуся российскому закону???
То есть сегодня вы делаете авторизацию через американский сайт VK.COM, через полгода там или в законе что-то меняется - и ВАС наказывают. Не VK.COM, его не за что, а именно ВАС, за старое доверия к этому сайту. "Длящееся преступление" и всё такое.PereslavlFoto
29.06.2026 23:50Какая гарантия лично у вас, что американский сайт VK.COM соответствует российскому закону о чём-то там?
Генеральный директор ПАО «ВК» Владимир Сергеевич Кириенко предоставляет гарантию первому заместителю руководителя Администрации президента Российской Федерации Сергею Владиленовичу Кириенко, своему отцу.
Об исчерпании этой гарантии сообщит ТАСС.
00Kirill00
29.06.2026 23:50Для мелких сайтов самый дешевый путь - просто выпилить кнопку и заставить всех делать сброс пароля по почте. Интеграция с госуслугами или сбер айди стоит слишком дорого для обычного форума
SerjV
29.06.2026 23:50дорого для обычного форума
Для обычного форума, боюсь, статус организатора распространения информации обойдётся гораздо дороже формы аутентификации...
А без статуса ОРИ - пожизненная блокировка без права разблокировки после второй претензии от РКН за размещение неправильного контента...
Arioch
29.06.2026 23:50NNTP, mail-list, FIDO, UUCP с IRC
непривычно, конечно, но деды же как-то жилиPereslavlFoto
29.06.2026 23:50Деды жили в условиях, когда протоколы NNTP и UUCP не оскорбляли никаких чувств.
SerjV
29.06.2026 23:50В то время еще не было этих поправок в закон "Об информации...". А то нынче из перечисленного вами под них, похоже, подпадают всё, кроме одного - да и то пока к Интернету не подключено..
ulisma
29.06.2026 23:50Мне кажется, что этот закон приведет лишь к тому, что многие проекты переориентируются исключительно на международную аудиторию. Там людей больше, денег тоже больше, законодательство (пока, по крайней мере) более понятное и предсказуемое.
А здесь явно не указано, но прослеживается задача сделать авторизацию только через несколько структур (ВК и т. п.). Это тоже дополнительные риски - непонятно, что будет дальше с этими аусами.
Aleksid1
29.06.2026 23:50Чрезмерная зарегулированность просто убивает желание делать сервисы для российских пользователей. Хранение перс. данных только в РФ, ограничения на авторизацию через зарубежные сервисы... Для крупных компаний это дополнительные расходы, а для небольших команд зачастую дешевле просто закрыть доступ пользователям из России и ориентировать продукт только на зарубежных пользователей. Что еще хуже - накопительный эффект бюрократических ограничений, по отдельности еще терпимо, но вместе - уже задумаешь, а оно мне надо?
Простой пример - форум техподдержки или тикеты для саппорта софт продукта.
SergeiMinaev
29.06.2026 23:50Если у меня небольшой инди-проект, нацеленный не только на РФ, но и на иностранную аудиторию, то что я по мнению властей должен делать? Насколько понимаю, убирать вход через условный гугл нужно только для российских пользователей. Но как это проверять? Только не говорите, что по IP - это смешно в условиях повсеместного КВН.
valera_efremov
29.06.2026 23:50А владельцу сайта как достоверно узнавать, что пользователь именно из России или гражданин РФ? Бред
webhamster
29.06.2026 23:50Новое в том, что теперь за нарушение есть отдельная статья КоАП — 13.55:
Проблема в том, что сейчас в Консультанте статьи 13.55 просто нет. Есть статья 13.54 (ред. от 26.06.2026), а дальше идет раздел 14.
achekalin Автор
29.06.2026 23:50Технически Вы правы.
Документ принят 26.06.2026, вступает в силу по истечении 10 дней после дня его официального опубликования (статья 6 Федерального закона от 14.06.94 N 5-ФЗ) - т.е. с 07.07.2026.
Так что Вы будете правы еще неделю. Но, кажется, вряд ли что-то за неделю изменится с таким шансом, что нам не стоит обсуждать тему уже сейчас.
Gorky
29.06.2026 23:50Господи ну как же эти уроды задолбали! Делается ВСЕ чтобы тупо мешать жить бизнесу и обычным людям. Буквально ВСЕ ломают что работало годами без каких-либо проблема.
Arioch
29.06.2026 23:50Закон заставляет убрать иностранные кнопки
А вот не надо было делать эти кнопки вообще.
Была одна кнопка, и было поле ввода, текстовое. Вставляешь туда ЛЮБУЮ гиперссылку на провайдер OpenID и входишь, а уж этих провайдеров было - даже у мессенжеров. И всё, нет кнопки - нечего и убирать.
Можно было бы себе простенький сайт сделать на бесплатном хостинге, который бы меня лично авторизовывал через мой, например, GMail. Бизнес бы видел прокладку-точка-ру и имел бы отмазку.
k4ir05
29.06.2026 23:50О, да ещё и на бесплатном хостинге) А потом хостер случайно профукивает ваш сайтик (гарантий доступности он вам забесплатно вряд ли каких-то даст) и вы уже не сможете зайти в свой банк или любой другой сайт. Да и кто вашему сайту доверять станет?
Такое было возможно когда учётки не представляли никакой ценности. В интернете были только бложики, форумы да мессенджеры с малочисленной аудиторией.
Vasjen
Ох веселье будет ждать разрабов и техподдержку бизнеса, то-то часы списать не куда. Вместо того, чтобы заниматься тем, что принесет бизнесу бабки, мы будем делать так, чтобы государство у бизнеса не отжало под видом
штрафовзаботы о населении.Вот реально, есть же база пользователей, насколько "легко" перенести их на другой доверенный OAuth источник? А сколько будет обращений "Не могу войти, у меня пропала кнопка"? Я уж молчу, сколько людей входит с телефона через гугл/эппл и понятия не имеет, какая вообще у них почта. Они просто жмут кнопку, нажимают на телефона "Да, да, это я" и пользуются сервисом.
not_yours_ne
Короче, минусов нет
yahooyaks
Покричат-покричат и найдут почту! У каждого гугл/эпл аккаунта она есть, так что найдётся полюбому! Люди расслабились, вот чиновники и подбадривают.
vikarti
Кстати - не факт. И она может быть неожиданной и не на gmail. Google умеет быть чисто-identity провайдером.
r23232r
а можна не подбадривать, можно мне самому решать через какое место заходить? (нет)
Vasjen
У эпл есть такой прикол, что когда вы через AppleId входите куда-то, он предлагает скрывать вашу реальную почту. Поэтому для системы вы будете не user@icloud.com, а какой-нибудь asdasd8723sda.75287@icloud.com (рандомный набор символов).
И этот алиас вы в жизни не найдете.
ministr
В айфоне: Настройки > Аккаунт Apple > Вход с Apple > Выбираете приложение или сайт > Внутри ваш алиас
Arioch
вы опоздали, это раньше было
теперь это asdasd8723sda.75287@PRIVATE.icloud.com - и большая часть сайтов его заблокирует через 10, 9, 8, 7, ...
а те, кто не заблокирует, там и через Mailinator можно
Arioch
Одноразовая, завели чтобы включить телефон и забыли на следующий день.
Особенно, когда телефон дают "молодому умному другу/родственнику"
Записываешь на бумажку и почту, и пароль, и инструкцию как входить, пытаешься достучаться, что это нужно и полезно - тупые ускоряющиеся кивания и в глазах отвращение, "опять четырёхглазые хвастаются, какие они умные!" пополам с нетерпением "отдай мне мой новый телефон наконец, сделал своё дело - уходи"
Потом через год-два происходит какая-то фигня, гугло-акк блокируется, и начинаются пляски. Что такой е-mail? Не врите, я не то, что его не знаю, я даже такого слово не знаю.
Если вдруг удаётся адрес почтовый найти - то пароль давно поменялся и был забыт. Или почту заблокировали за не указание телефона. Или почты просто больше нет (привет Сhat.ru, привет NewMail/QIP). И "откуда я могу знать, что вы там настраивали, я вам доверился, потому что я не разбираюсь".
В общем... Нам с вами не понять, но люди действительно почту не найдут. Даже если она когда-то пару месяцев у них была.
Void-Cowboy
ну я сходу вижу держать auth-сервер там где гугл не отвалится и не будет ругаться. А уже токен доступа прокидывать в те ебеня где гугла нет.
Если у вас авторизация таки по почте, а токен oauth просто для сессий, то даже за домены переживать не надо, просто "насквозь" синхронизация по почте и все
leotsarev
В реальности все крупные компании прошли этот путь года два назад. Это запрещено давно, просто сейчас штраф ввели
PikNic
Ага, прошёл этот путь. Угораздило меня в VK Play Atomic Heart купить. Спустя пару лет захотел пройти дополнение и не смог найти игру в аккаунте. Через техподдержку чудом выяснил, что логинился через аккаунт гугл, а теперь надо через специальную ссылку заходить и уже не помню что делать, почту привязывать, что-ли. Ссылка действует несколько часов, поэтому пришлось запрашивать её в техподдержке дважды, а потом мониторить ответы, потому что отвечали очень неспешно. Ни за что в жизни не буду пользоваться этой клоакой больше.
achekalin Автор
Они (ну, боссы), почему‑то уверены, что мы все, как один, побежим авторизовываться через их систему.
Добровольно и с песней!
А Вы - "клоака"! )
Vasjen
Ну крупные да, разумеется. Они проходят регуляно такой путь, причем иногда раньше, чем какой-то законопроект начинают рассматривать, так сказать на перед.
Но сколько есть чего по меньше и попроще, кто далек от крупного бизнеса и у них есть пользователи с такой вот историей входа. Но это проблемы уже мелкого бизнеса, когда они кого-то заботили)
iamkisly
сэкономил - значит заработал, если работа помогает избежать штрафов от меняющейся внешней среды, то это тоже вполне себе плюс
Yuriy_krd
Ловко вы перевернули все с ног на голову - избежать штрафов - это прибыль для бизнеса ? Оррригинально-с... ©
salnicoff
Ну дык по методичке: не «взрыв», а «хлопок», не «падение», а «отрицательный рост»...
iamkisly
Кыш кыш кыш! Ты портишь всю шутку
lz961
а раз прибыль, значит должен быть заплачен налог
Fragster
Ага, замена софта и оборудования на импортозамещенное идет по статье "инвестиции"
TerraV
А если это плюс - плати налоги!
0x200AC
Еврейская семья. Сын приходит домой со школы и радостно сообщает отцу:
- Папа, я сегодня сэкономил 4 шекеля!
- Как, сынок?
- Мне не пришлось платить за проезд в автобусе, ведь я бежал за ним, вместо того чтобы войти в него.
- Ну и дурак ты, сынок! Бежал бы за такси, сэкономил бы 20 шекелей!
vShadow
Избежал штрафа - значит сэкономил, сэкономил - значит заработал, заработал - значит заплати налоги :-)
achekalin Автор
Чья-то экономия на штрафах - это чей-то недособранный % плана по штрафам. А от этого и до более серьезных статей недалеко.
Думаю, так и до штрафа гражданина, если он не был ни разу оштрафован за год не был, может дойти.
00Kirill00
По идее можно просто спарсить email из гуглового пейлоада перед отключением и принудительно заставить юзера задать пароль при следующем входе