Perguntas frequentes sobre a fase de autenticação

Perguntas frequentes sobre a fase de autenticação

​1. Qual é a finalidade da Fase de autenticação?

A finalidade da Fase de autenticação é fornecer ao aplicativo cliente a capacidade de verificar a identidade do usuário e obter informações de metadados do usuário.

A Fase de autenticação atua como uma etapa de pré-requisito para a Fase de pré-autorização ou Fase de autorização quando o aplicativo cliente precisa reproduzir o conteúdo.

​2. A Fase de autenticação é obrigatória?

A Fase de autenticação é obrigatória. O aplicativo cliente deve autenticar o usuário quando ele não tiver um perfil válido na Autenticação do Adobe Pass.

O aplicativo cliente pode ignorar esta fase nos seguintes cenários:

  • O usuário já está autenticado e o perfil ainda é válido.
  • O usuário recebe acesso temporário por meio do recurso TempPass básico ou promocional.

O tratamento de erros de aplicativo cliente requer o tratamento de códigos de erro (por exemplo, authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated, etc.), que indicam que o aplicativo cliente requer a autenticação do usuário.

​3. O que é uma sessão de autenticação e por quanto tempo ela é válida?

A sessão de autenticação é um termo definido na documentação do Glossário.

A sessão de autenticação armazena informações sobre o processo de autenticação iniciado que podem ser recuperadas do endpoint de Sessões.

A sessão de autenticação é válida por um período curto e limitado especificado no momento da emissão pelo carimbo de data/hora notAfter, indicando o tempo que o usuário tem para concluir o processo de autenticação antes de exigir a reinicialização do fluxo.

O aplicativo cliente pode usar a resposta da sessão de autenticação para saber como proceder com o processo de autenticação. Observe que há casos em que o usuário não precisa se autenticar, como fornecer acesso temporário, acesso degradado ou quando o usuário já está autenticado.

Para obter mais informações, consulte os seguintes documentos:

​4. Qual é um código de autenticação e por quanto tempo ele é válido?

O código de autenticação é um termo definido na documentação do Glossário.

O código de autenticação armazena um valor exclusivo gerado quando um usuário inicia o processo de autenticação e identifica exclusivamente a sessão de autenticação de um usuário até que o processo seja concluído ou até que a sessão de autenticação expire.

O código de autenticação é válido por um período curto e limitado especificado no momento do início da sessão de autenticação pelo carimbo de data/hora notAfter, indicando o tempo que o usuário tem para concluir o processo de autenticação antes de solicitar a reinicialização do fluxo.

O aplicativo cliente pode usar o código de autenticação para verificar se o usuário concluiu com êxito a autenticação e recuperar as informações de perfil do usuário, normalmente por meio de um mecanismo de pesquisa.

O aplicativo cliente também pode usar o código de autenticação para permitir que o usuário conclua ou retome o processo de autenticação no mesmo dispositivo ou em um segundo (tela), considerando que a sessão de autenticação não expirou.

Para obter mais informações, consulte os seguintes documentos:

​5. Como o aplicativo cliente pode saber se o usuário digitou um código de autenticação válido e se a sessão de autenticação ainda não expirou?

O aplicativo cliente pode validar o código de autenticação digitado pelo usuário em um aplicativo secundário (tela) enviando uma solicitação a um dos pontos de extremidade das sessões responsáveis por retomar a sessão de autenticação ou recuperar as informações da sessão de autenticação associadas ao código de autenticação.

O aplicativo cliente receberia um erro se o código de autenticação fornecido fosse digitado incorretamente ou caso a sessão de autenticação expirasse.

Para obter mais informações, consulte os documentos Retomar sessão de autenticação e Recuperar sessão de autenticação.

​6. Como o aplicativo cliente pode saber se o usuário já está autenticado?

O aplicativo cliente pode consultar um dos seguintes endpoints, capazes de verificar se um usuário já está autenticado e retornar informações do perfil:

Para obter mais detalhes, consulte os seguintes documentos:

​7. Qual é um perfil e por quanto tempo ele é válido?

O perfil é um termo definido no Glossário.

O perfil armazena informações sobre a validade de autenticação do usuário, informações de metadados e muito mais que podem ser recuperadas do endpoint de Perfis.

O aplicativo cliente pode usar o perfil para saber o status de autenticação do usuário, acessar informações de metadados do usuário, encontrar o método usado para autenticar ou a entidade usada para fornecer a identidade.

Para obter mais detalhes, consulte os seguintes documentos:

O perfil é válido por um período limitado especificado quando consultado pelo carimbo de data/hora notAfter, indicando o tempo que o usuário tem uma autenticação válida antes de passar pela Fase de Autenticação novamente.

Esse período de tempo limitado, conhecido como autenticação (authN) TTL, pode ser visualizado e alterado no Painel TVE da Adobe Pass por um dos administradores da organização ou por um representante de Autenticação da Adobe Pass que atue em seu nome.

Para obter mais detalhes, consulte a documentação do Guia do Usuário de Integrações do Painel do TVE.

​8. O aplicativo cliente deve armazenar em cache as informações de perfil do usuário em um armazenamento persistente?

O aplicativo cliente deve armazenar em cache partes das informações de perfil do usuário em um armazenamento persistente para evitar solicitações desnecessárias e melhorar a experiência do usuário considerando os seguintes aspectos:

AtributoExperiência do usuário
mvpdO aplicativo cliente pode usá-lo para rastrear o provedor de TV selecionado pelo usuário e continuar a usá-lo durante as Fases de Pré-autorização ou Autorização.

Quando o perfil de usuário atual expira, o aplicativo cliente pode usar a seleção MVPD lembrada e solicitar apenas que o usuário confirme.
attributesO aplicativo cliente pode usar isso para personalizar a experiência do usuário com base em diferentes chaves de metadados de usuário (por exemplo, zip, maxRating etc.).

Os metadados do usuário ficam disponíveis após a conclusão do fluxo de autenticação, portanto, o aplicativo cliente não precisa consultar um ponto de extremidade separado para recuperar as informações de metadados do usuário, pois elas já estão incluídas nas informações do perfil.

Determinados atributos de metadados podem ser atualizados durante o fluxo de autorização, dependendo do MVPD e do atributo de metadados específico. Como resultado, o aplicativo cliente pode precisar consultar as APIs de perfis novamente para recuperar os metadados do usuário mais recentes.
notAfterO aplicativo cliente pode usar isso para rastrear a data de expiração do perfil do usuário.

A manipulação de erros do aplicativo cliente requer a manipulação de códigos de erro (por exemplo, authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated, etc.), o que indica que o aplicativo cliente requer a autenticação do usuário.

​9. O aplicativo cliente pode estender o perfil do usuário sem exigir reautenticação?

Não.

O perfil do usuário não pode ser estendido além de sua validade sem interação do usuário, pois sua expiração é determinada pelo TTL de autenticação estabelecido com MVPDs.

Portanto, o aplicativo cliente deve solicitar que o usuário se autentique novamente e interaja com a página de logon do MVPD para atualizar seu perfil no sistema.

No entanto, para os MVPDs que oferecem suporte à autenticação baseada em página inicial (HBA), o usuário não precisará inserir credenciais.

​10. Quais são os casos de uso para cada endpoint de Perfis disponível?

Os endpoints básicos de Perfis são projetados para fornecer ao aplicativo cliente a capacidade de saber o status de autenticação do usuário, acessar informações de metadados do usuário, encontrar o método usado para autenticar ou a entidade usada para fornecer identidade.

Cada endpoint se adapta a um caso de uso específico, da seguinte maneira:

APIDescriçãoCaso de uso
API de ponto de extremidade de perfisRecuperar todos os perfis de usuário.O usuário abre o aplicativo cliente pela primeira vez

Neste cenário, o aplicativo cliente não tem o identificador MVPD selecionado pelo usuário em cache no armazenamento persistente.

Como resultado, ele enviará uma única solicitação para recuperar todos os perfis de usuário disponíveis.
Ponto de extremidade de perfis para a API do MVPD específicaRecupere o perfil de usuário associado a uma MVPD específica.O usuário retorna ao aplicativo cliente após a autenticação em uma visita anterior

Nesse caso, o aplicativo cliente deve ter o identificador MVPD selecionado anteriormente pelo usuário em cache no armazenamento persistente.

Como resultado, ele enviará uma única solicitação para recuperar o perfil do usuário para essa MVPD específica.
Ponto de extremidade de perfis para API de código (autenticação) específicaRecupere o perfil de usuário associado a um código de autenticação específico.O usuário inicia o processo de autenticação

Neste cenário, o aplicativo cliente deve determinar se o usuário concluiu com êxito a autenticação e recuperar suas informações de perfil.

Como resultado, ele iniciará um mecanismo de sondagem para recuperar o perfil do usuário associado ao código de autenticação.

Para obter mais detalhes, consulte o Fluxo de perfis básicos executado no aplicativo primário e o Fluxo de perfis básicos executado em documentos do aplicativo secundário.

O endpoint de SSO de Perfis atende a uma finalidade diferente; ele fornece ao aplicativo cliente a capacidade de criar um perfil de usuário usando a resposta de autenticação do parceiro e recuperá-lo em uma única operação única.

APIDescriçãoCaso de uso
API de ponto de extremidade de SSO de perfisCriar e recuperar perfil de usuário usando resposta de autenticação de parceiro.O usuário permite que o aplicativo use logon único de parceiro para autenticação

Neste cenário, o aplicativo cliente deve criar um perfil de usuário depois de receber a resposta de autenticação de parceiro e recuperá-lo em uma única operação única.

Para qualquer consulta subsequente, os endpoints básicos de Perfis devem ser usados para determinar o status de autenticação do usuário, acessar as informações de metadados do usuário, encontrar o método usado para autenticar ou a entidade usada para fornecer a identidade.

Para obter mais detalhes, consulte os documentos Logon único usando fluxos de parceiros e Guia de Cookies do Apple SSO (REST API V2).

​11. O que o aplicativo cliente deve fazer se o usuário tiver vários perfis do MVPD?

A decisão de oferecer suporte a vários perfis depende das necessidades de negócios do aplicativo cliente.

A maioria dos usuários terá apenas um perfil. No entanto, nos casos em que existem vários perfis (conforme detalhado abaixo), o aplicativo cliente é responsável por determinar a melhor experiência do usuário para a seleção de perfis.

O aplicativo cliente pode optar por solicitar que o usuário selecione o perfil do MVPD desejado ou fazer a seleção automaticamente, como escolher o primeiro perfil de usuário da resposta ou aquele com o período de validade mais longo.

A REST API v2 é compatível com vários perfis para acomodar:

  • Usuários que podem precisar escolher entre um perfil MVPD comum e um obtido por meio do logon único (SSO).
  • Os usuários recebem acesso temporário sem precisar fazer logoff do MVPD normal.
  • Usuários com assinatura do MVPD combinada com serviços de Direto para o consumidor (DTC).
  • Usuários com várias assinaturas do MVPD.

​12. O que acontece quando os perfis de usuários expiram?

Quando os perfis de usuário expiram, eles não são mais incluídos na resposta do endpoint Perfis.

Se o endpoint de Perfis retornar uma resposta vazia do mapa de perfis, o aplicativo cliente deverá criar uma nova sessão de autenticação e solicitar que o usuário se autentique novamente.

Para obter mais informações, consulte a documentação da Criar API de sessão de autenticação.

​13. Quando os perfis de usuário se tornam inválidos?

Os perfis de usuário se tornam inválidos nos seguintes cenários:

  • Quando o TTL de autenticação expira, conforme indicado pelo carimbo de data/hora notAfter na resposta do ponto de extremidade Profiles.
  • Quando o aplicativo cliente altera o valor do cabeçalho AP-Device-Identifier.
  • Quando o aplicativo cliente atualiza, as credenciais de cliente usadas para recuperar o valor do cabeçalho Autorização.
  • Quando o aplicativo cliente revoga ou atualiza a instrução de software usada para obter credenciais do cliente.

​14. Quando o aplicativo cliente deve iniciar o mecanismo de polling?

Para garantir a eficiência e evitar solicitações desnecessárias, o aplicativo cliente deve iniciar o mecanismo de pesquisa nas seguintes condições:

Autenticação executada no aplicativo (tela) primário

