Skip to content

Backend de autorización

media.access.auth_backend

El backend HTTP de autorización es un mecanismo obsoleto (deprecated), no recomendado para nuevas integraciones. Para nuevas integraciones, use el JWT del espectador: la aplicación obtiene un token firmado mediante la API de central y los edges lo validan localmente. El backend HTTP se mantiene por compatibilidad con las instalaciones existentes.

Con la autorización HTTP, el streamer consulta al backend al autorizar inicialmente la sesión y al reautorizarla, no en cada segmento HLS/DASH. Los inicios masivos de reproducción y las comprobaciones repetidas generan carga en el backend. Este servicio requiere capacidad para procesar solicitudes, alta disponibilidad y baja latencia: sus respuestas afectan al inicio y la continuidad de la reproducción. JWT elimina esta dependencia mediante la validación local en el streamer.

Cómo se transmite el token

El token se acepta de dos formas:

  • Parámetro de URL — ?token=<token>, tiene prioridad.
  • Cabecera — Authorization: Bearer <token>, se utiliza si la URL no contiene el parámetro token.

Para HLS, basta con abrir la lista maestra con el token: Sapsan añade ?token= a todas las URL anidadas (variantes, segmentos, partes, init).

Backends de autorización externos

La decisión puede delegarse en backends HTTP:

auth:
  upstreams:
    main:
      url: http://backend.example.com/auth
      timeout_ms: 3000

Sapsan envía un POST a la url del backend con un cuerpo JSON:

{
  "kind": "play",
  "stream_name": "cam1",
  "proto": "hls",
  "user_agent": "Mozilla/5.0 ...",
  "token": "viewer-secret-1",
  "session_id": "..."
}

La decisión se toma según el estado HTTP de la respuesta (el cuerpo no se analiza):

  • 2xx — permitir;
  • 401 o 403 — denegar (la denegación se almacena en caché; una solicitud idéntica repetida no consulta al backend);
  • cualquier otro estado, indisponibilidad o superación de timeout_ms (1000 ms por defecto) — el backend se considera caído;
  • varios backends se consultan en paralelo: basta con una respuesta que permita el acceso; si solo hay denegaciones, se deniega; si todos los backends están indisponibles, se devuelve un error de backend no disponible, en lugar de una denegación silenciosa.

Sesiones

Una sesión HTTP agrupa las solicitudes por medio, tipo de acceso (play/publish), IP y token. User-Agent no forma parte de esta identidad. Varios dispositivos detrás de un mismo NAT con el mismo token pueden compartir una sesión; no es un identificador de dispositivo físico.

Las solicitudes de medios repetidas reutilizan la autorización de la sesión hasta que termina su ventana de autorización. Por defecto, el intervalo de reautorización es de 180 segundos; auth_duration en la configuración define otro intervalo y la cabecera de respuesta del backend X-AuthDuration lo sustituye. Si una nueva comprobación deniega el acceso, la sesión se cierra. Consulte autorización de la sesión y estadísticas.

Siguientes pasos