🔑 Безопасность · по документации

Вход в Telegram без кода: как работают passkeys

27 августа 2026·Чтение ~7 мин

Passkey — это второй ключ от аккаунта, а не замена первому. Он пускает внутрь по отпечатку или PIN-у устройства, но код из SMS никуда не девается: в FAQ Telegram написано прямым текстом, что с passkey код всё ещё можно запросить и войти им. Ключей на аккаунт — не больше пяти. Облачный пароль спросят всё равно. А сторонние клиенты passkey не поддерживают вообще, и на это у сервера есть отдельная ошибка с дословной формулировкой.

Что такое passkey и когда он появился в Telegram

Passkey — это пара ключей. Приватный лежит на устройстве, в защищённом хранилище вроде TEE-анклава, и оттуда не уезжает. Публичный уходит на серверы Telegram. При входе сервер присылает challenge, устройство подписывает его приватным ключом, сервер проверяет подпись публичным — сходится, значит пускаем. Стандарт называется WebAuthn, Telegram его не изобретал, и документация первым делом отправляет читать первоисточник.

Пользователю фича приехала 12 декабря 2025 года. В протоколе она задокументирована в Layer 225 — там же, где появились машиночитаемые permalink-и конфигурации и справочника ошибок. В интерфейсе живёт по пути «Настройки → Конфиденциальность → Passkeys», и завести ключ можно только с устройства, где вы уже вошли.

Как заводится passkey по шагам протокола

Регистрация — два вызова с браузерным колдовством посередине.

account.initPasskeyRegistration отдаёт JSON с единственным ключом publicKey — это PublicKeyCredentialCreationOptions из стандарта, только бинарные поля закодированы в base64url.
Разобранные опции уходят в navigator.credentials.create в браузере или в аналог на другой платформе. Оттуда возвращается PublicKeyCredential.
Ответ раскладывается в inputPasskeyResponseRegister — туда идут clientDataJSON и attestationObject, — а тот заворачивается в inputPasskeyCredentialPublicKey вместе с id и raw_id.
Готовая конструкция уезжает в account.registerPasskey. Метод возвращает конструктор passkey с человекочитаемой информацией о том, что получилось.

Два ограничения, о которые спотыкаются на первом шаге. Ошибка 403 ACCESS_DENIED означает, что аккаунт деактивирован либо это бот или служебный профиль. Ошибка 406 FRESH_RESET_AUTHORISATION_FORBIDDEN — что с момента входа в текущую сессию не прошли сутки; тот же код закреплён ещё за тремя методами, и разбор этого суточного окна у нас отдельной статьёй.

Что видно в списке ключей

Список приходит методом account.getPasskeys — вектором конструкторов passkey. Полей всего пять, и два из них полезны не только владельцу.

Поле	Что в нём
`id`	Идентификатор ключа — им же его потом и удаляют
`name`	Название ключа
`date`	Когда ключ создан
`software_emoji_id`	Кастомная эмодзи-иконка. В документации сказано, что она обычно совпадает с иконкой менеджера паролей
`last_usage_date`	Когда ключом в последний раз входили

Поле, ради которого стоит открыть список. last_usage_date читается так же, как date_active у сессии. Наличие ключа само по себе говорит мало; дата последнего входа говорит, живой он или лежит мёртвым грузом. А software_emoji_id заодно показывает, каким менеджером паролей ключ сохранён — iCloud, Google или чем-то третьим.

Удаление — account.deletePasskey с идентификатором ключа. Никаких окон ожидания у этого метода в справочнике не закреплено.

Почему passkey не работает в сторонних клиентах

В документации это написано без обиняков. Официальные приложения используют telegram.org как RP ID при создании и запросе ключей. А сервер запрещает создавать passkey с любым другим RP ID. Вывод в тексте сформулирован прямо: неофициальные приложения не смогут пользоваться passkey вообще.

В машиночитаемом справочнике ошибок это подтверждено кодом PASSKEY_ORIGIN_MISMATCH и дословным описанием: сторонние клиенты сейчас не поддерживают passkey даже при смене origin. Обратите внимание на «даже при смене origin» — обходной путь закрыт заранее и явно.

Дальше деталь, которая вылезает только при разборе справочника по методам. Ошибка закреплена ровно за двумя методами: account.registerPasskey и auth.finishPasskeyLogin. За account.getPasskeys и account.deletePasskey её нет — у этих двух в списке вообще только служебные коды про бизнес-подключение и незарегистрированный ключ авторизации. То есть по документации сторонний клиент не может завести ключ и не может им войти, а вот прочитать список и удалить лишнее origin-проверка не трогает. На мой взгляд, это логично: запрет стоит там, где ключ создаётся или предъявляется, а чтение своего же списка ничем не отличается от чтения списка устройств.

