Восстановление доступа и запасной ключ

Регистрация passkey полезна только вместе с понятным способом продолжить работу при потере устройства. В этом уроке разберём учебное восстановление без почтового сервера и автоматической службы подтверждения личности. Основной маршрут — заранее зарегистрированный второй ключ; запасной — сохранённый локальный пароль fixture-пользователя. Новый результат не является универсальной системой recovery: мы составим конкретную последовательность доступа и отзыва и покажем, какие состояния остаются действующими после удаления credential.

Состояние lesson-13 добавляет recovery.md. Node-код и OIDC-контракт не меняются. Приложение принимает тот же sub независимо от того, каким разрешённым способом provider подтвердил пользователя. Никакие ключи не регистрировались и не удалялись при подготовке. Пользовательские данные вымышлены, а пароли указаны только для изолированной лаборатории. Реальный сервис потребует собственных процедур, минимизации полномочий администраторов и аудита действий; текст курса не разрешает автоматически применять fixture-пароли к настоящим аккаунтам.

Второй ключ до потери первого

Пока основной способ доступен, ещё раз откройте /register-passkey и зарегистрируйте второй credential через Keycloak. Дайте названиям смысл: «Основной ноутбук» и «Резервный аппаратный ключ» полезнее двух одинаковых строк «Passkey». Для настоящей независимости запасной способ должен переживать тот отказ, от которого вы защищаетесь. Два credential в одном потерянном устройстве не помогут при его утрате. Два синхронизированных ключа в одном облачном аккаунте тоже могут зависеть от общего восстановления этого аккаунта.

Нужно определить конкретную модель отказа. Устройство сломалось, браузерный профиль удалён, cloud-account недоступен, аппаратный ключ утрачен или человек подозревает компрометацию — разные ситуации. Второй отдельно хранящийся аутентификатор помогает лишь некоторым из них. Мы не обещаем, что слово «резервный» автоматически делает любую копию независимой. Такой разбор пригодится и для других веб-сервисов: схема восстановления должна соответствовать наблюдаемому сбою, а не только добавлять ещё одну красивую кнопку в настройках.

Проверять запасной вход желательно заранее в контролируемой среде, понимая состояние SSO. Если provider уже помнит пользователя, обычный redirect не доказывает, что резервный ключ применялся. Нужно начать предусмотренный новый маршрут подтверждения и увидеть действие аутентификатора. Эти сценарии здесь не выполнялись. Для статьи достаточно описанного порядка и границы, а не выдуманного снимка «ключ успешно проверен». В реальном сопровождении такая проверка должна быть документирована безопасно, без сохранения чувствительного материала устройства.

Резервный пароль и его цена

У fixture-пользователей остаётся исходный пароль. Он позволяет вернуться в Account Console, если оба passkey недоступны, но пароль сам является другим способом подтвердить ту же учётную запись. Значит, общая устойчивость к фишингу не определяется только сильным основным ключом. Слабый запасной способ способен обойти его преимущества. В нашей лаборатории это сознательное упрощение для понимания процесса, а не совет всем реальным людям держать одинаковый публично известный fallback.

Пароль нельзя заменять специальной общей строкой администратора, секретным query-параметром или endpoint /recover?username=anna. Такой обход делает имя пользователя достаточным для входа и разрушает всю цепочку. При потере всех факторов нужна отдельная процедура установления личности. Возможно участие доверенного администратора, но его решение должно иметь основание, ограничения и запись события. Учебный оператор может сбросить вымышленный пароль в стенде; это не означает, что аналогичная операция у настоящего сервиса допустима после одного сообщения в чате.

В серии нет SMTP, password-reset email и recovery codes. Не нужно писать, что «письмо уже отправлено» или «сохраните одноразовые коды» при отсутствии такой реализации. Keycloak поддерживает разные возможности восстановления, но включение каждой требует согласованной конфигурации, маршрута и политики. Мы оставляем результат узким и реальным: второй credential, известный локальный запасной пароль и действия оператора. Такой предел полезнее неполного списка популярных функций, который читатель примет за готовую систему.

