Авторизационный бэкенд: доступ к видео по правилам вашей системы

Kinescope позволяет контролировать доступ к видео через внешний авторизационный бэкенд. Это значит, что вы сами решаете, кто может смотреть конкретное видео — на основе правил вашей системы (курсы, подписки, роли и т.д.).

Кому подходит эта статья

• Разработчикам LMS — нужно контролировать доступ к видео по курсам и урокам
• Владельцам платформ с подписками — требуется ограничить доступ по статусу подписки
• Администраторам корпоративных систем — нужно настроить доступ по ролям и группам
• Backend-разработчикам — требуется интегрировать систему контроля доступа с Kinescope

Когда вам нужен авторизационный бэкенд

Вот типичные ситуации, когда это пригодится:

• Доступ только к части видео: пользователь купил курс или пакет, но не имеет доступа ко всей библиотеке.
• Подписка: видео доступны только пока подписка активна (или не истёк пробный период).
• Покупка отдельных уроков: доступ только к конкретным видео, которые пользователь оплатил.
• Корпоративный доступ: доступ по роли в организации (сотрудники, партнёры) или по членству в группе.
• Ограничения по контексту: доступ по IP, геолокации, времени (окно доступа), устройству или сессии.

Если хотя бы один из этих сценариев вам знаком — читайте дальше. Ниже показано, как настроить проверку доступа в два шага.

Как проходит проверка доступа (4 шага)

1. Вы передаёте идентификатор пользователя в плеер Kinescope.
2. Когда пользователь пытается посмотреть видео, Kinescope спрашивает у вашего бэкенда: «Можно ли этому пользователю смотреть это видео?»
3. Ваш бэкенд проверяет правила (курс, подписка, роль и т.д.) и отвечает: 200 (разрешить) или 403 (запретить).
4. Плеер открывает или блокирует доступ.

Теперь разберём, как это настроить.

Настройка: шаг 1 — передача идентификатора пользователя

При встраивании плеера на сайт передайте токен авторизации через параметр drmauthtoken в URL:

<iframe
  src="https://kinescope.io/embed/pcFNnQGsD59CMKte2SQQaz?drmauthtoken=${user_id}"
  width="640"
  height="360"
  frameborder="0"
  allow="autoplay; fullscreen; picture-in-picture; encrypted-media;"
></iframe>

В качестве токена можно использовать любую строку: user_id, JWT-токен или другой идентификатор, который ваш бэкенд сможет проверить.

Рекомендация (безопасность): для продакшена рекомендуем использовать подписанный JWT в drmauthtoken. Это защитит от подмены токена на клиенте. На бэкенде валидируйте подпись JWT и извлекайте user_id.

Для разработчиков: при валидации JWT проверяйте стандартные поля: exp (срок действия), aud (аудитория), iss (издатель) — это повысит безопасность.

Настройка: шаг 2 — подключение вашего бэкенда

Чтобы Kinescope мог обращаться к вашему бэкенду за проверкой доступа, добавьте URL вашего эндпоинта в настройки проекта или рабочей области через API Kinescope.

Важно: API-токен в заголовке Authorization: Bearer должен быть в формате UUID. Получить токен можно в Dashboard Kinescope в разделе Настройки → API-токены. Подробнее об авторизации и обработке ошибок в общих правилах API.

DRM можно настроить на двух уровнях:

• Workspace — применяется ко всем проектам
• Project — применяется к конкретному проекту (переопределяет настройки workspace)

Настройка URL авторизационного бэкенда через API:

Для всего workspace:

curl -X PUT "https://api.kinescope.io/v1/drm/auth" \
  -H "Authorization: Bearer ${KINESCOPE_API_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://api.example.com/drm/authorize",
    "username": "drm_user",
    "password": "drm_password",
    "strict": false
}'

Для конкретного проекта:

curl -X PUT "https://api.kinescope.io/v1/drm/auth/${PROJECT_ID}" \
  -H "Authorization: Bearer ${KINESCOPE_API_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://api.example.com/drm/authorize",
    "username": "drm_user",
    "password": "drm_password",
    "strict": false
}'

Параметры запроса:

• url (обязательный) — URL вашего эндпоинта проверки доступа (куда Kinescope будет отправлять запросы при воспроизведении)
• username (опционально) — логин для Basic Auth к вашему сервису
• password (опционально) — пароль для Basic Auth
• strict (опционально) — строгий режим проверки

Проверка текущих настроек:

# Для workspace
curl -X GET "https://api.kinescope.io/v1/drm/auth" \
  -H "Authorization: Bearer ${KINESCOPE_API_TOKEN}"

# Для проекта
curl -X GET "https://api.kinescope.io/v1/drm/auth/${PROJECT_ID}" \
  -H "Authorization: Bearer ${KINESCOPE_API_TOKEN}"

Важно: Kinescope отправляет на ваш URL HTTP-запрос с JSON (см. пример ниже). В ответ достаточно вернуть 200 (разрешить) или 403 (запретить).

Что приходит на ваш бэкенд

Когда пользователь пытается посмотреть видео, Kinescope отправляет на ваш URL авторизации JSON с контекстом:

{
  "id": "7127f2d7-0e96-40d0-9a03-2e987c096466",
  "ip": "11.22.33.0",
  "type": "video",
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 ..."
}

Что означают поля:

• id — ID видео, к которому запрашивается доступ
• token — токен авторизации, который вы передали в drmauthtoken (например, user_id или JWT)
• ip — IP-адрес пользователя
• type — тип контента (обычно "video")
• user_agent — User-Agent браузера пользователя

Что отдавать в ответ

Ваш бэкенд должен вернуть один из HTTP-кодов:

Для разработчиков: если ваш бэкенд временно недоступен (5xx), Kinescope не сможет проверить доступ. Рекомендуем настроить мониторинг и быстрое восстановление сервиса.

Как проверить доступ (минимальная схема)

Вот что нужно сделать в вашем обработчике авторизации:

1. Извлечь user_id из token: если используете JWT — валидируйте подпись и извлеките user_id; если передаёте user_id напрямую — просто используйте его.
2. Определить контекст видео: по id (ID видео) понять, к какому курсу/пакету/разделу относится видео.
3. Проверить права в вашей системе: есть ли у пользователя доступ (покупка, подписка, роль, группа и т.д.).
4. Вернуть ответ: 200, если доступ есть, иначе 403.

Коротко в псевдокоде:

user_id = verify_and_extract_user_id(token)
if user_id is empty -> 403

if user_has_access_to_video(user_id, video_id) -> 200
else -> 403

Пример: доступ только к купленному курсу

Допустим, у вас на сайте есть курсы, и пользователь купил только один из них. Как проверить доступ к видео этого курса?

Шаг 1: Сопоставьте видео с курсом в вашей системе (например, таблица course_videos с полями course_id и video_id).

Шаг 2: В обработчике авторизации:

• Извлеките user_id из token (валидируйте JWT, если используете).
• По video_id найдите course_id.
• Проверьте, что пользователь записан на курс, оплатил его и курс активен.
• Верните 200, если всё ок, иначе 403.

Псевдокод:

course_id = find_course_by_video(video_id)
if course_id is empty -> 403

if enrollment_is_active(user_id, course_id) -> 200
else -> 403

Как это работает (подробнее)

Вот что происходит, когда пользователь открывает страницу с плеером:

1. Пользователь заходит на страницу — ваш сайт передаёт токен авторизации (например, user_id или JWT) в плеер Kinescope через параметр drmauthtoken.
2. Kinescope обращается к вашему бэкенду — отправляет HTTP-запрос с JSON, где указаны:
   • токен авторизации (тот, что вы передали в drmauthtoken);
   • ID видео;
   • IP-адрес и User-Agent пользователя.
3. Ваш бэкенд проверяет доступ — смотрит правила в вашей системе (курс, подписка, роль и т.д.) и возвращает ответ:
   • HTTP 200 — доступ разрешён, сервер лицензий выдаёт ключ дешифровки, видео становится доступным.
   • HTTP 403 — доступ запрещён, видео не воспроизводится.
4. Плеер получает ответ — открывает или блокирует доступ к видео.

Всё! Теперь вы можете контролировать доступ к видео по любым правилам вашей системы.

Что дальше?

После настройки авторизационного бэкенда рекомендуем:

1. DRM-шифрование файлов — дополнительная защита контента
2. Ограничение доступа к видео — другие способы ограничения доступа
3. Общие правила API — авторизация и формат запросов

Остались вопросы? Напишите в чат поддержки — специалисты помогут!