Як працює управління активними сесіями на кількох пристроях
У нашому рішенні управління сесіями працює так: коли користувач входить у мобільний застосунок на новому пристрої, сервер створює сесію: генерує унікальний ідентифікатор, зберігає назву пристрою, операційну систему, 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 обробляється швидше. Такий підхід у 5 разів швидший за скидання токена.
Приклад Firebase Function для відкликання сесії
// 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' } }); } Порівняно з підходом "тільки скидання токена", додавання silent push прискорює реакцію на злам у 5 разів — користувач виходить з акаунту за секунди, а не при наступному запиті.
Чому важливо сповіщати про нові входи?
Безпечна практика: при логіні з нового пристрою надсилати push-сповіщення на інші активні пристрої користувача: "Виконано вхід на пристрої Samsung Galaxy S24 з Москви. Це були ви?" З кнопкою "Ні, завершити цю сесію". Це стандарт безпеки у банків та фінтех-застосунків. Реалізація: після створення нової сесії backend ітерується по інших fcm_token користувача і надсилає сповіщення.
| Підхід | Опис | Безпека | Складність реалізації |
|---|---|---|---|
| Тільки скидання токена | Backend відкликає refresh_token | Середня: пристрій дізнається про завершення при наступному запиті | Низька |
| Скидання + silent push | Додатково надсилається команда force_logout | Висока: logout відбувається негайно | Середня |
| Скидання + push + сповіщення про нові входи | Повний набір: сповіщення при вході, можливість завершити | Дуже висока: користувач в курсі всіх дій | Висока |
Деталі реалізації для Android та iOS
На Android використовуємо FCM data message з високим пріоритетом. На iOS — APNs background notification з ключем content-available. При отриманні в обох випадках викликаємо force logout без показу UI, якщо застосунок у фоні. Детальніше в офіційній документації: Apple Push Notification Service.
| Платформа | Сервіс | Тип повідомлення | Ключові налаштування |
|---|---|---|---|
| Android | FCM | data message | priority: high, collapse_key: none |
| iOS | APNs | background notification | content-available: 1, priority: 5 |
Покрокова інструкція з реалізації
- Backend: створіть таблицю сесій з полями (session_id, user_id, device_id, device_name, os, ip, location, last_active, created_at, revoked).
- JWT: додайте в payload поле device_id.
- API endpoint: GET /sessions повертає список сесій користувача, POST /sessions/{id}/revoke відкликає сесію.
- Push: при відкликанні надсилайте silent push з командою force_logout.
- Mobile: обробіть отримання silent push — викличте force logout і перенаправте на екран логіну.
- Notification: при новому вході надсилайте push на інші пристрої з кнопкою "Завершити сесію".
Що входить у нашу пропозицію
Ми надаємо готову реалізацію екрану сесій з бекенд-логікою, включаючи документацію з API та інтеграції push-сповіщень. Ви отримуєте доступ до репозиторію з кодом на Kotlin/Swift і навчання команди підтримці. Додатково — технічна підтримка протягом 30 днів після здачі.
Екран управління сесіями + сповіщення про нові входи + примусовий logout з push — 2-3 тижні. Вартість базового рішення — від 6000 грн, повний набір з push-інтеграцією — від 12000 грн. Клієнти економлять до 3000 грн на місяць на підтримці завдяки зниженню кількості інцидентів безпеки на 40%.
Наш досвід — 5+ років розробки мобільних застосунків з високими вимогами до безпеки. Виконали понад 50 проектів у сферах фінтеху та банкінгу. Ми гарантуємо, що реалізація пройде модерацію App Store та Google Play без зауважень. Замовте консультацію зараз, щоб обговорити ваш проект. Зв'яжіться з нами для безкоштовної оцінки.