Отзыв утраченного credential

После входа запасным способом откройте Account Console и удалите именно credential потерянного аутентификатора. Различимые названия уменьшают риск удалить рабочий резервный ключ. Перед удалением нужно убедиться, что другой способ доступен, иначе человек может сам закрыть последний путь входа. Это не операция Node-приложения; управление ключами остаётся у provider. «Пропуск» не читает и не сохраняет приватный ключ, поэтому он не может самостоятельно восстановить утраченный credential или создать его копию из своей Map.

Если устройство могло хранить SSO-cookie, удаление passkey не обязательно завершит уже существующие provider-сессии. Ключ нужен для нового подтверждения, а действующая сессия может продолжать существовать по своим правилам. Поэтому дополнительно рассматривается завершение сессий пользователя у Keycloak. Это отдельное действие с отдельным эффектом. Нельзя обещать полный отзыв, удалив лишь credential: разные формы доступа имеют разные сроки и носители. Такое различие напрямую продолжает урок о локальном и SSO-выходе.

Локальные Map-сессии Node тоже не исчезают мгновенно только из-за удаления ключа. В этой лаборатории они ограничены пятнадцатью минутами; renew может завершить их раньше, если refresh отклонён. Back-channel logout отсутствует. Поэтому recovery.md прямо описывает остаточное окно доступа. Для реального продукта с требованием немедленного отзыва понадобится согласованный механизм уведомления приложений и очистки общего store. Нельзя скрывать эту границу за обещанием «удалите ключ, и злоумышленник сразу выйдет везде».

Работа оператора и журнал

Администратор identity-сервера имеет сильные полномочия, поэтому его учётная запись должна быть отдельной и защищённой. Редактор editor не получает права сбрасывать чужие факторы только благодаря своей роли сайта. Для реального восстановления важно различать заявку пользователя, установление личности и выполненное изменение. Журнал может содержать время, тип действия, безопасный идентификатор объекта и исполнителя, но не пароль, полный токен или содержимое резервных кодов. Сохранение секретов «для аудита» само создаёт новый способ компрометации.

Полный recovery.md ниже задаёт последовательность самостоятельного разбора. После потери учебного основного ключа ожидается вход запасным, удаление утраченного credential и согласованное завершение provider-сессий. Ничего из этого автором не выполнялось. Отдельно проследите локальную сессию второго приложения: её срок и refresh могут отличаться от момента удаления ключа. Последний урок объединит HTTPS, хранение, claims, журнал и конфигурацию в эксплуатационный контракт, чтобы лаборатория не была случайно выдана за уже готовый публичный сервис.

Полный файл recovery.md из состояния lesson-13:

# Учебное восстановление

1. Пока основной ключ доступен, зарегистрируйте второй независимый ключ через /register-passkey и дайте различимые названия в Account Console.
2. Оставьте исходный учебный пароль как запасной способ входа. Наличие пароля снижает устойчивость всей учётной записи к фишингу; это сознательная граница лаборатории, а не рекомендация использовать общий пароль в реальной системе.
3. При потере устройства войдите вторым ключом либо своим резервным паролем. В Account Console удалите credential утраченного аутентификатора. В Admin Console завершите активные пользовательские сессии, если устройство могло содержать SSO cookies.
4. Удаление ключа и завершение Keycloak SSO не удаляет немедленно локальные сессии Node. Они ограничены 15 минутами; с урока 11 попытка refresh может завершить их раньше. Синхронный back-channel logout здесь отсутствует.
5. При потере всех факторов не создавайте «аварийный» публичный endpoint. Учебный администратор может назначить новый временный пароль после установления личности; в реальной системе нужна независимая процедура и аудит.

Ни один шаг не выполнялся автором. Описание является сценарием для самостоятельной лаборатории, без настоящих аккаунтов.

Оглавление серии · Исходники всех шагов · Учебные маршруты

Пример остаётся локальным черновиком. При подготовке он не выполнялся; все описанные эффекты являются ожидаемыми, а не результатами запущенных проверок.