Ещё два факта из того же справочника. Все шесть passkey-методов лежат в списке user_only — ботам они недоступны. А auth.initPasskeyLogin и auth.finishPasskeyLogin перечислены среди методов, которые можно вызывать без авторизации: иначе вход по ключу был бы невозможен.

Как выглядит сам вход по ключу

Начинается всё с auth.initPasskeyLogin, и метод принимает api_id с api_hash. За ним в справочнике закреплена ошибка API_ID_INVALID — идентификатор приложения проверяется на самом первом шаге, ещё до того, как пользователь коснулся сканера отпечатка. Дата-центр, в который ушёл этот запрос, клиент обязан запомнить.

Дальше navigator.credentials.get предлагает выбрать ключ — и это же выбор аккаунта, в который вы входите. В ответе есть поле user_handle, и документация велит разбирать его форматом %d:%lld. Под этим прячется пара «идентификатор дата-центра и идентификатор пользователя», разделённая двоеточием. То есть passkey несёт в себе и номер DC, на котором живёт аккаунт, и его user ID.

Отсюда два следствия, прописанных явно. Если клиент уже залогинен под тем же user ID, нужно попросить выбрать другой ключ и начать заново — войти вторым входом в тот же аккаунт через passkey нельзя. И если DC ключа не совпал с тем, куда ушёл первый запрос, финальный auth.finishPasskeyLogin отправляется в «родной» дата-центр аккаунта, а поля from_dc_id и from_auth_key_id заполняются данными первого соединения.

На финальном шаге сервер может ответить двумя вещами: SESSION_PASSWORD_NEEDED — включена двухэтапная проверка, дальше обычный сценарий с паролем; PASSKEY_CREDENTIAL_NOT_FOUND — такого ключа на сервере нет, например его удалили.

Что passkey не отменяет

Маркетинговая формулировка «вход без SMS» читается как «SMS больше не работает». Это не так, и расхождение стоит проговорить по пунктам.

Код из SMS остаётся. В FAQ дословно: с passkey всё ещё можно запросить код, чтобы войти. И прямая рекомендация — держать под аккаунтом актуальный номер, который контролируете вы. В посте с анонсом это сформулировано ещё жёстче: не спешите выбрасывать SIM-карту.
Облачный пароль остаётся. На странице документации это повторено трижды, и это не случайность: пароль спрашивают и при входе по ключу. Про то, что именно он и есть настоящий замок, — в разборе списка активных сессий.
Номер остаётся основой аккаунта. Passkey никак не меняет того, что аккаунт держится на номере. Что с этим номером можно и нельзя сделать — в статье про два аккаунта и перенос номера.

Так что passkey — это защита от перехвата кода и удобство в поездке, где SMS не доходит. Про то, сколькими способами вообще приезжает код и почему он иногда не приезжает, у нас отдельный разбор типов доставки.

Сколько ключей можно завести и почему раздела может не быть

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

passkeys_account_passkeys_max — максимальное число ключей на один аккаунт. В примере ответа, опубликованном на странице конфигурации, стоит 5. Оговорка обязательная: это пример из документации, а живое значение клиент получает с сервера при запуске, и Telegram такие числа меняет молча.

settings_display_passkeys — флаг, который включает поддержку. Формулировка в документации: поддержку passkey следует включать, только если этот ключ равен true. В опубликованном примере конфигурации он равен false. Отсюда простое объяснение для человека, который не нашёл раздел у себя: фичу может просто не раздать сервер.

Есть и обратный механизм — в телеграмме сервер умеет сам предлагать завести ключ. В списке подсказок есть SETUP_PASSKEY с описанием «приглашает пользователя настроить passkey». Рядом, для сравнения, живёт SETUP_LOGIN_EMAIL_NOSKIP — подсказка, которую нельзя пропустить и которая полноэкранно блокирует приложение. У passkey такого режима нет: только приглашение.

Чего в документации нет

Здесь честно перечислю то, что при сверке не подтвердилось, — чтобы это не выглядело как умолчание.

PASSKEY_CREDENTIAL_NOT_FOUND описана на странице про passkey, но в машиночитаемом справочнике ошибок её нет. Проверено грепом по файлу 27 августа 2026 года.
SESSION_PASSWORD_NEEDED в справочнике есть, но с пустым списком методов, хотя страница про passkey называет её среди ответов на завершение входа. Две части документации расходятся, и я фиксирую это как есть.
Что происходит с ключами при смене номера, сбросе облачного пароля или удалении аккаунта, в открытой документации не описано. Выдумывать не буду.

Что из этого следует, если аккаунт вы купили

Для работы с покупными аккаунтами всё это сводится к нескольким пунктам.

