Призрачные входы и ошибки работы сессий

Почему пользователи думают, что они всё ещё в системе

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

Такая реакция понятна. Большинство пользователей ожидают один ясный результат: либо они вошли, либо вышли. Реальное поведение сессий часто грубее.

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

Поведение с refresh token усугубляет ситуацию. Экран может на мгновение выглядеть как будто пользователь вышел, а затем refresh token в фоне получает новый access token, и аккаунт снова появляется. Большинство людей читают это как серьёзный баг или доказательство того, что кто‑то ещё имеет доступ. Часто никто не взламывал аккаунт. Приложение просто следовало собственным правилам.

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

Этот разрыв между ожиданиями людей и фактической работой системы — причина, почему призрачные входы кажутся такими тревожными. Пользователь видит, что аккаунт вернулся после выхода, поддержка видит сессию, которая «должна была» исчезнуть, и все начинают думать о компрометации. Иногда это реальная проблема безопасности. Часто — просто поведение сессий, которое никто толком не объяснил.

Что такое сессия на самом деле

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

Эта память обычно реализуется двумя способами. В вебе браузер часто хранит cookie, которое автоматически отправляет сайту. Access token выполняет похожую роль, но приложение обычно управляет им напрямую и посылает с каждым запросом. Для пользователя оба варианта означают одно и то же: «я вошёл». Для поддержки и инженеров они разные.

Cookies обычно живут внутри одного профиля браузера. Если кто‑то вошёл в Chrome, а затем открыл Firefox, это часто отдельная сессия. Access token может храниться в мобильном приложении, десктоп‑приложении или single‑page приложении. Поэтому один и тот же аккаунт может одновременно быть активен в нескольких местах. Ноутбук, телефон и планшет могут быть одновременно залогинены.

Refresh token работает за сценой. После входа приложение часто получает короткоживущий access token и более долгоживущий refresh token. Когда access token истекает, приложение использует refresh token, чтобы получить новый. Пользователь может и не заметить. Просто продолжает пользоваться приложением — и именно здесь возникают призрачные входы.

Это также объясняет, почему выход не всегда работает так, как ожидают пользователи. Выход в одной вкладке может очистить cookie этой вкладки, но не затронуть телефонное приложение или другой браузер под тем же аккаунтом. Если система не отслеживает и не отзывает каждый refresh token, некоторые сессии могут продолжать обновляться.

Веб и мобильные приложения часто ведут себя по‑разному. Браузеры следуют правилам cookie и обычно перестают отправлять cookie, как только его удалили. Мобильные приложения часто хранят токены внутри приложения и могут пробовать обновить их в фоне. Поэтому пользователь может выглядеть вышедшим на одном устройстве и всё ещё активным на другом, хотя думает, что у него «только один вход».

Как refresh token порождает призрачные входы

Многие приложения не просят пользователя заново входить всякий раз, когда истекает access token. Они хранят refresh token в браузере или приложении и используют его, чтобы незаметно получить новый access token в фоне. Для пользователя ничего не происходит. Для поддержки это выглядит как вход, который отказывается умирать.

Именно отсюда берутся призрачные входы. Короткоживущий access token может истечь через несколько минут, но приложение заменяет его прежде, чем пользователь заметит. Человек думает: «моя сессия уже должна была завершиться», а на следующем клике аккаунт открывается как ни в чём не бывало.

Выход часто не проходит по той же причине. Пользователь нажимает «выйти», приложение очищает один токен, но валидный refresh token остаётся в хранилище или в другой вкладке. Перезагрузка страницы или вызов API вытаскивает свежий access token, и пользователь снова попадает в аккаунт. С его точки зрения сайт проигнорировал кнопку выхода.

Браузеры усложняют обнаружение проблемы, потому что вкладки не обновляются одновременно. Одна вкладка может всё ещё показывать старое состояние с входом. Другая вкладка уже использовала refresh token и обновила сессию. Если у пользователя также открыт тот же аккаунт на телефоне, каждое устройство может вращать токены по собственному расписанию.

Простой и частый пример: кто‑то выходит на ноутбуке, закрывает крышку, а позже открывает то же приложение на телефоне. У телефона всё ещё есть валидный refresh token, поэтому оно продолжает работать. Когда ноутбук «просыпается» и вкладка перезагружается, она может снова синхронизироваться с активной сессией. Пользователь жалуется: «Я вышел везде, но ваше приложение снова меня залогинило».

Команды поддержки часто гоняются за неправильными следами. Они проверяют смену пароля, срок жизни cookie или кеш браузера. На самом деле refresh token чаще всего является причиной. Если продукт не отзывает этот токен при выходе, не истекает его вовремя и не синхронизирует выход между вкладками и устройствами, пользователи будут продолжать видеть призрачные входы.

Где ломается отзыв устройств

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

Распространённая ошибка — считать один refresh token эквивалентом всей сессии устройства. На самом деле приложение часто хранит больше: access token, refresh token, cookie и локальный флаг «вы вошли». Если бекенд блокирует только одну часть, приложение всё ещё может открываться и выглядеть нормально. Поддержка видит призрачные входы. Пользователи видят, что кнопка выхода не работает.

Время добавляет ещё один слой путаницы. Некоторые приложения проверяют отзыв только тогда, когда просят новый access token или вызывают защищённый API. До этой проверки старая сессия может ещё какое‑то время работать. В браузере открытая вкладка может всё ещё показывать данные аккаунта из памяти, и пользователь думает, что аккаунт полностью активен.

Офлайн‑устройства усугубляют проблему. Телефон без подключения не может спросить сервер, действительна ли сессия. Он сохраняет последнее состояние. Если пользователь вышел везде с другого устройства, этот офлайн‑телефон может позже открыть приложение и выглядеть залогиненным до тех пор, пока не подключится и не сделает запрос на сервер.

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

Простой пример: кто‑то сбрасывает пароль на рабочем ноутбуке после потери планшета. Админ отзывает текущий refresh token, но у планшета остался более старый токен и в тот момент нет сети. Через пару дней он подключается, открывает приложение и ещё некоторое время показывает недавние данные. Пользователь думает, что сброс не сработал, и поддержка начинает искать не ту ошибку.

Исправление не громкое, но работает. Отслеживайте сессии на уровне устройства, а не только на уровне токена. Когда вы отзываете устройство, блокируйте возможность обновления, очищайте cookie там, где это возможно, принуждайте к проверке на сервере на чувствительных экранах и заставляйте приложение удалять локальное состояние «вход выполнен» сразу, как только сервер скажет, что сессия умерла.

Общие браузеры усугубляют проблему

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

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

Сохранённые аккаунты добавляют путаницу. Менеджер паролей или автозаполнение браузера может подставить не тот e‑mail в форму входа, а выбор сохранённого аккаунта может вернуть пользователя к последнему использованному профилю. Поддержка получает тикет, который звучит как взлом, даже когда браузер просто повторно использовал старое состояние.

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

Прежде чем поддержка будет строить догадки, ей стоит задать несколько прямых вопросов. Использует ли кто‑то ещё этот компьютер или профиль браузера? Входили ли вы через подсказку сохранённого аккаунта? Обычное ли это окно браузера, а не приватное? Кто‑то ещё пользовался этим устройством сегодня? Эти вопросы экономят время, потому что сначала исключают самое обыденное: один профиль браузера, который действует как одна общая идентичность.

Простой пример из тикета поддержки

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

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

Это момент, когда призрачные входы начинают казаться захватом аккаунта, хотя никто к нему не прикасался.

В таком случае может быть правдой одновременно несколько вещей. В офисном браузере могла очиститься cookie‑сессия. На телефоне может всё ещё быть валидный refresh token, который тихо запрашивает новый access token. Планшет может продолжать работать, потому что приложение не принуждает к полной повторной аутентификации после сброса пароля.

Со стороны пользователя сигналы не совпадают. На одном устройстве статус — «вышел». Другой снова открывает аккаунт. Сброс пароля ничего не меняет мгновенно. Это несоответствие мгновенно вызывает панику.

Агенты поддержки иногда усугубляют ситуацию, говоря «вы вышли везде», когда система закончила только один тип сессии. Общие браузерные сессии добавляют ещё больше путаницы. Если рабочий компьютер используют несколько человек, браузер может автозаполнить аккаунт или восстановить кешированную страницу. Пользователь видит своё имя и воспринимает это как доказательство, что сессия всё ещё жива, даже если сервер бы отверг следующий реальный запрос.

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

Как проверять и фиксить шаг за шагом

Начните с карты всех мест, которые могут держать пользователя в системе. Многие команды проверяют только сервер. Это упускает cookie браузера, localStorage, sessionStorage, хранилище мобильного приложения и любой refresh token, кэшируемый библиотекой.

Если одна копия выживет, пользователь может выглядеть вышедшим в одном месте и вошедшим в другом. Так появляются призрачные входы.

Далее сформулируйте, что значит «выйти», простыми словами. Выход на одном устройстве должен завершать только ту сессию устройства. «Выйти везде» должно завершать каждую активную сессию, каждый refresh token и каждое запомненное устройство, привязанное к аккаунту.

Затем тестируйте поток в заданном порядке. Перечислите каждое место, где хранится состояние сессии на клиенте и на сервере. Отзывайте или вращайте refresh tokens при выходе, смене пароля или сообщении о потере устройства. Заставьте приложение проверять отзыв перед тем, как оно обновит access через refresh token. Решите, как работает удаление устройства, и сделайте результат таким же, как вы это описали пользователям.

Это звучит базово, но многие команды пропускают последний шаг: тестирование на реальных устройствах. Войдите в Chrome, Firefox и на телефоне. Выйдите в одном браузере, затем обновите страницу в других. Смените пароль и повторите тест. Удалите устройство и посмотрите, что происходит на следующем обновлении токена.

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

Распространённая ловушка легко ускользает: access token истёк, но у приложения всё ещё есть рабочий refresh token. Пользователь думает, что выход не удался, поддержка видит смешанные сигналы, а инженеры спорят, на клиенте дело или на сервере.

Запишите ожидаемый результат для каждого действия. Это даст поддержке конкретику для сравнения. Также поможет отличать старую страницу, которая ещё не обновилась, от сессии, которую система по‑прежнему принимает.

Частые ошибки, которые команды продолжают допускать

Команды часто принимают истечение access token за полноценный выход. Это красиво на бумаге, но ломается в реальности. Если у приложения всё ещё есть живой refresh token, оно может получить новый access token и снова открыть сессию.

Та же ошибка проявляется после сброса пароля. Многие команды меняют пароль, закрывают текущую веб‑сессию и на этом останавливаются. Если они оставляют старые refresh tokens на телефонах, планшетах или фоновых вкладках, эти устройства могут тихо снова войти.

Опция «Запомнить меня» тоже создаёт проблемы, потому что команды оставляют её поведение расплывчатым. Пользователи читают это как «держите меня в системе, пока я не скажу иначе». Поддержка может думать, что это «продлить сессию на несколько дней». Инженеры могут привязать это к сроку жизни refresh token без чёткого объяснения. Когда эти три представления не совпадают, пользователи считают систему сломанной.

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

Команды поддержки также слишком рано закрывают тикеты. Они видят, что пользователь вышел в одном браузере, помечают проблему как решённую и забывают. Потом другое устройство просыпается, посылает refresh‑запрос — и проблема возвращается.

Лучше простая привычка: истекайте access tokens, отзывайте refresh tokens при изменении риска, ясно объясняйте, что делает «Запомнить меня», предупреждайте пользователей про общие браузеры и ждите, пока все устройства снова не проверят состояние, прежде чем закрывать дело. Это работа скучная, но экономит часы поддержки и совпадает с ожиданиями пользователей.

Быстрые проверки перед закрытием тикета

Тикет по сессии не закрыт, когда одна вкладка браузера показывает экран входа. Призрачные входы часто выживают в местах, которые никто не проверил: в другой вкладке, в мобильном приложении, в старом refresh token или в профиле общего браузера.

Прежде чем закрыть дело, поддержка должна убедиться, что продукт действительно сделал то, что должен был, а не полагаться на свои ожидания. Пользователи должны иметь возможность видеть активные устройства и удалять их без обращения в поддержку. «Выйти везде» должен отзывать и refresh tokens тоже, а не только короткоживущие access tokens или cookie. Веб, мобильные и десктоп‑приложения должны следовать одному правилу сессий, или продукт должен ясно объяснять разницу.

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

Небольшие несовпадения создают основную путаницу. Если браузер сразу удаляет cookie, а мобильное приложение продолжает использовать refresh token до следующей синхронизации, пользователь видит два разных состояния и думает, что выход не удался.

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

Последняя проверка проста: может ли поддержка подтвердить действие без догадок? Хороший ответ звучит примерно так: «Мы отозвали все refresh tokens и удалили три активные сессии. Ваше мобильное приложение попросит вас войти снова при следующей синхронизации». «Должно быть исправлено» обычно недостаточно.

Что делать дальше

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

Затем протестируйте это правило на реальных сценариях, а не только в одной вкладке браузера на одном ноутбуке. Используйте два браузера, приватное окно, телефон и второе устройство. Выйдите в одном месте и обновите в другом. Сбросьте пароль, пока старая вкладка ещё открыта. Удалите устройство и посмотрите, создаёт ли refresh token новую сессию через несколько минут.

Большинство проблем со поддержкой сессий прячутся в небольших разрывах между ожиданиями команды и реальным поведением приложения. Старая вкладка, общий профиль браузера или слишком длинный срок жизни refresh token может сделать так, что пользователь одновременно кажется вышедшим и вошедшим.

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

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

Если такие тикеты продолжают замедлять вашу команду, Oleg Sotnikov на oleg.is может посмотреть дизайн сессий и поток поддержки как Fractional CTO или советник. Его опыт в production‑системах, архитектуре ПО и бережных операциях поможет найти места, где правила выхода, правила токенов и шаги поддержки перестают согласовываться.