Что категорически нельзя (Красная зона)
Использовать кнопки авторизации зарубежных сервисов: Google, Apple ID, GitHub, Facebook и т.д. Зарубежный сервис больше не может выступать провайдером авторизации (IdP / Authorization Server).
Оставлять зарубежные OAuth-кнопки для старых пользователей: Отключение только регистрации новых аккаунтов не сработает. Закон наказывает за сам факт проведения авторизации запрещенным способом.
Прятаться за доменом .com или зарубежным хостингом: Если проект ориентирован на граждан РФ (русский язык, российская специфика услуг), закон применяется. Учитывается взаимодействие с гражданами, а не технические записи ICANN.
Что можно и абсолютно легально (Зеленая зона)
Использовать связку «Логин + Пароль»: Если система написана вами, БД в РФ, а владелец проекта — гражданин РФ (без второго гражданства) или российское юрлицо.
Использовать зарубежные email в качестве логина: Ввод иностранной почты (например, @gmail.com) в поле «Логин» не делает авторизацию иностранной. Почта выступает как текстовый идентификатор, проверку пароля осуществляет ваш сервер.
Отправлять письма для восстановления пароля на любые ящики: Включая зарубежные. Это процесс информирования, а не аутентификация через сторонний сервис.
Использовать российские методы входа: Номера телефонов РФ, Госуслуги (ЕСИА), Единая биометрическая система (ЕБС), российские ID (Яндекс, ВКонтакте, Сбер и т.д.).
Спорные моменты (Серая зона)
Авторизация через Telegram: Получение номера телефона через бота удобно, но валидация происходит на серверах иностранного мессенджера. Юридическая практика не сформирована, риски присутствуют.
Заброшенные проекты и форумы: Старые сайты с неактуальными кнопками входа (например, через Google) попадают под штрафы (от 500 до 700 тысяч рублей для юрлиц). Их необходимо обновить или полностью закрыть авторизацию.
Что сделать прямо сейчас: чек-лист для владельца
Провести аудит интерфейсов: Проверить все экраны входа на сайтах, в мобильных и десктопных приложениях.
Удалить зарубежные SSO-кнопки: Полностью убрать возможность входа через иностранные сервисы.
Настроить миграцию старых пользователей: Тем, кто входил только через зарубежные сервисы, нужно предложить принудительное создание пароля (например, через функцию восстановления пароля на привязанный email).
Обновить документацию: Убрать упоминания о передаче данных зарубежным сервисам авторизации из пользовательских соглашений и политик конфиденциальности, чтобы соответствовать 152-ФЗ.
Все не так уж и страшно, да? :)
tg / max
Комментарии (17)
Как выше прекрасно написано, что отправлять на чужие ящики не запрещено (вот спасибо), но и с телегой все тоже самое, одновременно и ДА и НЕТ.
Кнопка -- авторизоваться через телеграмм -- это редфлаг. Причем даже если вы используете нижеописанный маршрут, или сам сервис авторизации телеграмма.
Просто написав на кнопке ТГ или что-то подобное, вас просто сразу берут на карандаш автогосботы, и это просто технический момент.
Далее, если вы все же выполняете решение "пускать или нет" внешним сервисом -- это неправильно.
Но, если вы регистрируете человека парой email пароль, а потом даете ему возможность "привязать" телеграм, или "подтвердить телеграм" -- это относится уже как указано выше к каналам уведомлений, а не способам и узлам принятия решений.
Вы отправляете коды, а куда вы их отправляете -- да хоть голубями почтовыми. Решение принимаете вы и ваш сервис.
Такие дела малята, все так и работает, все выдыхаем. Потому что даже во времена всех этих авторизаций лучше иметь email пользователя, для него же самого, чем не иметь. Сколько уже было потеряно акков и доступов потому что либо сайт не поддерживает постоянный тюнинг обновлений этих oauth, тех же фейсбуков, одно время там был лютый адище, или же сам фейсбук вот решит побанить приложение авторизации или тебя как пользователя -- и шо ты будешь делать.
Так что закон правильный, хороший, и очень здравый, писали и доводили понимающие контекст люди.
Панику отставить.
- пользоваться gmail ящиком в личных целях - можно
- регистрироваться с помощью gmail на ру сайтах - нельзя
где в итоге правда