O aplicativo principal (streaming) deve iniciar a pesquisa quando o usuário atingir a página de destino final, depois que o componente do navegador carregar a URL especificada para o parâmetro redirectUrl na solicitação de ponto de extremidade Sessões.

Autenticação executada em um aplicativo secundário (tela)

O aplicativo principal (transmissão) deve iniciar a sondagem assim que o usuário iniciar o processo de autenticação, logo após receber a resposta do ponto de extremidade Sessões e exibir o código de autenticação ao usuário.

​15. Quando o aplicativo cliente deve interromper o mecanismo de polling?

Para garantir a eficiência e evitar solicitações desnecessárias, o aplicativo cliente deve interromper o mecanismo de pesquisa nas seguintes condições:

Autenticação bem-sucedida

As informações de perfil do usuário foram recuperadas com êxito, confirmando o status de autenticação. Neste ponto, a pesquisa não é mais necessária.

Sessão de autenticação e expiração do código

A sessão de autenticação e o código expiram, conforme indicado pelo carimbo de data/hora notAfter (por exemplo, 30 minutos) na resposta do ponto de extremidade Sessões. Se isso acontecer, o usuário deverá reiniciar o processo de autenticação e a pesquisa usando o código de autenticação anterior deverá ser interrompida imediatamente.

Novo código de autenticação gerado

Se o usuário solicitar um novo código de autenticação no dispositivo principal (tela), a sessão existente não será mais válida e o polling usando o código de autenticação anterior deverá ser interrompido imediatamente.

​16. Que intervalo entre chamadas o aplicativo cliente deve usar para o mecanismo de sondagem?

Para garantir a eficiência e evitar solicitações desnecessárias, o aplicativo cliente deve configurar a frequência do mecanismo de polling nas seguintes condições:

Autenticação executada no aplicativo (tela) primárioAutenticação executada em um aplicativo secundário (tela)
O aplicativo principal (transmissão) deve pesquisar a cada 3-5 segundos ou mais.O aplicativo principal (transmissão) deve pesquisar a cada 3-5 segundos ou mais.

​17. Qual é o número máximo de solicitações de sondagem que o aplicativo cliente pode enviar?

O aplicativo cliente deve seguir os limites atuais definidos pelo Mecanismo de limitação da Autenticação Adobe Pass.

A manipulação de erros do aplicativo cliente deve poder manipular o código de erro 429 Muitas Solicitações, que indica que o aplicativo cliente excedeu o número máximo de solicitações permitidas.

Para obter mais detalhes, consulte a documentação do Mecanismo de limitação.

​18. Como o aplicativo cliente pode obter as informações de metadados do usuário?

O aplicativo cliente pode consultar um dos seguintes pontos de extremidade capazes de retornar informações de metadados do usuário como parte das informações do perfil:

Os metadados do usuário ficam disponíveis após a conclusão do fluxo de autenticação, portanto, o aplicativo cliente não precisa consultar um ponto de extremidade separado para recuperar as informações de metadados do usuário, pois elas já estão incluídas nas informações do perfil.

Para obter mais detalhes, consulte os seguintes documentos:

Determinados atributos de metadados podem ser atualizados durante o fluxo de autorização, dependendo do MVPD e do atributo de metadados específico. Como resultado, o aplicativo cliente pode precisar consultar as APIs acima novamente para recuperar os metadados do usuário mais recentes.

​19. Como o aplicativo cliente deve gerenciar o acesso degradado?

O Recurso de Degradação permite que o aplicativo cliente mantenha uma experiência de streaming contínua para os usuários, mesmo quando os serviços de autenticação ou autorização do MVPD tiverem problemas.

Em resumo, isso pode garantir acesso ininterrupto ao conteúdo, apesar das interrupções temporárias de serviço do MVPD.

Considerando que sua organização pretende usar o recurso de degradação premium, o aplicativo cliente deve lidar com fluxos de acesso degradados, que descrevem como os endpoints da API REST v2 se comportam nesses cenários.

Para obter mais detalhes, consulte a documentação dos Fluxos de acesso degradados.

​20. Como o aplicativo cliente deve gerenciar o acesso temporário?

O Recurso TempPass permite que o aplicativo cliente forneça acesso temporário ao usuário.

Em resumo, isso pode envolver os usuários fornecendo acesso limitado ao conteúdo ou a um número predefinido de títulos do VOD por um período especificado.

