Perguntas frequentes sobre REST API V2
- Tópicos:
- Authentication
IMPORTANTEste documento fornece respostas de alta visão geral para perguntas frequentes sobre a adoção da API REST V2 de autenticação da Adobe Pass.
Para obter mais informações sobre a REST API V2 como um todo, consulte a Documentação de Visão geral da REST API V2.
Perguntas frequentes gerais
Comece com esta seção se estiver trabalhando em um aplicativo que precise integrar a REST API V2, seja um aplicativo novo ou existente que migre da REST API V1 ou do SDK.
Para obter mais informações sobre detalhes e etapas da migração, consulte também as próximas seções.
Perguntas frequentes sobre a fase de registro
Perguntas frequentes sobre a fase de registro
Perguntas frequentes sobre a fase de configuração
Perguntas frequentes sobre a fase de configuração
1. Qual é a finalidade da fase de configuração?
A finalidade da Fase de Configuração é fornecer ao aplicativo cliente a lista de MVPDs com os quais ele está ativamente integrado, juntamente com os detalhes de configuração (por exemplo, id, displayName, logoUrl, etc.) salvos pela Autenticação Adobe Pass para cada MVPD.
A Fase de configuração atua como uma etapa de pré-requisito para a Fase de autenticação quando o aplicativo cliente precisa solicitar que o usuário selecione o Provedor de TV.
2. A Fase de configuração é obrigatória?
A Fase de configuração não é obrigatória. O aplicativo cliente deve recuperar a configuração somente quando o usuário precisar selecionar o MVPD para autenticar ou autenticar novamente.
O aplicativo cliente pode ignorar esta fase nos seguintes cenários:
- O usuário já está autenticado.
- O usuário recebe acesso temporário por meio do recurso TempPass básico ou promocional.
- A autenticação do usuário expirou, mas o aplicativo cliente armazenou em cache o MVPD selecionado anteriormente como uma escolha motivada por experiência do usuário e solicita que o usuário confirme que ainda é assinante desse MVPD.
3. O que é uma configuração e por quanto tempo ela é válida?
A configuração é um termo definido no Glossário.
A configuração contém uma lista de MVPDs definidos pelos seguintes atributos id, displayName, logoUrl, etc., que podem ser recuperados do ponto de extremidade Configuração.
O aplicativo cliente deve recuperar a configuração somente quando o usuário precisar selecionar o MVPD para autenticar ou autenticar novamente.
O aplicativo cliente pode usar a resposta de configuração para apresentar um seletor de interface do usuário com opções de MVPD disponíveis sempre que o usuário precisar selecionar seu provedor de TV.
O aplicativo cliente deve armazenar o identificador MVPD selecionado pelo usuário, conforme especificado pelo atributo de nível de configuração id da MVPD, para continuar com as fases de Autenticação, Pré-autorização, Autorização ou Logout.
Para obter mais informações, consulte a documentação Recuperar configuração.
4. O aplicativo cliente deve armazenar em cache as informações de resposta da configuração em um armazenamento persistente?
O aplicativo cliente deve recuperar a configuração somente quando o usuário precisar selecionar o MVPD para autenticar ou autenticar novamente.
O aplicativo cliente deve armazenar as informações de resposta da configuração em cache em um armazenamento de memória para evitar solicitações desnecessárias e melhorar a experiência do usuário quando:
- O usuário já está autenticado.
- O usuário recebe acesso temporário por meio do recurso TempPass básico ou promocional.
- A autenticação do usuário expirou, mas o aplicativo cliente armazenou em cache o MVPD selecionado anteriormente como uma escolha motivada por experiência do usuário e solicita que o usuário confirme que ainda é assinante desse MVPD.
5. O aplicativo cliente pode gerenciar sua própria lista de MVPDs?
O aplicativo cliente pode gerenciar sua própria lista de MVPDs, mas seria necessário manter os identificadores do MVPD sincronizados com a Autenticação do Adobe Pass. Portanto, é recomendável usar a configuração fornecida pela Autenticação Adobe Pass para garantir que a lista esteja atualizada e precisa.
O aplicativo cliente receberia um erro da API REST V2 de Autenticação do Adobe Pass se o identificador do MVPD fornecido fosse inválido ou caso não tivesse uma integração ativa com o provedor de serviços especificado.
6. O aplicativo cliente pode filtrar a lista de MVPDs?
O aplicativo cliente pode filtrar a lista de MVPDs fornecida na resposta de configuração implementando um mecanismo personalizado com base em sua própria lógica de negócios e requisitos, como localização do usuário ou histórico de usuário de seleção anterior.
O aplicativo cliente pode filtrar a lista de TempPass MVPDs ou os MVPDs que ainda têm sua integração em desenvolvimento ou teste.
7. O que acontece se a integração com uma MVPD for desativada e marcada como inativa?
Quando a integração com uma MVPD é desativada e marcada como inativa, o MVPD é removido da lista de MVPDs fornecidos em outras respostas de configuração e há duas consequências importantes a serem consideradas:
- Os usuários não autenticados desse MVPD não poderão mais concluir a Fase de autenticação usando esse MVPD.
- Os usuários autenticados desse MVPD não poderão mais concluir as Fases de pré-autorização, autorização ou logout usando esse MVPD.
O aplicativo cliente receberia um erro da API REST V2 de Autenticação do Adobe Pass se o usuário selecionado no MVPD não tivesse mais uma integração ativa com o provedor de serviços especificado.
8. O que acontece se a integração com uma MVPD for habilitada novamente e marcada como ativa?
Quando a integração com uma MVPD é habilitada e marcada como ativa, o MVPD é incluído de volta na lista de MVPDs fornecidos em outras respostas de configuração e há duas consequências importantes a serem consideradas:
- Os usuários não autenticados desse MVPD poderão concluir novamente a Fase de autenticação usando esse MVPD.
- Os usuários autenticados desse MVPD poderão concluir novamente as Fases de pré-autorização, autorização ou logout usando esse MVPD.
9. Como ativar ou desativar a integração com uma MVPD?
Esta operação pode ser concluída por meio do Painel do 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.
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:
- Criar API de sessão de autenticação
- Retomar API de sessão de autenticação
- Fluxo de autenticação básica executado no aplicativo principal
- Fluxo de autenticação básico executado no aplicativo secundário
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:
- Criar API de sessão de autenticação
- Retomar API de sessão de autenticação
- Fluxo de autenticação básica executado no aplicativo principal
- Fluxo de autenticação básico executado no aplicativo secundário
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:
- API do endpoint de perfis
- Endpoint de perfis para API MVPD específica
- Endpoint de perfis para API de código específica (autenticação)
Para obter mais detalhes, consulte os seguintes documentos:
- Fluxo de perfis básicos realizado no aplicativo principal
- Fluxo de perfis básicos realizado no aplicativo secundário
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:
- API do endpoint de perfis
- Endpoint de perfis para API MVPD específica
- Endpoint de perfis para API de código específica (autenticação)
- Fluxo de perfis básicos realizado no aplicativo principal
- Fluxo de perfis básicos realizado no aplicativo secundário
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:
mvpdQuando 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.
attributeszip, 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.
notAfterA 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:
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.
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.
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.
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
notAfterna 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:
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:
- API do endpoint de perfis
- Endpoint de perfis para API MVPD específica
- Endpoint de perfis para API de código específica (autenticação)
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:
- Fluxo de perfis básicos realizado no aplicativo principal
- Fluxo de perfis básicos realizado no aplicativo secundário
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
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:
- Recuperar API de decisões de pré-autorização
- Fluxo básico de pré-autorização executado no aplicativo principal
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 informações sobre 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
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:
- Recuperar API de decisões de autorização
- Fluxo de autorização básico executado no aplicativo principal
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 informações sobre 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:
- Recuperar API de decisões de autorização
- Fluxo de autorização básico executado no aplicativo principal
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:
notBeforenotAfterCarimbos 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:
notBeforenotAfter10. 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.
Perguntas frequentes sobre a fase de logout
1. Qual é a finalidade da Fase de logout?
A finalidade da Fase de logout é fornecer ao aplicativo cliente a capacidade de encerrar o perfil autenticado do usuário na Autenticação do Adobe Pass mediante solicitação do usuário.
2. A Fase de logout é obrigatória?
A Fase de logout é obrigatória, o aplicativo cliente deve fornecer ao usuário a capacidade de fazer logout.
Perguntas frequentes sobre cabeçalhos
1. Como calcular o valor do cabeçalho de autorização?
IMPORTANTBearer como antes.O cabeçalho de solicitação Authorization contém o token de acesso Bearer exigido pelo aplicativo cliente para acessar APIs protegidas pelo Adobe Pass.
O valor do cabeçalho de Autorização deve ser obtido da Autenticação Adobe Pass durante a Fase de Registro.
Para obter mais detalhes, consulte os seguintes documentos:
- Visão geral do registro dinâmico do cliente
- Recuperar API de credenciais do cliente
- Recuperar API do token de acesso
- Fluxo de registro dinâmico do cliente
2. Como calcular o valor do cabeçalho AP-Device-Identifier?
IMPORTANTO cabeçalho de solicitação AP-Device-Identifier contém o identificador do dispositivo de streaming conforme foi criado pelo aplicativo cliente.
A documentação do cabeçalho AP-Device-Identifier fornece exemplos para as principais plataformas de como calcular o valor, mas o aplicativo cliente pode optar por usar um método diferente com base em sua própria lógica e requisitos de negócios.
3. Como calcular o valor do cabeçalho X-Device-Info?
IMPORTANTO cabeçalho de solicitação X-Device-Info contém as informações do cliente (dispositivo, conexão e aplicativo) relacionadas ao dispositivo de streaming real e é usado para determinar regras específicas da plataforma que os MVPDs podem impor.
A documentação do cabeçalho X-Device-Info fornece exemplos para as principais plataformas de como calcular o valor, mas o aplicativo cliente pode optar por usar um método diferente com base em sua própria lógica e requisitos de negócios.
Se o cabeçalho X-Device-Info estiver ausente ou contiver valores incorretos, a solicitação poderá ser classificada como originária de uma plataforma unknown.
Isso pode fazer com que a solicitação seja tratada como insegura e sujeita a regras mais restritivas, como TTLs de autenticação mais curtas. Além disso, alguns campos, como o dispositivo de streaming connectionIp e connectionPort, são obrigatórios para recursos como a Autenticação da Base Inicial do Spectrum.
Mesmo quando a solicitação é originada de um servidor em nome de um dispositivo, o valor do cabeçalho X-Device-Info deve refletir as informações reais do dispositivo de streaming.
Perguntas frequentes diversas
1. Posso explorar solicitações e respostas da API REST V2 e testar a API?
Sim.
Você pode explorar a REST API V2 através do nosso site dedicado Adobe Developer. O site do Adobe Developer fornece acesso irrestrito a:
Para interagir com a REST API V2, você deve incluir o cabeçalho Autorização com um token de acesso Bearer obtido por meio da DCR API.
Para usar a API DCR, é necessária uma instrução de software com o escopo REST API V2. Para obter mais detalhes, consulte o documento Perguntas frequentes sobre o Dynamic Client Registration (DCR).
2. Posso explorar solicitações e respostas da REST API V2 usando uma ferramenta de desenvolvimento de API com suporte a OpenAPI?
Sim.
Você pode baixar arquivos de especificação OpenAPI para a API DCR e a API REST V2 do site Adobe Developer.
Para baixar os arquivos de especificação OpenAPI, clique nos botões de download para salvar os seguintes arquivos no computador local:
Em seguida, você pode importar esses arquivos para sua ferramenta de desenvolvimento de API preferida para explorar solicitações e respostas da API REST V2 e testar a API.
3. Ainda posso usar a ferramenta de teste de API existente hospedada em https://sp.auth-staging.adobe.com/apitest/api.html?
Não.
Os aplicativos clientes que estão migrando para a REST API V2 devem usar a nova ferramenta de teste hospedada em https://developer.adobe.com/adobe-pass/. O site do Adobe Developer fornece acesso irrestrito a:
Para interagir com a REST API V2, você deve incluir o cabeçalho Autorização com um token de acesso Bearer obtido por meio da DCR API.
Para usar a API DCR, é necessária uma instrução de software com o escopo REST API V2. Para obter mais detalhes, consulte o documento Perguntas frequentes sobre o Dynamic Client Registration (DCR).
Perguntas frequentes sobre migração
Prossiga com esta seção se estiver trabalhando em um aplicativo que precise migrar um aplicativo existente para a REST API V2.
Perguntas frequentes gerais sobre migração
1. Sou obrigado a implantar um novo aplicativo cliente migrado para a REST API V2 para todos os usuários de uma só vez?
Não.
O aplicativo cliente não é necessário para implantar uma nova versão que integre a REST API V2 a todos os usuários simultaneamente.
A Autenticação do Adobe Pass continuará a ser compatível com versões mais antigas do aplicativo cliente integrando a REST API V1 ou o SDK até o final de 2025.
2. Sou obrigado a implantar um novo aplicativo cliente migrado para a REST API V2 em todas as APIs e fluxos de uma só vez?
Sim.
O aplicativo cliente é necessário para implantar uma nova versão que integre a REST API V2 em todas as APIs de autenticação da Adobe Pass e flui simultaneamente.
No caso do fluxo 'segunda autenticação de tela', o aplicativo cliente é necessário para implantar uma nova versão integrando a API REST V2 para os aplicativos primário e secundário simultaneamente.
A autenticação do Adobe Pass não oferecerá suporte a implementações "híbridas" que integram a REST API V2 e a REST API V1/SDK entre APIs e fluxos.
3. A autenticação do usuário será preservada ao atualizar para um novo aplicativo cliente migrado para a REST API V2?
Não.
A autenticação de usuário obtida em versões anteriores do aplicativo cliente que integram a REST API V1 ou o SDK não será preservada.
Portanto, o usuário precisará autenticar novamente no novo aplicativo cliente migrado para a REST API V2.
4. Os códigos de erro aprimorados estão habilitados por padrão na REST API V2?
Sim.
Por padrão, os aplicativos clientes que migram para a REST API V2 se beneficiam automaticamente desse recurso, fornecendo informações de erro mais detalhadas e precisas.
Para obter mais detalhes, consulte a documentação dos Códigos de erro aprimorados.
5. As integrações existentes exigem alterações de configuração ao migrar para a REST API V2?
Não.
Os aplicativos clientes que estão migrando para a REST API V2 não exigem alterações de configuração nas integrações existentes do MVPD. Além disso, eles continuarão a usar os mesmos identificadores para os provedores de serviços e MVPDs existentes.
Além disso, os protocolos usados pela Autenticação Adobe Pass para se comunicar com os endpoints do MVPD permanecem inalterados.
Migração da REST API V1 para REST API V2
Prossiga com esta subseção se estiver trabalhando em um aplicativo que precise migrar da API REST V1 para a API REST V2.
Perguntas frequentes sobre a fase de registro
1. Quais são as migrações de API de alto nível necessárias para a fase de registro?
Na migração da REST API V1 para a REST API V2, não há alterações de alto nível em relação à Fase de registro.
O aplicativo cliente pode continuar a usar o mesmo fluxo para se registrar na Autenticação Adobe Pass por meio do processo Registro Dinâmico de Cliente (DCR) e obter um token de acesso.
Para obter mais informações, consulte os seguintes documentos:
Perguntas frequentes sobre a fase de configuração
1. Quais são as migrações de API de alto nível necessárias para a fase de configuração?
Na migração da REST API V1 para REST API V2, há alterações de alto nível a serem consideradas que são apresentadas na tabela a seguir:
Perguntas frequentes sobre a fase de autenticação
1. Quais são as migrações de API de alto nível necessárias para a Fase de autenticação?
Na migração da REST API V1 para REST API V2, há alterações de alto nível a serem consideradas que são apresentadas na tabela a seguir:
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
Perguntas frequentes da fase de pré-autorização
1. Quais são as migrações de API de alto nível necessárias para a fase de pré-autorização?
Na migração da REST API V1 para REST API V2, há alterações de alto nível a serem consideradas que são apresentadas na tabela a seguir:
Para obter mais detalhes, consulte os seguintes documentos:
Perguntas frequentes sobre a fase de autorização
1. Quais são as migrações de API de alto nível necessárias para a fase de autorização?
Na migração da REST API V1 para REST API V2, há alterações de alto nível a serem consideradas que são apresentadas na tabela a seguir:
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
- Iniciar autorização do (MVPD)
- Recuperar decisão de autorização
- Recuperar token de mídia curto
Para obter mais detalhes, consulte os seguintes documentos:
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
- Iniciar autorização do (MVPD)
- Recuperar decisão de autorização
- Recuperar token de mídia curto
Para obter mais detalhes, consulte os seguintes documentos:
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
- Iniciar autorização do (MVPD)
- Recuperar decisão de autorização
- Recuperar token de mídia curto
Para obter mais detalhes, consulte os seguintes documentos:
Perguntas frequentes sobre a fase de logout
1. Quais são as migrações de API de alto nível necessárias para a Fase de logout?
Na migração da REST API V1 para REST API V2, há alterações de alto nível a serem consideradas que são apresentadas na tabela a seguir:
Para obter mais detalhes, consulte os seguintes documentos:
Migração do SDK para a REST API V2
Prossiga com esta subseção se estiver trabalhando em um aplicativo que precise migrar do SDK para a REST API V2.
Perguntas frequentes sobre a fase de registro
1. Quais são as migrações de API de alto nível necessárias para a fase de registro?
Na migração dos SDKs para a REST API V2, há alterações de alto nível a serem consideradas que são apresentadas nas seguintes tabelas:
AccessEnabler JavaScript SDK
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler iOS/tvOS SDK
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler Android SDK
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler FireOS SDK
Para obter mais detalhes, consulte os seguintes documentos:
Perguntas frequentes sobre a fase de configuração
1. Quais são as migrações de API de alto nível necessárias para a fase de configuração?
Na migração dos SDKs para a REST API V2, há alterações de alto nível a serem consideradas que são apresentadas nas seguintes tabelas:
AccessEnabler JavaScript SDK
AccessEnabler iOS/tvOS SDK
AccessEnabler Android SDK
AccessEnabler FireOS SDK
Perguntas frequentes sobre a fase de autenticação
1. Quais são as migrações de API de alto nível necessárias para a Fase de autenticação?
Na migração dos SDKs para a REST API V2, há alterações de alto nível a serem consideradas que são apresentadas nas seguintes tabelas:
AccessEnabler JavaScript SDK
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler iOS SDK
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler tvOS SDK
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler Android SDK
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler FireOS SDK
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
O aplicativo cliente pode usar a resposta dessas APIs para vários propósitos de uma só vez:
- Verificar status de autenticação do usuário
- Recuperar perfil de usuário
- Recuperar informações de metadados do usuário
Para obter mais detalhes, consulte os seguintes documentos:
Perguntas frequentes da fase de pré-autorização
1. Quais são as migrações de API de alto nível necessárias para a fase de pré-autorização?
Na migração dos SDKs para a REST API V2, há alterações de alto nível a serem consideradas que são apresentadas nas seguintes tabelas:
AccessEnabler JavaScript SDK
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler iOS/tvOS SDK
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler Android SDK
Para obter mais detalhes, consulte os seguintes documentos:
Para obter mais detalhes, consulte os seguintes documentos:
Perguntas frequentes sobre a fase de autorização
1. Quais são as migrações de API de alto nível necessárias para a fase de autorização?
Na migração dos SDKs para a REST API V2, há alterações de alto nível a serem consideradas que são apresentadas nas seguintes tabelas:
AccessEnabler JavaScript SDK
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
- Iniciar autorização do (MVPD)
- Recuperar decisão de autorização
- Recuperar token de mídia curto
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler iOS/tvOS SDK
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
- Iniciar autorização do (MVPD)
- Recuperar decisão de autorização
- Recuperar token de mídia curto
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler Android SDK
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
- Iniciar autorização do (MVPD)
- Recuperar decisão de autorização
- Recuperar token de mídia curto
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler FireOS SDK
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
- Iniciar autorização do (MVPD)
- Recuperar decisão de autorização
- Recuperar token de mídia curto
Para obter mais detalhes, consulte os seguintes documentos:
Perguntas frequentes sobre a fase de logout
1. Quais são as migrações de API de alto nível necessárias para a Fase de logout?
Na migração dos SDKs para a REST API V2, há alterações de alto nível a serem consideradas que são apresentadas nas seguintes tabelas:
AccessEnabler JavaScript SDK
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler iOS/tvOS SDK
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler Android SDK
Para obter mais detalhes, consulte os seguintes documentos:
AccessEnabler FireOS SDK
Para obter mais detalhes, consulte os seguintes documentos: