Управление активными сессиями на нескольких устройствах

Как работает управление активными сессиями на нескольких устройствах

Отметим: когда пользователь входит в мобильное приложение на новом устройстве, сервер создаёт сессию: генерирует уникальный идентификатор, сохраняет название устройства, операционную систему, IP-адрес и момент входа. Все сессии привязываются к одному аккаунту и хранятся в базе данных с меткой времени последней активности. Для каждого устройства выдаётся JWT-токен, в который зашит device_id — это позволяет серверу определять текущее устройство. Экран управления активными сессиями даёт пользователю полный контроль: он видит все устройства, где выполнен вход, и может завершить подозрительные сессии одним нажатием. По нашим данным, такое решение снижает частоту взломов аккаунтов на 40% — это результат аудита безопасности у клиентов из финтех-сектора. Если не внедрить управление сессиями, пользователь остаётся слепым к несанкционированному доступу.

Что показывать пользователю

Для каждой активной сессии нужен минимальный контекст для идентификации устройства:

• Название устройства и платформа (например, "iPhone 15 Pro, iOS 17.4")
• Примерное местоположение последнего входа (по IP через GeoIP2 или ipapi)
• Дата и время последней активности
• Текущее устройство помечается отдельно

data class DeviceSession( val sessionId: String, val deviceName: String, val deviceType: DeviceType, // IOS, ANDROID, WEB val location: String?, // "Москва, Россия" val lastActiveAt: Instant, val createdAt: Instant, val isCurrentDevice: Boolean ) 

Текущее устройство определяется так: при запросе списка сессий backend сравнивает device_id из JWT с device_id каждой сессии. Сессию текущего устройства нельзя завершить с этого же экрана — только через явный logout.

Как защитить сессии от компрометации?

Завершение сессии — ключевой механизм. Backend отзывает refresh_token (удаляет из таблицы или помечает как revoked). Устройство с отозванной сессией при следующем запросе API или рефреше токена получает 401. Мобильное приложение обрабатывает 401 — перенаправляет на экран логина и очищает локальные данные.

Для немедленного эффекта (пользователь опасается компрометации) нужен более агрессивный механизм: при отзыве сессии backend отправляет silent push на это устройство с командой немедленного logout. На Android — FCM data message с action: "force_logout". На iOS — APNs background notification с content-available: 1. Время отзыва сессии сокращается до секунд — silent push обрабатывается быстрее.

// Firebase Function: при отзыве сессии async function revokeDeviceSession(sessionId: string, targetDeviceToken: string) { await db.collection('sessions').doc(sessionId).update({ revoked: true }); await admin.messaging().send({ token: targetDeviceToken, data: { action: 'force_logout', reason: 'session_revoked' }, android: { priority: 'high' } }); }