Passkey добавился в список того, что проверяют после входа. Раньше чек-лист заканчивался сессиями и приватностью, теперь к ним добавился список ключей. Запросить его и удалить лишнее — два вызова, и origin-проверка им, судя по справочнику, не мешает.
Через session и tdata ключ не завести. Аккаунт в формате session+json — это сторонний клиент, а им passkey закрыт. Чем отличаются форматы и что лежит в json-сайдкаре, разобрано в сравнении TDATA и session+json.
Индивидуальный api_id важен и здесь. Он проверяется на первом же шаге входа по ключу, а в списке устройств виден отдельным полем. Общий идентификатор на весь флот — плохая идея по совокупности причин, и это одна из них.
Пароль ставьте первым делом. Он не ждёт суток, работает против входа по одному коду и не отключается никакими passkey. Признаки возраста и траста аккаунта, на которые стоит смотреть заодно, собраны в типах аккаунтов.
Заложите сутки на первый день. Первые 24 часа после входа сервер не даст ни вычистить чужие сессии, ни зарегистрировать ключ. Планировать «аккаунт к вечеру» под эту механику не получится.
Проверьте приватность сразу. Она приезжает вместе с аккаунтом — что там можно закрыть и чем это отзовётся, в разборе четырнадцати ключей.

У нас каждый аккаунт проверяется вживую в момент выдачи — коннект через прокси, проверка ограничений, ответ служебного бота. Вопрос «живой ли он» этим закрывается. Вопрос «кто ещё может в него войти» — нет: на него отвечают список устройств и список ключей, и смотреть их надо своими глазами. Держать связки стабильно онлайн помогают резидентные прокси, а под мобильные сценарии — мобильные 4G/5G.

И про сбор, раз уж речь про то, что видно снаружи. Passkey — это ваша сторона аккаунта, в чужих чатах он не проявляется никак. Там работают другие срезы: участники чата, активные писавшие за период и комментаторы канала. Расхождение между ними обычно говорит о чате больше, чем каждый срез по отдельности.

Частые вопросы

Можно ли войти в Telegram без кода из SMS?

Да, если на аккаунте заведён passkey. Тогда вход идёт через PIN или биометрию устройства, а код не запрашивается. Но SMS при этом не отключается: в FAQ Telegram прямо сказано, что с passkey код всё равно можно запросить и войти им. Passkey добавляет способ входа поверх номера и не заменяет его.

Сколько passkey можно привязать к одному аккаунту?

Ограничение задаёт ключ конфигурации passkeys_account_passkeys_max. В примере ответа, опубликованном на странице конфигурации Telegram, он равен пяти. Реальное значение клиент получает с сервера при запуске, и Telegram меняет такие числа без анонса.

Почему в моём Telegram нет раздела с passkey?

Поддержку включает серверный флаг settings_display_passkeys: в документации сказано, что интерфейс passkey следует показывать, только если этот ключ равен true. В опубликованном примере конфигурации он выставлен в false. Второе объяснение проще — вы пользуетесь неофициальным клиентом, а они passkey не поддерживают вообще.

Работает ли passkey в сторонних клиентах и userbot-библиотеках?

Нет. Официальные приложения используют telegram.org как RP ID, а сервер запрещает создавать ключи с любым другим. На попытку прилетает ошибка PASSKEY_ORIGIN_MISMATCH с дословной формулировкой: сторонние клиенты сейчас не поддерживают passkey даже при смене origin. Ошибка закреплена ровно за двумя методами — регистрацией ключа и завершением входа по нему.

Отменяет ли passkey облачный пароль?

Нет. На странице документации это повторено трижды: если у аккаунта настроена двухэтапная проверка, пароль спросят и при входе по passkey. Сервер отвечает на завершение входа ошибкой SESSION_PASSWORD_NEEDED, и дальше идёт обычный сценарий с паролем.

Что делать с passkey, если аккаунт куплен?

Запросить список ключей методом account.getPasskeys и удалить чужие через account.deletePasskey. Эти два метода, в отличие от регистрации и входа, не помечены в справочнике ошибкой про origin. Заодно посмотрите дату последнего использования у каждого ключа — она приходит отдельным полем и сразу показывает, пользовались им или нет.

Схема методов, поля конструктора и порядок входа — со страницы документации о passkey, привязка ошибок к методам и дословные описания — из машиночитаемого справочника ошибок (Layer 227), значения ключей конфигурации — со страницы конфигурации (Layer 225), пользовательские формулировки — из FAQ Telegram. Всё снято и сверено 27 августа 2026 года. В телеграмме такие вещи меняются без анонса, так что если читаете это сильно позже — перепроверьте по первоисточнику.