Skip to content

Backend de autorização

media.access.auth_backend

O backend HTTP de autorização é um mecanismo obsoleto (deprecated), não recomendado para novas integrações. Para novas integrações, use o JWT do espectador: a aplicação obtém um token assinado pela API do central, e os edges o validam localmente. O backend HTTP é mantido para compatibilidade com instalações existentes.

Na autorização HTTP, o streamer consulta o backend ao autorizar inicialmente a sessão e ao reautorizá-la, não a cada segmento HLS/DASH. Muitos inícios de reprodução simultâneos e verificações repetidas geram carga no backend. Esse serviço exige capacidade de processamento de solicitações, alta disponibilidade e baixa latência: suas respostas afetam o início e a continuidade da reprodução. O JWT elimina essa dependência com a validação local no streamer.

Como o token é transmitido

O token é aceito de duas formas:

  • Parâmetro da URL — ?token=<token>, tem prioridade.
  • Cabeçalho — Authorization: Bearer <token>, usado quando não há parâmetro token na URL.

Para HLS, basta abrir a playlist mestre com o token: o Sapsan adiciona ?token= a todas as URLs aninhadas (variantes, segmentos, partes, init).

Backends externos de autorização

A decisão pode ser delegada a backends HTTP:

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

O Sapsan envia um POST à url do backend com um corpo JSON:

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

A decisão é tomada pelo status HTTP da resposta (o corpo não é interpretado):

  • 2xx — permitir;
  • 401 ou 403 — negar (a recusa fica em cache; uma solicitação idêntica repetida não consulta o backend);
  • qualquer outro status, indisponibilidade ou estouro de timeout_ms (1000 ms por padrão) — o backend é considerado fora de serviço;
  • vários backends são consultados em paralelo: uma resposta de permissão é suficiente; se houver apenas recusas, o acesso é negado; se todos os backends estiverem indisponíveis, é retornado um erro de backend indisponível, em vez de uma recusa silenciosa.

Sessões

Uma sessão HTTP agrupa solicitações por mídia, tipo de acesso (play/publish), IP e token. O User-Agent não faz parte dessa identidade. Vários dispositivos atrás do mesmo NAT com o mesmo token podem compartilhar uma sessão; ela não é um identificador de dispositivo físico.

As solicitações de mídia repetidas reutilizam a autorização da sessão até o fim da janela de autorização. O intervalo padrão de reautorização é de 180 segundos; auth_duration na configuração define outro intervalo, e o cabeçalho de resposta do backend X-AuthDuration o substitui. Se uma nova verificação negar o acesso, a sessão será encerrada. Veja autorização da sessão e estatísticas.

Próximos passos