Аутентификация и авторизация в Dexie Cloud

Dexie.js и Dexie Cloud формируют связку, в которой клиентская база данных в браузере дополняется облачным слоем синхронизации, а модель безопасности строится вокруг централизованной аутентификации и декларативной авторизации на уровне данных.


Аутентификация в Dexie Cloud опирается на концепцию идентичности пользователя, связанной с токеном доступа и серверной сессией. В отличие от классических REST API, где каждый запрос может сопровождаться отдельной проверкой, здесь используется долговременная сессия с обновляемыми токенами, которые интегрируются в механизм синхронизации.

Ключевые элементы модели:

  • пользователь (user identity)
  • сессия (session)
  • access token
  • refresh token (в зависимости от конфигурации провайдера)
  • контекст синхронизации (sync context)

Идентичность пользователя становится центральным объектом, определяющим доступ к таблицам и отдельным записям.


Структура идентичности и сессий

Идентичность в Dexie Cloud формируется после прохождения провайдера аутентификации. После успешной аутентификации создаётся сессия, которая закрепляется за устройством.

Сессия включает:

  • уникальный идентификатор пользователя
  • временные токены доступа
  • метаданные провайдера (email, OAuth id, external subject)
  • список разрешённых областей данных

Токен используется не только для API-запросов, но и для синхронизации состояния IndexedDB через Dexie.js.


Провайдеры аутентификации

Dexie Cloud поддерживает модель внешних провайдеров:

  • OAuth2/OIDC провайдеры
  • email-based magic link схемы
  • кастомные токены (server-issued tokens)

При использовании внешнего провайдера процесс выглядит следующим образом:

  1. перенаправление на провайдера
  2. получение callback с авторизационным кодом
  3. обмен кода на access token
  4. установка сессии в Dexie Cloud
  5. инициализация синхронизации локальной базы

Ключевой особенностью является то, что идентичность пользователя привязывается к внутреннему user id, а не к внешнему идентификатору напрямую.


Хранение токенов и клиентская интеграция

На клиентской стороне Dexie.js используется как слой локального хранения, где токены могут сохраняться в IndexedDB или memory storage.

Типовая структура состояния аутентификации:

  • текущий user context
  • access token
  • состояние refresh механизма
  • флаг синхронизации

Токен передаётся в синхронизатор Dexie Cloud, который автоматически добавляет его в заголовки запросов и управляет обновлением при истечении срока действия.


Авторизация как декларативная модель

Авторизация в Dexie Cloud не реализуется через императивные проверки в коде клиента. Вместо этого используется правила доступа (access rules), описываемые декларативно.

Основные уровни авторизации:

  • доступ к таблице
  • доступ к строкам (row-level security)
  • доступ к операциям (read/write/delete)
  • условные фильтры по полям записи

Пример концептуальной структуры правил:

  • таблица доступна только авторизованным пользователям
  • строки принадлежат конкретному userId
  • доступ разрешён только владельцу или участникам группы

Row-Level Security (RLS)

Row-Level Security является ключевым механизмом контроля данных. Каждая запись может содержать поле владельца или список участников.

Типовые стратегии:

Владение данными

  • запись содержит ownerId
  • доступ разрешён при совпадении ownerId и текущего user id

Коллаборативный доступ

  • запись содержит массив memberIds
  • доступ разрешён при наличии user id в массиве

Публичные записи

  • флаг isPublic
  • доступ разрешён без учёта пользователя

Эти правила применяются сервером при синхронизации и не зависят от логики клиента.


Интеграция авторизации в синхронизацию

Синхронизация в Dexie.js и Dexie Cloud тесно связана с системой авторизации.

Процесс синхронизации включает:

  • проверку токена перед установлением канала
  • загрузку разрешённых наборов данных
  • фильтрацию изменений на сервере
  • применение delta updates к локальной базе

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


Контекстные разрешения и области данных

Dexie Cloud использует концепцию data scopes, ограничивающих доступ пользователя к сегментам данных.

Возможные типы scope:

  • пользовательский scope (user-specific data)
  • групповой scope (team or organization)
  • системный scope (shared or public data)

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


Модель multi-tenant

Мультиарендность реализуется через разделение данных по tenantId. В рамках одной базы могут существовать:

  • отдельные пространства данных организаций
  • изолированные пользовательские сегменты
  • общие публичные области

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


Безопасность токенов и сессий

Система безопасности строится на следующих принципах:

  • токены имеют ограниченный срок жизни
  • доступ обновляется через refresh механизм
  • сессии привязаны к устройству
  • сервер контролирует отзыв токенов

Дополнительно используется защита от повторного использования токенов и проверка целостности сессии при каждом sync-запросе.


Конфигурация правил доступа

Правила авторизации задаются декларативно и интерпретируются сервером Dexie Cloud.

Типовая структура включает:

  • имя таблицы
  • условия доступа на чтение
  • условия доступа на запись
  • выражения фильтрации строк
  • привязка к user context

Условия выражаются через логические операторы и ссылки на поля записи и контекст пользователя.


Поведение при нарушении доступа

При несоответствии правил:

  • операции записи отклоняются сервером
  • изменения не попадают в синхронизацию
  • клиент получает частичный откат состояния
  • локальная база сохраняет консистентность

Это предотвращает расхождение между локальным состоянием Dexie.js и серверной моделью данных.


Комбинация аутентификации и авторизации

Аутентификация определяет кто является пользователем, авторизация определяет что именно доступно этому пользователю.

В Dexie Cloud эти два процесса объединены в единую систему:

  • токен содержит идентичность
  • правила доступа используют идентичность
  • синхронизация исполняется в контексте правил
  • локальная база является отражением разрешённого подмножества данных

Такое разделение позволяет сохранять оффлайн-работу без потери модели безопасности.


Контекст выполнения запросов

Каждый запрос к облаку выполняется в контексте:

  • user identity
  • active session
  • dataset scope
  • device identifier

Контекст формируется автоматически и используется сервером для оценки всех access rules без участия клиентского кода.


Изоляция клиентской логики

Клиентская сторона в Dexie.js не содержит критической логики безопасности. Любые проверки, реализованные на клиенте, считаются вспомогательными и не влияют на итоговое решение сервера.

Это обеспечивает устойчивость модели к:

  • модификации клиентского кода
  • подмене запросов
  • попыткам обхода фильтров синхронизации

Принципы построения безопасной модели доступа

Система Dexie Cloud опирается на следующие принципы:

  • сервер является единственным источником истины для доступа
  • клиент хранит только локально разрешённое подмножество данных
  • правила доступа описываются декларативно
  • идентичность пользователя централизована
  • синхронизация всегда проходит через проверку контекста

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