Considerando que sua organização pretende usar o recurso premium TempPass, o aplicativo cliente deve lidar com fluxos de acesso temporários, que descrevem como os endpoints da REST API v2 se comportam em tais cenários.

Em versões anteriores da API, o aplicativo cliente tinha que fazer logoff de um usuário autenticado com seu MVPD normal para oferecer acesso temporário.

Com a REST API v2, o aplicativo cliente pode alternar facilmente entre um MVPD comum e um TempPass MVPD ao autorizar um fluxo, eliminando a necessidade de o usuário ser desconectado.

Para obter mais detalhes, consulte a documentação dos Fluxos de acesso temporário.

​21. Como o aplicativo cliente deve gerenciar o acesso de logon único entre dispositivos?

A REST API v2 pode habilitar logon único entre dispositivos se o aplicativo cliente fornecer um identificador de usuário exclusivo consistente entre dispositivos.

Esse identificador, conhecido como token de serviço, deve ser gerado pelo aplicativo cliente por meio da implementação ou integração de um serviço de identidade externo de escolha.

Para obter mais detalhes, consulte a documentação do Logon único usando fluxos de token de serviço.

Perguntas frequentes da fase de pré-autorização

Perguntas frequentes sobre a fase de pré-autorização

​1. Qual é o objetivo da Fase de pré-autorização?

O objetivo da Fase de pré-autorização é fornecer ao aplicativo cliente a capacidade de apresentar um subconjunto de recursos de seu catálogo que o usuário teria direito de acessar.

A Fase de pré-autorização pode aprimorar a experiência do usuário quando ele abre o aplicativo do cliente pela primeira vez ou navega para uma nova seção.

​2. A fase de pré-autorização é obrigatória?

A Fase de pré-autorização não é obrigatória. O aplicativo cliente pode ignorar essa fase se quiser apresentar um catálogo de recursos sem filtrá-los primeiro com base nos direitos do usuário.

​3. O que é uma decisão de pré-autorização?

A pré-autorização é um termo definido na documentação do Glossário, enquanto o termo de decisão também pode ser encontrado no Glossário.

A decisão de pré-autorização armazena informações sobre o resultado da consulta do processo de pré-autorização do MVPD que pode ser recuperado do endpoint de Pré-autorização de decisões.

O aplicativo cliente pode usar as decisões de pré-autorização para apresentar um subconjunto de recursos que as decisões do Provedor de TV (informativas) permitiriam ao usuário acessar.

Para obter mais detalhes, consulte os seguintes documentos:

​4. O aplicativo cliente deve armazenar em cache as decisões de pré-autorização em um armazenamento persistente?

O aplicativo cliente não é necessário para armazenar decisões de pré-autorização no armazenamento persistente. No entanto, é recomendável armazenar em cache as decisões de permissão na memória para melhorar a experiência do usuário. Isso ajuda a evitar chamadas desnecessárias para o endpoint de Pré-autorização de Decisões para recursos que já foram pré-autorizados, reduzindo a latência e melhorando o desempenho.

​5. Como o aplicativo cliente pode determinar por que uma decisão de pré-autorização foi negada?

O aplicativo cliente pode determinar o motivo de uma decisão de pré-autorização negada ao inspecionar o código de erro e a mensagem incluídos na resposta do ponto de extremidade de Pré-autorização de Decisões. Esses detalhes fornecem ao insight o motivo específico pelo qual a solicitação de pré-autorização foi negada, ajudando a informar a experiência do usuário ou acionar qualquer manipulação necessária no aplicativo.

Certifique-se de que qualquer mecanismo de repetição implementado para recuperar decisões de pré-autorização não resulte em um loop infinito se a decisão de pré-autorização for negada.

Considere limitar as tentativas a um número razoável e lidar com as negações normalmente ao exibir comentários claros para o usuário.

​6. Por que a decisão de pré-autorização não tem um token de mídia?

A decisão de pré-autorização não tem um token de mídia porque a Fase de pré-autorização não deve ser usada para reproduzir recursos, pois essa é a finalidade da Fase de autorização.

​7. A fase de autorização pode ser ignorada se já existir uma decisão de pré-autorização?

Não.

A Fase de autorização não pode ser ignorada mesmo se uma decisão de pré-autorização estiver disponível. As decisões de pré-autorização são apenas informativas e não concedem direitos de reprodução reais. A Fase de pré-autorização tem como objetivo fornecer orientação antecipada, mas a Fase de autorização ainda é necessária antes de reproduzir qualquer conteúdo.

​8. Qual é um recurso e quais formatos são compatíveis?

O recurso é um termo definido no Glossário.

O recurso é um identificador exclusivo que foi acordado com os MVPDs e está associado a um conteúdo que o aplicativo cliente pode transmitir.

O identificador exclusivo do recurso pode ter dois formatos:

  • Um formato de string simples, como um identificador exclusivo de um canal (marca).
  • Um formato RSS de mídia (MRSS) com informações adicionais, como título, classificações e metadados de controle dos pais.

Para obter mais detalhes, consulte a documentação de Recursos Protegidos.

​9. Para quantos recursos o aplicativo cliente pode obter uma decisão de pré-autorização de cada vez?

O aplicativo cliente pode obter uma decisão de pré-autorização para um número limitado de recursos em uma única solicitação de API, geralmente até 5, devido a condições impostas pelos MVPDs.

Este número máximo de recursos pode ser exibido e alterado após a aceitação dos MVPDs por meio do Painel TVE da Adobe Pass por um dos administradores da organização ou por um representante da Autenticação Adobe Pass que atue em seu nome.

Para obter mais detalhes, consulte a documentação do Guia do Usuário de Integrações do Painel do TVE.

Perguntas frequentes sobre a fase de autorização

Perguntas frequentes sobre a fase de autorização

​1. Qual é o objetivo da fase de autorização?

A finalidade da Fase de autorização é fornecer ao aplicativo cliente a capacidade de reproduzir recursos que o usuário solicita após validar seus direitos com o MVPD.

​2. A fase de autorização é obrigatória?

A Fase de autorização é obrigatória, o aplicativo cliente não poderá ignorar essa fase se quiser reproduzir recursos que o usuário solicita, pois requer a verificação com o MVPD de que o usuário tem direito antes de liberar o fluxo.

​3. Qual é a decisão de autorização e por quanto tempo ela é válida?

A autorização é um termo definido na documentação do Glossário, enquanto o termo de decisão também pode ser encontrado no Glossário.

A decisão de autorização armazena informações sobre o resultado da consulta do processo de autorização do MVPD que pode ser recuperado do endpoint de autorização de decisões.

O aplicativo cliente pode usar a decisão de autorização contendo um token de mídia para reproduzir o fluxo de recursos, caso a decisão do Provedor de TV (autoritativo) permita que o usuário acesse-o.

Para obter mais detalhes, consulte os seguintes documentos:

A decisão de autorização é válida por um período limitado e curto especificado no momento da emissão, indicando a quantidade de tempo que será armazenada em cache pela Autenticação Adobe Pass antes de solicitar a consulta do MVPD novamente.

Este período de tempo limitado, conhecido como autorização (authZ) TTL, pode ser visualizado e alterado no Painel TVE da Adobe Pass por um dos administradores da sua organização ou por um representante da Autenticação da Adobe Pass que atue em seu nome.

Para obter mais detalhes, consulte a documentação do Guia do Usuário de Integrações do Painel do TVE.

​4. O aplicativo cliente deve armazenar em cache as decisões de autorização em um armazenamento persistente?

O aplicativo cliente não é necessário para armazenar decisões de autorização em armazenamento persistente.

​5. Como o aplicativo cliente pode determinar por que uma decisão de autorização foi negada?

O aplicativo cliente pode determinar o motivo de uma decisão de autorização negada ao inspecionar o código de erro e a mensagem incluídos na resposta do ponto de extremidade de Autorização de Decisões. Esses detalhes fornecem ao insight o motivo específico pelo qual a solicitação de autorização foi negada, ajudando a informar a experiência do usuário ou acionar qualquer manipulação necessária no aplicativo.

Certifique-se de que qualquer mecanismo de repetição implementado para recuperar decisões de autorização não resulte em um loop infinito se a decisão de autorização for negada.

