Shared Signals Framework: як сервіси повідомляють один одному про ризикові сесії

Shared Signals Framework (SSF) дозволяє різним сервісам обмінюватися перевірними подіями безпеки. Замість очікування завершення access token identity provider може повідомити relying party, що обліковий запис скомпрометовано, credential змінено або сесію потрібно переглянути.

Чому токен швидко застаріває

Під час видачі token користувач може бути довіреним. Через хвилину система виявляє викрадення cookie або вимикає обліковий запис, але token формально чинний ще годину. Continuous Access Evaluation потребує каналу, який доставляє зміну стану майже в реальному часі.

Security Event Token

Подія передається як SET — підписаний JWT зі стандартизованими claims та event payload. Отримувач перевіряє issuer, audience, signature, час і тип події. SET повідомляє факт, а не обов’язково містить команду: локальна policy вирішує, чи закрити сесію, запросити MFA або обмежити дію.

CAEP і RISC

Continuous Access Evaluation Profile описує зміни сесії, рівня assurance, device compliance та інших умов доступу. RISC зосереджений на сигналах про компрометацію акаунта. Вони використовують спільну delivery-основу, але мають різні event types і семантику.

Streams і доставка

Між transmitter та receiver налаштовується stream із конфігурацією, ключами й підтримуваними подіями. Доставка може використовувати push або pull-механізм залежно від профілю. Потрібні retry, idempotency, контроль черги та спостереження за затримкою.

SSF доповнює первинну авторизацію, а не замінює її. Для високозахищених API базовий flow варто будувати за FAPI 2.0 Security Profile.

Приватність і кореляція

Сигнали розкривають чутливий стан користувача. Сторони узгоджують purpose, subject identifiers, retention і мінімальний набір event types. Pairwise identifiers можуть зменшити наскрізне стеження, але потребують стабільного зіставлення у межах довірчого зв’язку.

Захист від replay і дублікатів

Receiver зберігає ідентифікатори подій на обмежений час, перевіряє часові claims і робить обробник ідемпотентним. Повторний сигнал про закриття сесії не повинен створювати помилку або відновлювати доступ. Порядок доставки також не завжди гарантований.

Пілотний сценарій

• почати з одного сигналу — наприклад, account disabled;
• визначити точну локальну реакцію та SLA;
• перевірити ключі, rotation і недоступність receiver;
• виміряти end-to-end latency та частку невдалих подій;
• провести privacy review і вправу з хибним сигналом.

Хибний позитивний сигнал

Автоматичне блокування тисяч сесій через помилковий event може стати окремим інцидентом. Для різних типів сигналів задають різну реакцію: негайне revoke, step-up authentication або risk review. Високий вплив потребує підтверджених джерел, обмеження швидкості й kill switch.

Відновлення після пропуску подій

Receiver може бути недоступним довше, ніж зберігається черга. Після reconnect потрібна resynchronization або перевірка поточного стану, інакше стара сесія залишиться активною. Метрика lag показує не лише транспортну затримку, а час до фактичного застосування локальної policy.

Першоджерело: OpenID Shared Signals Working Group.