Авторизация в мобильном приложении требует проверки смены телефона, выхода и отзыва сессии

Что именно покупает компания, когда заказывает авторизацию? Способ входа подтверждает пользователя, а сессия позволяет ему продолжать работу без повторного кода. У этих частей разные условия приёмки.

OWASP выделяет доступ к данным после завершения сессии в отдельную мобильную слабость. В проверку входят серверный доступ, токены и сохранённые данные на устройстве. Одной кнопки «Выйти» для этого недостаточно.

Собственный пример у нас вебовый: ученики vibecoding.ru входят по ссылке из письма. Инженер ведёт машину агентов, её работу видно в открытой истории разработки. Своего клиентского кейса мобильных сессий у нас нет.

Смена аппарата и смена номера телефона требуют разных проверок. В первом случае клиент получает новую сессию в прежнем аккаунте. Во втором нужно подтвердить право изменить средство входа, не потеряв историю и покупки.

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

Все примеры ниже являются сценариями приёмки. Они задают ожидаемое поведение продукта, а не описывают результаты проведённого нами мобильного испытания.

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

Старый аппарат не обязан терять доступ при каждом новом входе. Сервис может разрешать несколько устройств, CTO выбирает это правило до разработки. Но команда должна показать, как клиент отзывает доступ потерянного или проданного аппарата.

Восстановление без старого номера нельзя сводить к отправке SMS на него же. Для этого пути заранее определяют подтверждение владельца и работу поддержки. Подрядчик не должен молча создавать новый аккаунт вместо восстановления старого.

Выход не проверяют по появлению формы входа. На испытании сохраняют тестовую сессию, выходят и повторяют защищённый запрос с прежними данными доступа. Сервер должен отказать в пределах принятого правила завершения сессии.

Локальные данные проверяют отдельно: заказ не должен оставаться доступным после перезапуска, возврата кнопкой «Назад» или входа другого тестового пользователя. Отказ сервера не очищает уже сохранённый экран.

Выход без сети требует отдельного состояния. Приложение закрывает локальный доступ, а невозможность завершить серверный отзыв показывает по принятому правилу. Надпись «Вы вышли со всех устройств» до подтверждения сервером даёт клиенту ложное обещание.

Токен доступа разрешает запросы, а токен продления позволяет получать новый доступ. Отзыв второго не всегда закрывает первый сразу: это прямо разобрано в RFC 7009. Для бизнеса разница означает, что потерянный аппарат ещё некоторое время может читать данные.

Официальная документация Firebase показывает этот разрыв на реализации. Отзыв токенов продления и проверка отзыва уже выданного ID token являются отдельными действиями. Это пример устройства системы, а не рекомендация выбрать Firebase.

Срок прекращения доступа фиксируют в приёмке. Если бизнес требует отказа сразу после подтверждения отзыва, команда должна показать его на защищённом запросе. Фраза «JWT скоро истечёт» не доказывает выполнение такого требования.

Удалённый отзыв не может сам стереть данные с отключённого от сети телефона. Поэтому локальное хранение и доступ к кешу обсуждают заранее. Для работы агента используют тестовые данные без клиентов.

При ротации токен продления заменяется после использования. RFC 9700 описывает обнаружение повторного использования, альтернативой служит привязка токена к экземпляру клиента. Название механизма не заменяет проверку поведения.

В матрицу стоит добавить параллельные запросы и повтор после сетевого сбоя. Если два запроса пытаются продлить сессию одновременно, клиент не должен застревать в цикле входа. Это отдельный сценарий разработки, который команда проверяет на своей реализации.

Веб-вход учеников появился 8 сентября 2026 года, PR #2186. Пользователь получает письмо и открывает ссылку, вход и выход реализованы в веб-кабинете. Это собственный опыт разработки, его нельзя выдавать за мобильный кейс.

При ревью цепочки доступа нашли другую границу: выданное право ещё не означает доставленное письмо. Ошибка отправки могла оставить пользователя без ссылки, а повтор события не исправлял её. Этот дефект нашли до боевых продаж.

Серверные права и восстановление пути проверяют независимо. У нашей машины были ошибки в обоих местах. Про ответственность за ошибки агентов есть отдельный разбор, здесь нужны последствия для приёмки входа.

ИИ-агенту передают ожидаемое поведение до написания кода. В задаче для ИИ-агента указывают, как идентифицируется аккаунт, какие устройства остаются активными и когда старый доступ должен перестать работать. «Сделать авторизацию» оставляет эти решения исполнителю.

Постоянные ограничения входят в правила для ИИ-агентов: проверка прав на сервере, запрет выдавать секреты в журнал и работа с синтетическими аккаунтами. Сценарии конкретного продукта остаются в задаче и тестах.

Инженер принимает результат отдельно от отчёта агента. Он повторяет матрицу на старом и новом устройстве, смотрит отказ сервера и локальный экран. Зелёная проверка первого входа не закрывает приёмку выхода со всех устройств.

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

Следующий шаг для руководителя находится на странице разбора задачи. Этот адрес сейчас ведёт к условиям работы и записи на звонок.

Передать реализацию можно через разработку по подписке. Мобильные сессии, восстановление и выход со всех устройств можно поставить в очередь проекта.

1. Новый аппарат должен вернуть прежний аккаунт, сверьте историю и оплаченные права.
2. Выход закрывает серверный и локальный доступ, повторите запрос и перезапуск приложения.
3. Отзыв проверяют на уже выданном доступе и его продлении, задайте допустимое окно отказа.
4. Потерянный аппарат не участвует в восстановлении, испытайте этот путь отдельно.
5. Исправление завершено, когда сценарий поломки стал повторяемой проверкой следующего выпуска.