Perguntas frequentes sobre REST API V2 rest-api-v2-faqs
Este 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 general-faqs
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.
1. Qual é o objetivo da Fase de Registro? registration-phase-faq1
A finalidade da Fase de Registro é registrar o aplicativo cliente na Autenticação Adobe Pass por meio do processo de Registro Dinâmico de Cliente (DCR).
O processo de Registro dinâmico de cliente (DCR) exige que o aplicativo cliente obtenha um par de credenciais de cliente e recupere um token de acesso como meta final da fase de registro.
Para obter mais informações, consulte a documentação Visão geral do registro dinâmico do cliente.
2. A fase de registro é obrigatória? registration-phase-faq2
A Fase de Registro é obrigatória, mas o aplicativo cliente poderá ignorar essa fase se tiver um par de credenciais de cliente em cache e um token de acesso que ainda seja válido.
3. O que é uma declaração de software e por quanto tempo ela é válida? registration-phase-faq3
A instrução de software é um termo definido na documentação do Glossário.
A instrução de software consiste em um JSON Web Token (JWT) que pode ser gerado e baixado do Painel TVE do Adobe Pass por um dos administradores da organização ou por um representante de Autenticação Adobe Pass que atua em seu nome.
A declaração do software é válida por um período ilimitado, mas você pode solicitar que um representante da Autenticação da Adobe Pass a revogue a qualquer momento.
O aplicativo cliente deve armazenar a instrução de software e usá-la quando precisar recuperar credenciais de cliente.
Para obter mais detalhes, consulte a documentação Visão geral do registro dinâmico do cliente.
4. Como gerar e baixar uma instrução de software? registration-phase-faq4
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 Canais do Painel do TVE ou o Guia do Usuário de Programadores do Painel do TVE.
5. O que acontece se uma instrução de software for revogada? registration-phase-faq5
Quando a declaração de software for revogada, há uma consequência importante a ser considerada:
- Os aplicativos cliente que usam a instrução de software revogada não poderão mais passar pelos fluxos direitos, o que significa que os usuários serão impedidos de reproduzir conteúdo.
6. Quais são as credenciais do cliente e por quanto tempo elas são válidas? registration-phase-faq6
As credenciais do cliente são um termo definido na documentação do Glossário.
As credenciais do cliente consistem em um identificador do cliente e um par de segredos do cliente que podem ser recuperados do ponto de extremidade do Registro do cliente.
As credenciais do cliente são válidas por um período ilimitado.
O aplicativo cliente deve armazenar indefinidamente as credenciais do cliente e usá-las quando precisar recuperar um token de acesso.
Para obter mais informações, consulte a documentação Recuperar credenciais do cliente.
7. Como gerenciar credenciais do cliente? registration-phase-faq7
Recomendamos que o aplicativo cliente gerencie um par exclusivo de credenciais do cliente para cada instância do aplicativo do usuário no caso de integrações cliente para servidor e servidor para servidor com a Autenticação do Adobe Pass.
O aplicativo cliente deve armazenar indefinidamente as credenciais do cliente e usá-las quando precisar recuperar um token de acesso.
8. O que acontece se as credenciais de cliente em cache forem perdidas? registration-phase-faq8
Quando as credenciais de cliente em cache são perdidas, há três consequências importantes a serem consideradas:
- O aplicativo cliente deve obter um novo par de credenciais de cliente.
- O aplicativo cliente deve obter um novo token de acesso usando o novo par de credenciais do cliente.
- O aplicativo cliente precisará solicitar ao usuário uma nova autenticação, pois o aplicativo cliente perderá o acesso aos perfis autenticados obtidos anteriormente.
9. O que é um token de acesso e por quanto tempo ele é válido? registration-phase-faq9
O token de acesso é um termo definido no Glossário.
O token de acesso consiste em um token de portador que pode ser recuperado do ponto de extremidade do Token de Cliente.
O token de acesso é válido por um período limitado e curto especificado no momento da emissão.
O aplicativo cliente deve armazenar o token de acesso e usá-lo até que expire ao direcionar a API REST V2.
O aplicativo cliente deve obter um novo token de acesso antes que o atual expire para evitar solicitações não autorizadas.
Para obter mais informações, consulte a documentação Recuperar token de acesso.
10. Como o aplicativo cliente pode atualizar um token de acesso? registration-phase-faq10
O aplicativo cliente deve atualizar um token de acesso da mesma forma que recuperar um novo token de acesso, mas usando credenciais de cliente em cache.
O aplicativo cliente não deve se registrar novamente para atualizar um token de acesso. Em vez disso, ele deve usar as credenciais de cliente armazenadas, caso contrário, os usuários precisarão se autenticar novamente.
Para obter mais informações, consulte a documentação Recuperar token de acesso.
1. Qual é a finalidade da fase de configuração? configuration-phase-faq1
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 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? configuration-phase-faq2
A Fase de configuração não é obrigatória, o aplicativo cliente pode ignorar essa 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 é um assinante desse MVPD.
3. O que é uma configuração e por quanto tempo ela é válida? configuration-phase-faq3
A configuração é um termo definido no Glossário.
A configuração consiste em uma lista de MVPDs que podem ser recuperados do endpoint de Configuração.
O aplicativo cliente pode usar a configuração para apresentar um componente da interface chamado "Seletor" ao exigir que o usuário selecione seu MVPD.
O aplicativo cliente deve atualizar a configuração antes que o usuário passe pela Fase de autenticação.
Para obter mais informações, consulte a documentação Recuperar configuração.
4. O aplicativo cliente pode gerenciar sua própria lista de MVPDs? configuration-phase-faq4
O aplicativo cliente pode gerenciar sua própria lista de MVPDs, mas é 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 usuário selecionado não tivesse uma integração ativa com o provedor de serviços especificado.
5. O aplicativo cliente pode filtrar a lista de MVPDs? configuration-phase-faq5
O aplicativo cliente pode filtrar a lista de MVPDs fornecida na resposta de configuração implementando um mecanismo personalizado com base na 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.
6. O que acontece se a integração com um MVPD for desativada e marcada como inativa? configuration-phase-faq6
Quando a integração com um MVPD estiver desativada e marcada como inativa, o MVPD será removido da lista de MVPDs fornecidos em outras respostas de configuração e haverá 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 não tivesse mais uma integração ativa com o provedor de serviços especificado.
7. O que acontece se a integração com um MVPD for habilitada e marcada como ativa? configuration-phase-faq7
Quando a integração com um MVPD é habilitada e marcada como ativa, o MVPD é incluído de volta na lista de MVPDs fornecida 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.
8. Como ativar ou desativar a integração com um MVPD? configuration-phase-faq8
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.
1. Qual é a finalidade da Fase de autenticação? authentication-phase-faq1
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. Como o aplicativo cliente pode saber se o usuário já está autenticado? authentication-phase-faq2
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
3. Como o aplicativo cliente pode obter as informações de metadados do usuário? authentication-phase-faq3
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)
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
4. O que é uma sessão de autenticação e por quanto tempo ela é válida? authentication-phase-faq4
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 limitado e curto especificado no momento do problema, 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
5. Qual é um código de autenticação e por quanto tempo ele é válido? authentication-phase-faq5
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 limitado e curto especificado no momento do início da sessão de autenticação, 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 permitir que o usuário conclua ou retome o processo de autenticação no mesmo dispositivo ou em um segundo, 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
6. 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? authentication-phase-faq6
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 ao endpoint de Sessões responsável por 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 a documentação Recuperar sessão de autenticação.
7. Qual é um perfil e por quanto tempo ele é válido? authentication-phase-faq7
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 ou encontrar o método usado para autenticação.
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, 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.
1. Qual é o objetivo da Fase de pré-autorização? preauthorization-phase-faq1
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? preauthorization-phase-faq2
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? preauthorization-phase-faq3
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. Por que a decisão de pré-autorização não tem um token de mídia? preauthorization-phase-faq4
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.
5. Qual é um recurso e quais formatos são compatíveis? preauthorization-phase-faq5
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 Identificando Recursos Protegidos.
6. Para quantos recursos o aplicativo cliente pode obter uma decisão de pré-autorização de cada vez? preauthorization-phase-faq6
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.
1. Qual é o objetivo da fase de autorização? authorization-phase-faq1
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? authorization-phase-faq2
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 ela requer que o verifique com o MVPD se 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? authorization-phase-faq3
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 podem ser recuperadas do endpoint da 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 ser necessário consultar o 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 que é um token de mídia e por quanto tempo ele é válido? authorization-phase-faq4
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 Integraçã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 a quantidade de tempo que ele deve ser usado pelo aplicativo cliente antes de solicitar a consulta do endpoint da Autorização de Decisões novamente.
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
5. Qual é um recurso e quais formatos são compatíveis? authorization-phase-faq5
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 Identificando Recursos Protegidos.
6. Para quantos recursos o aplicativo cliente pode obter uma decisão de autorização de cada vez? authorization-phase-faq6
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.
1. Qual é a finalidade da Fase de logout? logout-phase-faq1
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.
1. Como calcular o valor do cabeçalho de autorização? headers-faq1
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
Caso o aplicativo cliente esteja migrando da API REST V1 para a API REST V2, o aplicativo cliente pode continuar a usar o mesmo método para obter o token de acesso Bearer como antes.
2. Como calcular o valor do cabeçalho AP-Device-Identifier? headers-faq2
O 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 alguns exemplos de como calcular o valor para plataformas diferentes, 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.
Caso o aplicativo cliente esteja migrando da REST API V1 para a REST API V2, o aplicativo cliente pode continuar a usar o mesmo método para calcular o identificador do dispositivo como antes.
3. Como calcular o valor do cabeçalho X-Device-Info? headers-faq3
O 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.
A documentação do cabeçalho X-Device-Info fornece alguns exemplos de como calcular o valor para plataformas diferentes, 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.
Caso o aplicativo cliente esteja migrando da REST API V1 para a REST API V2, o aplicativo cliente pode continuar a usar o mesmo método para calcular as informações do dispositivo como antes.
Perguntas frequentes sobre migração migration-faqs
Prossiga com esta seção se estiver trabalhando em um aplicativo que precise migrar um aplicativo existente para a REST API V2.
1. Sou obrigado a implantar um novo aplicativo cliente migrado para a REST API V2 para todos os usuários de uma só vez? migration-faq1
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? migration-faq2
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 API REST V2 e a API REST 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? migration-faq3
Não.
A autenticação de usuário obtida em versões anteriores do aplicativo cliente que integram a REST API V1 ou SDK não será preservada.
Portanto, o usuário precisará autenticar novamente no novo aplicativo cliente migrado para a REST API V2.
4. O aplicativo cliente pode usar os aplicativos registrados existentes (instruções de software)? migration-faq4
O aplicativo cliente não pode reutilizar os aplicativos registrados existentes (instruções de software), portanto, deve gerar e baixar novos aplicativos registrados (instruções de software) dedicados ao consumo da REST API V2.
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 Canais do Painel do TVE ou o Guia do Usuário de Programadores do Painel do TVE.
No momento, você deverá solicitar que um representante da Autenticação da Adobe Pass habilite o uso da REST API V2 para seus novos aplicativos registrados (instruções de software), até que o Painel do TVE da Adobe Pass seja atualizado para permitir o autogerenciamento desta operação.
Para distinguir os aplicativos registrados (instruções de software) usados em aplicativos clientes que consomem a REST API V2, exigimos que você adicione um sufixo específico ao nome do aplicativo registrado, como "RESTV2".
5. O aplicativo cliente pode usar os esquemas personalizados existentes? migration-faq5
O aplicativo cliente pode reutilizar os esquemas personalizados existentes gerados pelo Painel TVE do Adobe Pass.
Para obter mais detalhes, consulte a documentação do Guia do Usuário de Canais do Painel do TVE ou o Guia do Usuário de Programadores do Painel do TVE.
6. Os códigos de erro aprimorados estão ativados por padrão na REST API V2? migration-faq6
Sim.
Os aplicativos clientes que integram a REST API V2 se beneficiam do recurso de códigos de erro aprimorado habilitado por padrão.
Para obter mais detalhes, consulte a documentação dos Códigos de erro aprimorados.
Migração da REST API V1 para REST API V2 migration-rest-api-v1-to-rest-api-v2-faqs
Prossiga com esta subseção se estiver trabalhando em um aplicativo que precise migrar da API REST V1 para a API REST V2.
1. Quais são as migrações de API de alto nível necessárias para a fase de registro? registration-phase-v1-to-v2-faq1
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:
1. Quais são as migrações de API de alto nível necessárias para a fase de configuração? configuration-phase-v1-to-v2-faq1
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:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | REST API V1 | REST API V2 | Observações |
| Recuperar lista de MVPDs com integração ativa | GET /api/v1/config/{serviceProvider} |
GET /api/v2/{serviceProvider}/configuration |
1. Quais são as migrações de API de alto nível necessárias para a Fase de autenticação? authentication-phase-v1-to-v2-faq1
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:
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 7-row-4 | |||
|---|---|---|---|
| Escopo | REST API V1 | REST API V2 | Observações |
| Recuperar código de registro (código de autenticação) | POST /reggie/v1/{serviceProvider}/regcode |
POST /api/v2/{serviceProvider}/sessions |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar código de registro (código de autenticação) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/sessions/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Retomar a autenticação (MVPD) na segunda tela (aplicativo) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Iniciar autenticação (MVPD) | GET /api/v1/authenticate |
GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar status de autenticação do usuário | GET /api/v1/checkauthn (primeira tela) GET /api/v1/checkauthn (segunda tela) |
Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar token de autenticação de usuário (perfil) | GET /api/v1/tokens/authn |
Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar informações de metadados do usuário | GET /api/v1/tokens/usermetadata |
Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
1. Quais são as migrações de API de alto nível necessárias para a fase de pré-autorização? preauthorization-phase-v1-to-v2-faq1
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:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | REST API V1 | REST API V2 | Observações |
| Recuperar recursos pré-autorizados (decisões de pré-autorização) | GET /api/v1/preauthorize (primeira tela) GET /api/v1/preauthorize (segunda tela) |
POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Para obter mais detalhes, consulte os seguintes documentos: |
1. Quais são as migrações de API de alto nível necessárias para a fase de autorização? authorization-phase-v1-to-v2-faq1
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:
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Escopo | REST API V1 | REST API V2 | Observações |
| Iniciar autorização (MVPD) | GET /api/v1/authorize |
POST /api/v2/{serviceProvider}/Decisions/authorize/{mvpd} |
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar token de autorização (decisão de autorização) | GET /api/v1/tokens/authz |
POST /api/v2/{serviceProvider}/Decisions/authorize/{mvpd} |
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar token de autorização curto (token de mídia) | GET /api/v1/tokens/media |
POST /api/v2/{serviceProvider}/Decisions/authorize/{mvpd} |
O aplicativo cliente pode usar a resposta desta API para várias finalidades de uma só vez:
Para obter mais detalhes, consulte os seguintes documentos: |
1. Quais são as migrações de API de alto nível necessárias para a Fase de logout? logout-phase-v1-to-v2-faq1
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:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | REST API V1 | REST API V2 | Observações |
| Iniciar logout | GET /api/v1/logout |
GET /api/v2/{serviceProvider}/logout |
Para obter mais detalhes, consulte os seguintes documentos: |
Migração do SDK para a REST API V2 migrate-sdk-to-rest-api-v2
Prossiga com esta subseção se estiver trabalhando em um aplicativo que precise migrar do SDK para a REST API V2.
1. Quais são as migrações de API de alto nível necessárias para a fase de registro? registration-phase-sdk-to-v2-faq1
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:
SDK do JavaScript do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Concluir o Registro de Cliente Dinâmico (DCR) | Fornecendo instrução de software ao construtor | POST /o/client/register GET /o/client/token |
Para obter mais detalhes, consulte os seguintes documentos: |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Concluir o Registro de Cliente Dinâmico (DCR) | Fornecendo instrução de software ao construtor | POST /o/client/register GET /o/client/token |
Para obter mais detalhes, consulte os seguintes documentos: |
SDK do Android do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Concluir o Registro de Cliente Dinâmico (DCR) | Fornecendo instrução de software ao construtor | POST /o/client/register GET /o/client/token |
Para obter mais detalhes, consulte os seguintes documentos: |
SDK FireOS do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Concluir o Registro de Cliente Dinâmico (DCR) | Fornecendo instrução de software ao construtor | POST /o/client/register GET /o/client/token |
Para obter mais detalhes, consulte os seguintes documentos: |
1. Quais são as migrações de API de alto nível necessárias para a fase de configuração? configuration-phase-sdk-to-v2-faq1
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:
SDK do JavaScript do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar lista de MVPDs com integração ativa | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar lista de MVPDs com integração ativa | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
SDK do Android do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar lista de MVPDs com integração ativa | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
SDK FireOS do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar lista de MVPDs com integração ativa | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
1. Quais são as migrações de API de alto nível necessárias para a Fase de autenticação? authentication-phase-sdk-to-v2-faq1
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:
SDK do JavaScript do AccessEnabler
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Iniciar autenticação (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar status de autenticação do usuário | AccessEnabler.checkAuthentication | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar informações de metadados do usuário | AccessEnabler.getMetadata | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
SDK do iOS do AccessEnabler
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Iniciar autenticação (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar status de autenticação do usuário | AccessEnabler.checkAuthentication | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar informações de metadados do usuário | AccessEnabler.getMetadata | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
AccessEnabler tvOS SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar código de registro (código de autenticação) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar código de registro (código de autenticação) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/sessions/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Retomar a autenticação (MVPD) na segunda tela (aplicativo) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Iniciar autenticação (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar status de autenticação do usuário | AccessEnabler.checkAuthentication | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar informações de metadados do usuário | AccessEnabler.getMetadata | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
SDK do Android do AccessEnabler
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Iniciar autenticação (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar status de autenticação do usuário | AccessEnabler.checkAuthentication | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar informações de metadados do usuário | AccessEnabler.getMetadata | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
SDK FireOS do AccessEnabler
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar código de registro (código de autenticação) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar código de registro (código de autenticação) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/sessions/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Retomar a autenticação (MVPD) na segunda tela (aplicativo) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Iniciar autenticação (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obter mais detalhes, consulte os seguintes documentos: |
| Verificar status de autenticação do usuário | AccessEnabler.checkAuthentication | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
| Recuperar informações de metadados do usuário | AccessEnabler.getMetadata | Use um dos seguintes: 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:
Para obter mais detalhes, consulte os seguintes documentos: |
1. Quais são as migrações de API de alto nível necessárias para a fase de pré-autorização? preauthorization-phase-sdk-to-v2-faq1
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:
SDK do JavaScript do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar recursos pré-autorizados (decisões de pré-autorização) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Para obter mais detalhes, consulte os seguintes documentos: |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar recursos pré-autorizados (decisões de pré-autorização) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Para obter mais detalhes, consulte os seguintes documentos: |
SDK do Android do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar recursos pré-autorizados (decisões de pré-autorização) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Para obter mais detalhes, consulte os seguintes documentos: |
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar recursos pré-autorizados (decisões de pré-autorização) | AccessEnabler.checkPreauthorizedResources | POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Para obter mais detalhes, consulte os seguintes documentos: |
1. Quais são as migrações de API de alto nível necessárias para a fase de autorização? authorization-phase-sdk-to-v2-faq1
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:
SDK do JavaScript do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar token de autorização curto (token de mídia) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/Decisions/authorize/{mvpd} |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar token de autorização curto (token de mídia) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/Decisions/authorize/{mvpd} |
SDK do Android do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar token de autorização curto (token de mídia) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/Decisions/authorize/{mvpd} |
SDK FireOS do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Recuperar token de autorização curto (token de mídia) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/Decisions/authorize/{mvpd} |
1. Quais são as migrações de API de alto nível necessárias para a Fase de logout? logout-phase-sdk-to-v2-faq1
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:
SDK do JavaScript do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Iniciar logout | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Iniciar logout | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
SDK do Android do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Iniciar logout | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
SDK FireOS do AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Escopo | SDK | REST API V2 | Observações |
| Iniciar logout | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |