Skip to content

Авторизовать проигрывание с помощью токена

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

Эта схема работает в тех случаях, когда контент раздается с медиасервера. Если вы используете CDN, то вам нужно или обращаться к поставщику CDN, или использовать DRM.

Настройка тестового примера

Установите триальную версию Flussonic и за несколько минут вы сможете запустить защищенный стрим для тестирования.

http 8080;
rtmp 1935;
rtsp 1554;

auth_backend play-auth {
    allow token test1;
}

stream auth-check {
    input fake://fake;
    on_play auth://play-auth;
}

Как срабатывает защита?

Различные проигрыватели и пользовательские устройства по-разному будут показывать, что защищенный видео поток более не доступен для проигрывания. Например ffmpeg покажет следующее:

$ ffmpeg  -i rtmp://localhost/rtmp/auth-check
ffmpeg version 6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
...
  libswresample   4. 12.100 /  4. 12.100
  libpostproc    57.  3.100 / 57.  3.100
[in#0 @ 0x600001c9c700] Error opening input: Input/output error
Error opening input file rtmp://localhost/rtmp/auth-check.
Error opening input files: Input/output error

ffmpeg не раскрывает детали отказа, а по http отдается более стандартизованный код ошибки:

$ curl -v http://localhost:8080/auth-check/index.m3u8 -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /auth-check/index.m3u8 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/1.1 403 Forbidden
< access-control-allow-headers: x-vsaas-session, x-no-redirect, origin, authorization, accept, range, content-type, x-add-effective, session, x-originator, x-sid
< access-control-allow-methods: GET, PUT, DELETE, OPTIONS
< access-control-allow-origin: *
< access-control-expose-headers: Server, range, X-Run-Time, X-Sid, Content-Length, Location
< content-length: 1147
< date: Sat, 03 Feb 2024 19:16:16 GMT
< server: Streamer 24.02
< x-deny-reason: backend_denied
< x-route-time: 172
< x-run-time: 210
<

403 отдается, когда авторизация не пустила клиента

Как проиграть с токеном?

HTTP

По HTTP протоколам: HLS, DASH, MSS, LL-HLS, WebRTC всё довольно просто, токен надо добавить в query string запроса.

$ curl http://localhost:8080/auth-check/index.m3u8?token=test1
#EXTM3U
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=260000,BANDWIDTH=320000,RESOLUTION=320x240,FRAME-RATE=25.000,CODECS="avc1.42c015,mp4a.40.2",CLOSED-CAPTIONS=NONE
tracks-v1a1/mono.m3u8?token=test1


$ ffmpeg -i http://localhost:8080/auth-check/index.m3u8?token=test1
...
[hls @ 0x11f604b70] Opening 'http://localhost:8080/auth-check/tracks-v1a1/mono.m3u8?token=test1' for reading
[hls @ 0x11f604b70] Skip ('#EXT-X-VERSION:3')
[hls @ 0x11f604b70] Skip ('#EXT-X-PROGRAM-DATE-TIME:2024-02-03T19:31:31.839Z')
[hls @ 0x11f604b70] Opening 'http://localhost:8080/auth-check/tracks-v1a1/2024/02/03/19/31/36-05000.ts?token=test1' for reading
[hls @ 0x11f604b70] Opening 'http://localhost:8080/auth-check/tracks-v1a1/2024/02/03/19/31/41-05000.ts?token=test1' for reading
Input #0, hls, from 'http://localhost:8080/auth-check/index.m3u8?token=test1':
  Duration: N/A, start: 73249.691911, bitrate: N/A
  Program 0 
    Metadata:
      variant_bitrate : 320000
  Stream #0:0: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 90k tbn
    Metadata:
      variant_bitrate : 320000
  Stream #0:1(eng): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp
    Metadata:
      variant_bitrate : 320000

RTSP

Протокол RTSP не сильно отличается, в нём тоже есть стандартный урл, стандартный способ передачи query string:

$ ffmpeg -i rtsp://localhost:1554/auth-check?token=test1
...
Input #0, rtsp, from 'rtsp://localhost:1554/auth-check?token=test1':
  Metadata:
    title           : Streamer 24.02
  Duration: N/A, start: 0.003000, bitrate: N/A
  Stream #0:0: Video: h264 (Constrained Baseline), yuv420p(progressive), 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 90k tbn
  Stream #0:1(eng): Audio: aac (LC), 48000 Hz, stereo, fltp

RTMP

С RTMP немного сложнее, в этом протоколе нет единого понимания урла и поэтому есть куча разных вариантов, как передать авторизационную информацию. Однако существует сложившаяся практика отправлять query string в параметры функции play, склеивая с именем стрима и ffmpeg именно это и делает:

$ ffmpeg -i rtmp://localhost/static/auth-check?token=test1
...
Input #0, flv, from 'rtmp://localhost/static/auth-check?token=test1':
  Metadata:
    |RtmpSampleAccess: true
    audiochannels   : 2
  Duration: 00:00:00.00, start: 0.000000, bitrate: N/A
  Stream #0:0: Data: none
  Stream #0:1: Video: h264 (Constrained Baseline), yuv420p(progressive), 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1k tbn
  Stream #0:2: Audio: aac (LC), 48000 Hz, stereo, fltp, 28 kb/s

SRT

Есть отдельная статья про авторизацию проигрывания SRT.

UDP MPEG-TS

Протокол UDP MPEG-TS (передача по мультикасту) не включает в себя взаимодействие клиента и сервера, сервер вообще не знает о том, что с него что-то проигрывают и поэтому такой метод авторизации не работает. Облегчает ситуацию то, что мультикаст по интернету не ходит и задачи ограничения доступа немного другие. Для этого используется шифрование и CAS системы.

Как управлять авторизационными токенами

Перечисление токенов в конфиге ни в коем случае не может являться основным механизмом. Мы неоднократно видели, как подобные забытые «секретные» ключи, сделанные для удобства отладки сервиса, потом расходятся по интернету и активно используются.

Основной механизм генерации и проверки — реализация на стороне вашего портала (миддлвари, веб-сайта) системы, которая сама генерирует токены и сама их проверяет.

Если у вас еще нет подписки на Flussonic или триальной лицензии, перейдите по ссылке и запросите бесплатный тестовый ключ. Установка сервера займет совсем немного времени, а тестовая конфигурация с которой вы сможете начать, приведена в начале этой статьи.

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