Skip to main content
Статус: принято.

​
Контекст

Клиент попадает в свой аккаунт тремя способами: виджет входа Telegram в браузере, подписанная initData Mini App внутри Telegram и произвольный OIDC-провайдер, настроенный оператором. Четвёртый — ссылка для входа — это запасной путь, который запрашивается у бота, а не через веб-форму. Пароля нет. У операторов он есть — internal/adminauth хеширует его, ограничивает частоту попыток, блокирует учётную запись, сочетает с TOTP или passkey и уведомляет о каждом изменении учётных данных, — так что отсутствие пароля на стороне клиента не связано с тем, чего кодовая база не умеет. Это был выбор, и до этой записи он нигде не был зафиксирован, из-за чего выглядел как недосмотр для всякого, кто сравнивал два списка маршрутов. Выбор определяют три факта об этой установке. Транспорта электронной почты нет. Ни SMTP-клиента, ни адаптера провайдера, ни настроек для того и другого. Сброс операторского пароля выдаёт токен только командой, запущенной на сервере, которая печатает его для передачи вне системы, — это допустимо для горстки операторов, которые могут связаться друг с другом, и это не механизм для клиента. Отвечать на вопрос «знаете ли вы этот адрес?» — ровно то, чего кабинет не делает. Именно поэтому ссылка для входа начинается в чате, где клиент уже аутентифицирован, и поэтому контактный адрес, уже зарегистрированный за кем-то другим, отклоняется словами «здесь недоступен» и ничем больше. Форма пароля обязана принять идентификатор и затем либо принять его, либо отвергнуть, а любой вариант этого ответа сообщает постороннему, есть ли такой клиент. Клиент и так приходит с более сильным удостоверением. Telegram и OIDC-провайдер аутентифицируют человека до того, как его увидит Omniflow, и оба способны нести второй фактор, который Omniflow не приходится реализовывать, хранить и восстанавливать.

​
Решение

Кабинет клиента не предлагает пароль, а customer_identities никогда не хранит секрет. Клиент аутентифицируется через сторону, которая уже аутентифицировала его, — Telegram или OIDC-провайдер, — либо по ссылке, которую бот доставляет в чат, уже находящийся под его контролем. Отсутствие пароля — свойство схемы, а не интерфейса. На стороне клиента нет колонки пароля, нет таблицы токенов сброса и нет параметров хеширования. Будущий экран не сможет тихо вернуть пароль: для этого нужны миграция и замена этой записи. Добавление клиентского пароля сначала требует канала электронной почты. Пароль без пути восстановления запирает людей снаружи навсегда, а путь восстановления требует канала доставки, который дойдёт до клиента, по определению не способного войти. Telegram таким каналом не является: пароль сильнее всего нужен именно тем клиентам, у которых Telegram нет.

​
Последствия

Установка обязана включить Telegram или OIDC, иначе в веб не войдёт никто. Это настоящая цена, и она немаленькая. У оператора, продающего на рынке, где Telegram заблокирован, а ни один потребительский провайдер идентичности неприемлем, нет работающей конфигурации, и никакая настройка её не создаёт. GET /v1/account/auth/methods возвращает пустой список, и экран входа прямо об этом говорит, а не рисует форму, которая не может сработать. Утечка базы клиентов не несёт учётных данных для взлома. Нечего плохо хешировать, нечего переиспользовать на других сайтах и не над чем работать офлайн-атаке. Это то свойство безопасности, которое покупает решение, и оно стоит больше, чем удобство, которого стоит. Целых категорий работы просто нет. Ни проверки по спискам утечек, ни индикатора надёжности пароля на стороне клиента, ни настройки блокировок, ни политики срока жизни токена сброса, ни пути уведомления об изменении учётных данных, ни сценария поддержки «ваш пароль изменён». Сброс пароля — крупнейшая отдельная категория обращений в потребительских продуктах, и здесь её нет целиком. Восстановление доступа — не наша история. Клиент, потерявший доступ к аккаунту Telegram или к своему провайдеру идентичности, восстанавливает его там, а не здесь. Передача в поддержку при конфликтах личности и необратимых действиях ведёт к оператору, и ответ поддержки — помочь подтвердить контроль над вышестоящим аккаунтом, а не выдать новое удостоверение.

​
Пересмотреть, когда

  • Транспорт электронной почты существует и является поддерживаемым, настраиваемым каналом, а не задокументированным отсутствием. До тех пор пароль — это удостоверение без пути восстановления, что хуже отсутствия пароля.
  • Конкретная установка показывает клиентов, которых она не может впустить — не предпочтение паролей, а рынок, где недоступны ни Telegram, ни какой-либо приемлемый OIDC-провайдер. Это и есть наблюдаемое условие, и именно оно оправдает оплату всего стека выше.
Заметьте: подтверждённый адрес электронной почты уже хранится как контактный канал и уже используется для согласий и настроек доставки. Условие — не его существование, а транспорт, способный в него отправить.

​
Связанное

  • Кабинет клиента — три способа и то, что каждый отклоняет.
  • Провайдеры OIDC — настройка провайдера идентичности для клиентов и операторов.
  • Безопасность — стек операторских учётных данных, который эта запись намеренно не повторяет.
  • Приватность — что установка хранит о клиенте и чего не хранит.