Перейти к основному содержанию

Интеграция авторизации QuickPass с основным продуктом

Интеграция авторизации QuickPass с основным продуктом

QuickPass использует собственную систему аутентификации на основе JWT (JSON Web Tokens) для управления сессиями пользователей. Для интеграции с основным продуктом, где пользователь уже аутентифицирован, необходимо реализовать один из механизмов передачи данных аутентификации между системами.

Основная цель интеграции - обеспечить:

  1. Единый вход между основным продуктом и QuickPass
  2. Передачу минимально необходимых данных о пользователе
  3. Безопасность передачи учетных данных

Ниже представлены варианты интеграции, позволяющие передать данные аутентификации из основного продукта в QuickPass.

Варианты интеграции

1. OAuth2

  • Флоу:

    1. Основной продукт → редирект на QuickPass
    2. Авторизация в QuickPass
    3. QuickPass → код авторизации → основной продукт
    4. Обмен кода на access token
    5. Запрос данных пользователя по токену

  • Технические требования:

    • Регистрация OAuth2 приложения в QuickPass
    • HTTPS для всех redirect_uri
    • Поддержка Authorization Code flow

2. Iframe с общими куками

  • Флоу:

    1. Основной продукт → iframe QuickPass (поддомен)
    2. Проверка общих кук домена
    3. Автоматическая авторизация в iframe
    4. Передача данных через postMessage

  • Технические требования:

    • Общий домен или поддомены (например: main.example.com и qp.example.com)
    • Настройка SameSite=None для кроссдоменных кук
    • Content Security Policy для iframe
    • Обработка postMessage событий с валидацией origin

3. JWT-токены

  • Флоу:

    1. Основной продукт → генерирует JWT
    2. Редирект в QuickPass с токеном в URL
    3. QuickPass → верификация JWT
    4. Создание сессии на основе данных в токене

  • Технические требования:

    • Общий секретный ключ или асимметричная криптография (RS256)
    • Короткое время жизни токена (5-15 минут)
    • Обязательные claims: user_id, exp, iat, iss
    • Передача через POST body вместо URL для безопасности

4. Сервер-серверная синхронизация

  • Флоу:

    1. Основной продукт → вызов API QuickPass
    2. Передача хеша сессии/токена
    3. QuickPass → проверка → возврат данных пользователя
    4. Основной продукт → создание локальной сессии

  • Технические требования:

    • API ключи для аутентификации запросов
    • Rate limiting (например, 100 запросов/минуту)
    • Timeout для запросов (3-5 секунд)
    • Retry механизм при временных сбоях
    • Webhook для уведомлений об изменениях сессий

Рекомендации по выбору метода

МетодКогда использоватьСложностьБезопасность
OAuth2Полная интеграция, высокие требования к безопасностиВысокаяМаксимальная
IframeВстроенная интеграция, общий доменСредняяВысокая
JWTПростая интеграция, доверенная средаНизкаяСредняя
Сервер-серверBackend интеграция, высокая нагрузкаНизкаяВысокая

Быстрый старт: JWT-токены для прототипа, OAuth2 для продакшена.

Управление идентификаторами пользователей

При интеграции авторизации необходимо решить, как будут сопоставляться пользователи между основным продуктом и QuickPass. Существует два основных подхода:

Вариант 1: Единые идентификаторы

Принцип: userId в QuickPass соответствует userId в основном продукте

Реализация:

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

Преимущества:

  • Простота реализации и поддержки
  • Быстрый поиск пользователей
  • Минимальные накладные расходы

Пример интеграции:

{
  "user_id": "12345",
  "source": "main_product"
}

Вариант 2: Связанные аккаунты

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

Реализация:

  • У каждого пользователя QuickPass есть уникальный внутренний ID
  • Аккаунт основного продукта добавляется как связанный профиль социальной сети
  • Хранение: source="main_product" и source_id="{userId основного продукта}"
  • Поддержка множественных привязок к одному аккаунту QuickPass

Структура данных:

{
  "quickpass_user_id": "qp_67890",
  "linked_accounts": [
    {
      "source": "main_product",
      "source_id": "12345",
      "linked_at": "2024-01-15T10:30:00Z",
      "status": "active"
    },
    {
      "source": "telegram",
      "source_id": "tg_98765",
      "linked_at": "2024-01-10T15:20:00Z",
      "status": "active"
    }
  ]
}

Преимущества:

  • Независимость систем идентификации
  • Возможность привязки нескольких внешних аккаунтов
  • Гибкость при миграциях и изменениях
  • Соответствие архитектуре социальных интеграций QuickPass

Пример API запроса:

POST /api/v1/users/accounts
{
  "quickpass_user_id": "qp_67890",
  "source": "main_product",
  "source_id": "12345",
  "verification_token": "jwt_token_from_main_product"
}

Процесс привязки аккаунтов

  1. Первичная авторизация:

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

  2. Создание или поиск аккаунта:

    • QuickPass проверяет, есть ли уже привязка с source="main_product" и данным source_id
    • Если есть - авторизует существующего пользователя
    • Если нет - создает новый аккаунт QuickPass или предлагает привязать к существующему

  3. Установка связи:

    • Сохранение записи о связанном аккаунте
    • Установка активной сессии QuickPass
    • Возможность дальнейшего использования любого из методов авторизации