Considere limitar as tentativas a um número razoável e lidar com as negações normalmente ao exibir comentários claros para o usuário.

​6. O que é um token de mídia e por quanto tempo ele é válido?

O token de mídia é um termo definido no Glossário.

O token de mídia consiste em uma sequência de caracteres assinada enviada em texto não criptografado que pode ser recuperada do endpoint da Autorização de decisões.

Para obter mais informações, consulte a documentação do Verificador de Token de Mídia.

O token de mídia é válido por um período limitado e curto especificado no momento da emissão, indicando o limite de tempo antes que ele seja verificado e usado pelo aplicativo cliente.

O aplicativo cliente pode usar o token de mídia para reproduzir um fluxo de recursos caso a decisão do Provedor de TV (autoritativo) permita que o usuário acesse-o.

Para obter mais detalhes, consulte os seguintes documentos:

​7. O aplicativo cliente deve validar o token de mídia antes de reproduzir o fluxo de recursos?

Sim.

O aplicativo cliente deve validar o token de mídia antes de iniciar a reprodução do fluxo de recursos. Esta validação deve ser executada usando o Verificador de Token de Mídia. Ao verificar o serializedToken do token retornado, o aplicativo cliente ajuda a impedir o acesso não autorizado, como a cópia de fluxo, e garante que somente os usuários devidamente autorizados possam reproduzir o conteúdo.

​8. O aplicativo cliente deve atualizar um token de mídia expirado durante a reprodução?

Não.

O aplicativo cliente não é necessário para atualizar um token de mídia expirado enquanto o fluxo estiver sendo reproduzido ativamente. Se o token de mídia expirar durante a reprodução, o fluxo deverá continuar sem interrupções. No entanto, o cliente deve solicitar uma nova decisão de autorização — e obter um novo token de mídia — na próxima vez que o usuário tentar reproduzir um recurso.

​9. Qual é o objetivo de cada atributo de carimbo de data e hora na decisão de autorização?

A decisão de autorização inclui vários atributos de carimbo de data e hora que fornecem contexto essencial sobre o período de validade da própria autorização e o token de mídia associado. Esses carimbos de data e hora atendem a diferentes finalidades, dependendo se estão relacionados à decisão de autorização ou ao token de mídia.

Carimbos de data e hora de nível de decisão

Estes carimbos de data e hora descrevem o período de validade da decisão de autorização geral:

AtributoDescriçãoNotas
notBeforeO tempo em milissegundos durante o qual a decisão de autorização foi emitida.Isso marca o início da janela de validade da autorização.
notAfterO tempo em milissegundos quando a decisão de autorização expira.O TTL (Time-to-Live) de autorização determina por quanto tempo a autorização permanece válida antes de ser necessária uma nova autorização. Esse TTL é negociado com representantes da MVPD.

Carimbos de Data/Hora no Nível do Token

Esses carimbos de data e hora descrevem o período de validade do token de mídia vinculado à decisão de autorização:

AtributoDescriçãoNotas
notBeforeO tempo em milissegundos durante o qual o token de mídia foi emitido.Isso marca quando o token se torna válido para reprodução.
notAfterO tempo em milissegundos quando o token de mídia expira.Os tokens de mídia têm uma vida útil deliberadamente curta (normalmente 7 minutos) para minimizar riscos de uso incorreto e levar em conta possíveis diferenças de relógio entre o servidor gerador de tokens e o servidor de verificação de token.

​10. O que é um recurso e quais formatos são compatíveis?

O recurso é um termo definido no Glossário.

O recurso é um identificador exclusivo que foi acordado com os MVPDs e está associado a um conteúdo que o aplicativo cliente pode transmitir.

O identificador exclusivo do recurso pode ter dois formatos:

  • Um formato de string simples, como um identificador exclusivo de um canal (marca).
  • Um formato RSS de mídia (MRSS) com informações adicionais, como título, classificações e metadados de controle dos pais.

Para obter mais detalhes, consulte a documentação de Recursos Protegidos.

​11. Para quantos recursos o aplicativo cliente pode obter uma decisão de autorização de cada vez?

O aplicativo cliente pode obter uma decisão de autorização para um número limitado de recursos em uma única solicitação de API, geralmente até 1, devido a condições impostas pelos MVPDs.