Preguntas frecuentes sobre la API de REST V2 rest-api-v2-faqs
Este documento proporciona respuestas generales para las preguntas frecuentes acerca de la adopción de la API de REST V2 de autenticación de Adobe Pass.
Para obtener más información sobre la API de REST V2 en general, consulte la Información general sobre la API de REST V2.
Preguntas frecuentes generales general-faqs
Empiece con esta sección si está trabajando en una aplicación que necesita integrar la API de REST V2, ya sea una aplicación nueva o una existente que migre de API de REST V1 o SDK.
Para obtener más información sobre los detalles y pasos de la migración, consulte las secciones siguientes también.
1. ¿Cuál es el propósito de la fase de registro? registration-phase-faq1
El propósito de la fase de registro es registrar la aplicación cliente con la autenticación de Adobe Pass a través del proceso de Registro dinámico de clientes (DCR).
El proceso de registro dinámico de clientes (DCR) requiere que la aplicación cliente obtenga un par de credenciales de cliente y recupere un token de acceso como objetivo final de la fase de registro.
Para obtener más información, consulte la Información general sobre el registro de clientes dinámicos.
2. ¿Es obligatoria la fase de registro? registration-phase-faq2
La fase de registro es obligatoria, pero la aplicación cliente puede omitir esta fase si tiene un par en caché de credenciales de cliente y un token de acceso que siguen siendo válidos.
3. ¿Qué es una declaración de software y durante cuánto tiempo es válida? registration-phase-faq3
La instrucción de software es un término definido en la documentación de Glosario.
La declaración de software consiste en un token web JSON (JWT) que uno de los administradores de su organización puede generar y descargar desde el TVE Dashboard de Adobe Pass o un representante de autenticación de Adobe Pass que actúe en su nombre.
La declaración del software es válida durante un periodo de tiempo ilimitado, pero puede optar por pedirle a un representante de autenticación de Adobe Pass que la revoque en cualquier momento.
La aplicación cliente debe almacenar la instrucción de software y utilizarla cuando necesite recuperar las credenciales del cliente.
Para obtener más información, consulte la Información general sobre el registro de clientes dinámicos.
4. ¿Cómo generar y descargar una declaración de software? registration-phase-faq4
Esta operación puede completarla uno de los administradores de su organización o un representante de autenticación de Adobe Pass que actúe en su nombre a través del Panel de control de TVE de Adobe Pass.
Para obtener más información, consulte la Guía del usuario de canales del panel de TVE o la Guía del usuario para programadores del panel de TVE.
5. ¿Qué sucede si se revoca una declaración de software? registration-phase-faq5
Cuando se revoca la declaración del software, hay una consecuencia importante que considerar:
- Las aplicaciones cliente que usen la instrucción de software revocada ya no podrán pasar por los flujos de derechos, lo que significa que se bloqueará a los usuarios la reproducción de contenido.
6. ¿Qué son las credenciales del cliente y durante cuánto tiempo son válidas? registration-phase-faq6
Las credenciales del cliente son un término definido en la documentación de Glosario.
Las credenciales del cliente constan de un identificador de cliente y un par de secreto de cliente que se pueden recuperar del extremo de registro de cliente.
Las credenciales del cliente son válidas para un periodo de tiempo ilimitado.
La aplicación cliente debe almacenar indefinidamente las credenciales del cliente y utilizarlas cuando necesite recuperar un token de acceso.
Para obtener más información, consulte la documentación de Recuperar credenciales de cliente.
7. ¿Cómo administrar las credenciales del cliente? registration-phase-faq7
Recomendamos que la aplicación cliente administre un par único de credenciales de cliente para cada instancia de aplicación de usuario en caso de integraciones cliente a servidor y servidor a servidor con autenticación de Adobe Pass.
La aplicación cliente debe almacenar indefinidamente las credenciales del cliente y utilizarlas cuando necesite recuperar un token de acceso.
8. ¿Qué sucede si se pierden las credenciales del cliente en caché? registration-phase-faq8
Cuando se pierden las credenciales del cliente en caché, hay tres consecuencias importantes que hay que tener en cuenta:
- La aplicación cliente debe obtener un nuevo par de credenciales de cliente.
- La aplicación cliente debe obtener un nuevo token de acceso utilizando el nuevo par de credenciales de cliente.
- La aplicación cliente deberá solicitar al usuario que vuelva a autenticarse, ya que la aplicación cliente perderá el acceso a los perfiles autenticados obtenidos anteriormente.
9. ¿Qué es un token de acceso y durante cuánto tiempo es válido? registration-phase-faq9
El token de acceso es un término definido en la documentación de Glosario.
El token de acceso consiste en un token portador que se puede recuperar del extremo del token de cliente.
El token de acceso es válido durante un periodo de tiempo limitado y corto especificado en el momento de la emisión.
La aplicación cliente debe almacenar el token de acceso y utilizarlo hasta que caduque al segmentar la API de REST V2.
La aplicación cliente debe obtener un nuevo token de acceso antes de que caduque el actual para evitar solicitudes no autorizadas.
Para obtener más información, consulte la documentación de Recuperar token de acceso.
10. ¿Cómo puede la aplicación cliente actualizar un token de acceso? registration-phase-faq10
La aplicación cliente debe actualizar un token de acceso de la misma manera que recuperar un nuevo token de acceso, pero utilizando credenciales de cliente en caché.
La aplicación cliente no debe volver a registrarse para actualizar un token de acceso; en su lugar, debe utilizar las credenciales de cliente almacenadas; de lo contrario, los usuarios deberán volver a autenticarse.
Para obtener más información, consulte la documentación de Recuperar token de acceso.
1. ¿Cuál es el propósito de la fase de configuración? configuration-phase-faq1
El propósito de la fase de configuración es proporcionar a la aplicación cliente la lista de MVPD con las que está activamente integrada, junto con los detalles de configuración guardados por la autenticación de Adobe Pass para cada MVPD.
La fase de configuración actúa como un paso previo para la fase de autenticación cuando la aplicación cliente necesita pedir al usuario que seleccione su proveedor de TV.
2. ¿Es obligatoria la fase de configuración? configuration-phase-faq2
La fase de configuración no es obligatoria, la aplicación cliente puede omitir esta fase en los siguientes casos:
- El usuario ya se ha autenticado.
- Al usuario se le ofrece acceso temporal a través de la función básica o promocional TempPass.
- La autenticación del usuario ha caducado, pero la aplicación cliente ha almacenado en caché la MVPD seleccionada anteriormente como una elección motivada por la experiencia del usuario, y solo le pide que confirme que sigue siendo un suscriptor de esa MVPD.
3. ¿Qué es una configuración y durante cuánto tiempo es válida? configuration-phase-faq3
La configuración es un término definido en la documentación de Glosario.
La configuración consiste en una lista de MVPD que se pueden recuperar del punto de conexión de configuración.
La aplicación cliente puede utilizar la configuración para presentar un componente de interfaz de usuario denominado "Selector" cuando requiera que el usuario seleccione su MVPD.
La aplicación cliente debe actualizar la configuración antes de que el usuario pase por la fase de autenticación.
Para obtener más información, consulte la documentación de Recuperar configuración.
4. ¿Puede la aplicación cliente gestionar su propia lista de MVPD? configuration-phase-faq4
La aplicación cliente puede administrar su propia lista de MVPD, pero se recomienda utilizar la configuración proporcionada por la autenticación de Adobe Pass para garantizar que la lista esté actualizada y sea precisa.
La aplicación cliente recibiría un error de la API de REST de autenticación de Adobe Pass V2 si el usuario seleccionado MVPD no tiene una integración activa con el proveedor de servicios especificado.
5. ¿Puede la aplicación cliente filtrar la lista de MVPD? configuration-phase-faq5
La aplicación cliente puede filtrar la lista de MVPD proporcionadas en la respuesta de configuración implementando un mecanismo personalizado basado en la propia lógica empresarial y en requisitos como la ubicación del usuario o el historial del usuario de selecciones anteriores.
6. ¿Qué sucede si la integración con un MVPD está deshabilitada y marcada como inactiva? configuration-phase-faq6
Cuando la integración con una MVPD está deshabilitada y marcada como inactiva, la MVPD se elimina de la lista de MVPD que se proporciona en las respuestas de configuración adicionales y hay dos consecuencias importantes que se deben tener en cuenta:
- Los usuarios no autenticados de esa MVPD ya no podrán completar la fase de autenticación con esa MVPD.
- Los usuarios autenticados de esa MVPD ya no podrán completar las fases de preautorización, autorización o cierre de sesión con esa MVPD.
La aplicación cliente recibiría un error de la API de REST de autenticación de Adobe Pass V2 si el usuario seleccionado MVPD ya no tiene una integración activa con el proveedor de servicios especificado.
7. ¿Qué sucede si la integración con un MVPD se vuelve a habilitar y se marca como activa? configuration-phase-faq7
Cuando la integración con una MVPD se vuelve a habilitar y se marca como activa, la MVPD se vuelve a incluir en la lista de MVPD que se proporciona en las respuestas de configuración adicionales y hay dos consecuencias importantes que se deben tener en cuenta:
- Los usuarios no autenticados de esa MVPD podrán completar de nuevo la fase de autenticación usando esa MVPD.
- Los usuarios autenticados de esa MVPD podrán completar de nuevo las fases de preautorización, autorización o cierre de sesión utilizando esa MVPD.
8. ¿Cómo habilitar o deshabilitar la integración con una MVPD? configuration-phase-faq8
Esta operación puede completarla uno de los administradores de su organización o un representante de autenticación de Adobe Pass que actúe en su nombre a través del Panel de control de TVE de Adobe Pass.
Para obtener más información, consulte la Guía del usuario sobre integraciones de paneles de TVE.
1. ¿Cuál es el propósito de la fase de autenticación? authentication-phase-faq1
El propósito de la fase de autenticación es proporcionar a la aplicación cliente la capacidad de verificar la identidad del usuario y obtener información de metadatos del usuario.
La fase de autenticación actúa como un paso previo para la fase de preautorización o la fase de autorización cuando la aplicación cliente necesita reproducir contenido.
2. ¿Cómo puede saber la aplicación cliente si el usuario ya está autenticado? authentication-phase-faq2
La aplicación cliente puede consultar uno de los siguientes extremos capaces de comprobar si un usuario ya está autenticado y devolver información de perfil:
- API de extremo de perfiles
- Extremo de perfiles para API de MVPD específica
- Extremo de perfiles para API de código específica (autenticación)
Para obtener más información, consulte los siguientes documentos:
- Flujo de perfiles básicos realizado dentro de la aplicación principal
- Flujo de perfiles básicos realizado en la aplicación secundaria
3. ¿Cómo puede la aplicación cliente obtener la información de metadatos del usuario? authentication-phase-faq3
La aplicación cliente puede consultar uno de los siguientes extremos capaces de devolver información de metadatos de usuario como parte de la información de perfil:
- API de extremo de perfiles
- Extremo de perfiles para API de MVPD específica
- Extremo de perfiles para API de código específica (autenticación)
Para obtener más información, consulte los siguientes documentos:
- Flujo de perfiles básicos realizado dentro de la aplicación principal
- Flujo de perfiles básicos realizado en la aplicación secundaria
4. ¿Qué es una sesión de autenticación y durante cuánto tiempo es válida? authentication-phase-faq4
La sesión de autenticación es un término definido en la documentación de Glosario.
La sesión de autenticación almacena información sobre el proceso de autenticación iniciado que se puede recuperar del punto final de sesiones.
La sesión de autenticación es válida durante un periodo de tiempo limitado y corto especificado en el momento del problema, lo que indica la cantidad de tiempo que el usuario debe completar el proceso de autenticación antes de requerir el reinicio del flujo.
La aplicación cliente puede utilizar la respuesta de sesión de autenticación para saber cómo continuar con el proceso de autenticación. Tenga en cuenta que hay casos en los que no se requiere la autenticación del usuario, como proporcionar acceso temporal, acceso degradado o cuando el usuario ya está autenticado.
Para obtener más información, consulte los siguientes documentos:
- Crear API de sesión de autenticación
- Reanudar API de sesión de autenticación
- Flujo de autenticación básico realizado en la aplicación principal
- Flujo de autenticación básico realizado en la aplicación secundaria
5. ¿Qué es un código de autenticación y durante cuánto tiempo es válido? authentication-phase-faq5
El código de autenticación es un término definido en la documentación de Glosario.
El código de autenticación almacena un valor único generado cuando un usuario inicia el proceso de autenticación e identifica de forma exclusiva la sesión de autenticación de un usuario hasta que el proceso se completa o hasta que caduca la sesión de autenticación.
El código de autenticación es válido durante un periodo de tiempo limitado y corto especificado en el momento de iniciar la sesión de autenticación, lo que indica la cantidad de tiempo que el usuario debe completar el proceso de autenticación antes de requerir el reinicio del flujo.
La aplicación cliente puede utilizar el código de autenticación para permitir al usuario completar o reanudar el proceso de autenticación en el mismo dispositivo o en un segundo dispositivo, teniendo en cuenta que la sesión de autenticación no caducó.
Para obtener más información, consulte los siguientes documentos:
- Crear API de sesión de autenticación
- Reanudar API de sesión de autenticación
- Flujo de autenticación básico realizado en la aplicación principal
- Flujo de autenticación básico realizado en la aplicación secundaria
6. ¿Cómo puede saber la aplicación cliente si el usuario ha escrito un código de autenticación válido y que la sesión de autenticación aún no ha caducado? authentication-phase-faq6
La aplicación cliente puede validar el código de autenticación escrito por el usuario en una aplicación secundaria (pantalla) enviando una solicitud al extremo de sesiones responsable de recuperar la información de sesión de autenticación asociada al código de autenticación.
La aplicación cliente recibiría un error si el código de autenticación proporcionado estuviera escrito incorrectamente o en caso de que la sesión de autenticación expirara.
Para obtener más información, consulte la documentación de Recuperar sesión de autenticación.
7. ¿Qué es un perfil y durante cuánto tiempo es válido? authentication-phase-faq7
El perfil es un término definido en la documentación de Glosario.
El perfil almacena información sobre la validez de autenticación del usuario, información de metadatos y mucho más que se puede recuperar del extremo de perfiles.
La aplicación cliente puede utilizar el perfil para conocer el estado de autenticación del usuario, acceder a la información de metadatos del usuario o encontrar el método utilizado para la autenticación.
Para obtener más información, consulte los siguientes documentos:
- API de extremo de perfiles
- Extremo de perfiles para API de MVPD específica
- Extremo de perfiles para API de código específica (autenticación)
- Flujo de perfiles básicos realizado dentro de la aplicación principal
- Flujo de perfiles básicos realizado en la aplicación secundaria
El perfil es válido durante un periodo de tiempo limitado especificado cuando se consulta, lo que indica la cantidad de tiempo que el usuario tiene una autenticación válida antes de requerir volver a pasar por la fase de autenticación.
Este periodo de tiempo limitado conocido como autenticación (authN) TTL lo puede ver y cambiar uno de los administradores de su organización o un representante de autenticación de Adobe Pass que actúe en su nombre a través del panel de control de TVE de Adobe Pass.
Para obtener más información, consulte la Guía del usuario sobre integraciones de paneles de TVE.
1. ¿Cuál es el propósito de la fase de preautorización? preauthorization-phase-faq1
El propósito de la fase de preautorización es proporcionar a la aplicación cliente la capacidad de presentar un subconjunto de recursos de su catálogo al que el usuario tendría derecho de acceso.
La fase de preautorización puede mejorar la experiencia del usuario cuando abre la aplicación cliente por primera vez o navega a una nueva sección.
2. ¿Es obligatoria la fase de preautorización? preauthorization-phase-faq2
La fase de preautorización no es obligatoria, la aplicación cliente puede omitir esta fase si desea presentar un catálogo de recursos sin filtrarlos primero según el derecho del usuario.
3. ¿Qué es una decisión de preautorización? preauthorization-phase-faq3
La preautorización es un término definido en la documentación de Glosario, mientras que el término de decisión también se puede encontrar en el Glosario.
La decisión de preautorización almacena información sobre el resultado de la consulta del proceso de preautorización de MVPD que se puede recuperar del extremo de preautorización de Decisions.
La aplicación cliente puede utilizar las decisiones de preautorización para presentar un subconjunto de recursos al que el proveedor de TV (informativo) permitiría acceder.
Para obtener más información, consulte los siguientes documentos:
- Recuperar API de decisiones de preautorización
- Flujo de preautorización básico realizado en la aplicación principal
4. ¿Por qué en la decisión de preautorización falta un token de medios? preauthorization-phase-faq4
A la decisión de preautorización le falta un token de medios porque la fase de preautorización no debe utilizarse para reproducir recursos, ya que ese es el propósito de la fase de autorización.
5. ¿Qué es un recurso y qué formatos se admiten? preauthorization-phase-faq5
El medio es un término definido en la documentación de Glosario.
El recurso es un identificador único acordado con las MVPD y está asociado a un contenido que la aplicación cliente podría transmitir.
El identificador único del recurso puede tener dos formatos:
- Un formato de cadena simple, como un identificador único de un canal (marca).
- Un formato RSS (RSS) multimedia que contiene información adicional, como el título, las clasificaciones y los metadatos de control parental.
Para obtener más información, consulte la Documentación sobre la identificación de recursos protegidos.
6. ¿Para cuántos recursos puede la aplicación cliente obtener una decisión de preautorización a la vez? preauthorization-phase-faq6
La aplicación cliente puede obtener una decisión de preautorización para un número limitado de recursos en una sola solicitud de API, normalmente hasta 5, debido a condiciones impuestas por MVPD.
Este número máximo de recursos se puede ver y cambiar después de ponerse de acuerdo con las MVPD a través del TVE Dashboard de Adobe Pass por uno de los administradores de la organización o por un representante de autenticación de Adobe Pass que actúe en su nombre.
Para obtener más información, consulte la Guía del usuario sobre integraciones de paneles de TVE.
1. ¿Cuál es el propósito de la fase de autorización? authorization-phase-faq1
El propósito de la fase de autorización es proporcionar a la aplicación cliente la capacidad de reproducir los recursos que el usuario solicita después de validar sus derechos con la MVPD.
2. ¿Es obligatoria la fase de autorización? authorization-phase-faq2
La fase de autorización es obligatoria, la aplicación cliente no puede omitir esta fase si desea reproducir los recursos que solicita el usuario, ya que requiere verificar con la MVPD que el usuario tiene derecho antes de liberar el flujo.
3. ¿Qué es una decisión de autorización y durante cuánto tiempo es válida? authorization-phase-faq3
La autorización es un término definido en la documentación de Glosario, mientras que el término de decisión también se puede encontrar en el Glosario.
La decisión de autorización almacena información sobre el resultado de la consulta del proceso de autorización de MVPD que se puede recuperar del punto final de autorización de decisiones.
La aplicación cliente puede utilizar la decisión de autorización que contiene un token de medios para reproducir el flujo de recursos en caso de que la decisión del proveedor de TV (autoritativa) permita al usuario acceder a él.
Para obtener más información, consulte los siguientes documentos:
- Recuperar API de decisiones de autorización
- Flujo de autorización básico realizado en la aplicación principal
La decisión de autorización es válida durante un periodo de tiempo limitado y corto especificado en el momento de la emisión, lo que indica la cantidad de tiempo que la autenticación de Adobe Pass la almacenará en caché antes de requerir volver a consultar la MVPD.
Este periodo de tiempo limitado conocido como autorización (authZ) TTL lo puede ver y modificar uno de los administradores de su organización o un representante de autenticación de Adobe Pass que actúe en su nombre a través del panel de control de TVE de Adobe Pass.
Para obtener más información, consulte la Guía del usuario sobre integraciones de paneles de TVE.
4. ¿Qué es un token de medios y durante cuánto tiempo es válido? authorization-phase-faq4
El token multimedia es un término definido en la documentación de Glosario.
El token de medios consiste en una cadena firmada enviada en texto no cifrado que se puede recuperar del extremo de autorización de decisiones.
Para obtener más información, consulte la documentación de Integración del verificador de tokens de medios.
El token de medios es válido durante un periodo de tiempo limitado y corto especificado en el momento del problema, lo que indica la cantidad de tiempo que debe utilizar la aplicación cliente antes de requerir volver a consultar el extremo de autorización de decisiones.
La aplicación cliente puede utilizar el token de medios para reproducir un flujo de recursos en caso de que la decisión del proveedor de TV (autoritativa) permita al usuario acceder a él.
Para obtener más información, consulte los siguientes documentos:
- Recuperar API de decisiones de autorización
- Flujo de autorización básico realizado en la aplicación principal
5. ¿Qué es un recurso y qué formatos se admiten? authorization-phase-faq5
El medio es un término definido en la documentación de Glosario.
El recurso es un identificador único acordado con las MVPD y está asociado a un contenido que la aplicación cliente podría transmitir.
El identificador único del recurso puede tener dos formatos:
- Un formato de cadena simple, como un identificador único de un canal (marca).
- Un formato RSS (RSS) multimedia que contiene información adicional, como el título, las clasificaciones y los metadatos de control parental.
Para obtener más información, consulte la Documentación sobre la identificación de recursos protegidos.
6. ¿Para cuántos recursos puede la aplicación cliente obtener una decisión de autorización a la vez? authorization-phase-faq6
La aplicación cliente puede obtener una decisión de autorización para un número limitado de recursos en una sola solicitud de API, normalmente hasta 1, debido a condiciones impuestas por MVPD.
1. ¿Cuál es el propósito de la fase de cierre de sesión? logout-phase-faq1
El propósito de la fase de cierre de sesión es proporcionar a la aplicación cliente la capacidad de finalizar el perfil autenticado del usuario dentro de la autenticación de Adobe Pass si el usuario lo solicita.
1. ¿Cómo se calcula el valor del encabezado Autorización? headers-faq1
El encabezado de la solicitud Authorization contiene el token de acceso Bearer requerido por la aplicación cliente para acceder a las API protegidas por Adobe Pass.
El valor del encabezado Autorización debe obtenerse de la Autenticación de Adobe Pass durante la Fase de registro.
Para obtener más información, consulte los siguientes documentos:
- Información general sobre el registro dinámico de clientes
- Recuperar API de credenciales de cliente
- Recuperar API de token de acceso
- Flujo de registro de cliente dinámico
Si la aplicación cliente está migrando de la API de REST V1 a la API de REST V2, puede seguir utilizando el mismo método para obtener el token de acceso Bearer que antes.
2. ¿Cómo calcular el valor del encabezado AP-Device-Identifier? headers-faq2
El encabezado de la solicitud AP-Device-Identifier contiene el identificador del dispositivo de flujo continuo tal como lo creó la aplicación cliente.
La documentación del encabezado AP-Device-Identifier proporciona algunos ejemplos de cómo calcular el valor para distintas plataformas, pero la aplicación cliente puede elegir utilizar un método diferente según su propia lógica y requisitos empresariales.
En caso de que la aplicación cliente esté migrando de la API de REST V1 a la API de REST V2, la aplicación cliente puede seguir utilizando el mismo método para calcular el identificador de dispositivo que antes.
3. ¿Cómo calcular el valor del encabezado X-Device-Info? headers-faq3
El encabezado de la solicitud X-Device-Info contiene la información del cliente (dispositivo, conexión y aplicación) relacionada con el dispositivo de flujo continuo real.
La documentación del encabezado X-Device-Info proporciona algunos ejemplos de cómo calcular el valor para distintas plataformas, pero la aplicación cliente puede elegir utilizar un método diferente según su propia lógica y requisitos empresariales.
En caso de que la aplicación cliente esté migrando de la API de REST V1 a la API de REST V2, la aplicación cliente puede seguir utilizando el mismo método para calcular la información del dispositivo que antes.
Preguntas frecuentes sobre migración migration-faqs
Continúe con esta sección si está trabajando en una aplicación que necesita migrar una aplicación existente a la API de REST V2.
1. ¿Debo implementar una nueva aplicación cliente migrada a la API de REST V2 para todos los usuarios a la vez? migration-faq1
No.
La aplicación cliente no es necesaria para implementar una nueva versión que integre la API de REST V2 para todos los usuarios simultáneamente.
La autenticación de Adobe Pass seguirá siendo compatible con versiones de aplicaciones cliente anteriores que integren la API de REST V1 o el SDK hasta finales de 2025.
2. ¿Se me requiere para implementar una nueva aplicación cliente migrada a la API de REST V2 en todas las API y flujos a la vez? migration-faq2
Sí.
La aplicación cliente debe implementar una nueva versión que integre la API de REST V2 en todas las API de autenticación de Adobe Pass y flujos simultáneamente.
En caso del flujo de "autenticación de segunda pantalla", la aplicación cliente debe implementar una nueva versión que integre la API de REST V2 para las aplicaciones primary y secondary simultáneamente.
La autenticación de Adobe Pass no admitirá implementaciones "híbridas" que integren la API de REST V2 y la API de REST V1/SDK entre API y flujos.
3. ¿Se conservará la autenticación del usuario al actualizar a una nueva aplicación cliente migrada a la API de REST V2? migration-faq3
No.
No se conservará la autenticación de usuario obtenida en versiones anteriores de aplicaciones cliente que integran la API de REST V1 o el SDK.
Por lo tanto, se solicitará al usuario que vuelva a autenticarse dentro de la nueva aplicación cliente migrada a la API de REST V2.
4. ¿Puede la aplicación cliente utilizar las aplicaciones registradas existentes (declaraciones de software)? migration-faq4
La aplicación cliente no puede reutilizar las aplicaciones registradas existentes (declaraciones de software), por lo que debe generar y descargar una nueva aplicación registrada (declaraciones de software) dedicada a consumir la API de REST V2.
Esta operación puede completarla uno de los administradores de su organización o un representante de autenticación de Adobe Pass que actúe en su nombre a través del Panel de control de TVE de Adobe Pass.
Para obtener más información, consulte la Guía del usuario de canales del panel de TVE o la Guía del usuario para programadores del panel de TVE.
Por el momento, se le pedirá a un representante de autenticación de Adobe Pass que habilite el uso de la API de REST V2 para sus nuevas aplicaciones registradas (declaraciones de software), hasta que el TVE Dashboard de Adobe Pass se actualice para permitir la administración automática de esta operación.
Para distinguir las aplicaciones registradas (declaraciones de software) utilizadas en las aplicaciones cliente que consumen REST API V2, es necesario agregar un sufijo específico al nombre de la aplicación registrada, como "RESTV2".
5. ¿Puede la aplicación cliente utilizar los esquemas personalizados existentes? migration-faq5
La aplicación cliente puede reutilizar los esquemas personalizados existentes generados a través del Tablero de TVE de Adobe Pass.
Para obtener más información, consulte la Guía del usuario de canales del panel de TVE o la Guía del usuario para programadores del panel de TVE.
6. ¿Los códigos de error mejorados están habilitados de forma predeterminada en la API de REST V2? migration-faq6
Sí.
Las aplicaciones cliente que integran la API REST V2 se benefician de la función de códigos de error mejorados activada de forma predeterminada.
Para obtener más información, consulte la documentación de Códigos de error mejorados.
Migración de la API de REST V1 a la API de REST V2 migration-rest-api-v1-to-rest-api-v2-faqs
Continúe con esta subsección si está trabajando en una aplicación que necesita migrar de la API de REST V1 a la API de REST V2.
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de registro? registration-phase-v1-to-v2-faq1
En la migración de la API de REST V1 a la API de REST V2 no hay cambios de alto nivel con respecto a la fase de registro.
La aplicación cliente puede seguir utilizando el mismo flujo para registrarse con la autenticación de Adobe Pass a través del proceso de registro dinámico de cliente (DCR) y obtener un token de acceso.
Para obtener más información, consulte los siguientes documentos:
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de configuración? configuration-phase-v1-to-v2-faq1
En la migración de la API de REST V1 a la API de REST V2 hay cambios de alto nivel que se presentan en la siguiente tabla:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | API DE REST V1 | API DE REST V2 | Observaciones |
| Recuperar lista de MVPD con integración activa | GET /api/v1/config/{serviceProvider} |
GET /api/v2/{serviceProvider}/configuration |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de autenticación? authentication-phase-v1-to-v2-faq1
En la migración de la API de REST V1 a la API de REST V2 hay cambios de alto nivel que se presentan en la siguiente tabla:
| 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 | |||
|---|---|---|---|
| Ámbito | API DE REST V1 | API DE REST V2 | Observaciones |
| Recuperar código de registro (código de autenticación) | POST /reggie/v1/{serviceProvider}/regcode |
POST /api/v2/{serviceProvider}/session |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar código de registro (código de autenticación) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/session/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Reanudar la autenticación (MVPD) en la segunda pantalla (aplicación) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/session/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Iniciar autenticación (MVPD) | GET /api/v1/authenticate |
GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar estado de autenticación del usuario | GET /api/v1/checkauthn (primera pantalla) GET /api/v1/checkauthn (segunda pantalla) |
Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar token de autenticación de usuario (perfil) | GET /api/v1/tokens/authn |
Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar información de metadatos de usuario | GET /api/v1/tokens/usermetadata |
Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de preautorización? preauthorization-phase-v1-to-v2-faq1
En la migración de la API de REST V1 a la API de REST V2 hay cambios de alto nivel que se presentan en la siguiente tabla:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | API DE REST V1 | API DE REST V2 | Observaciones |
| Recuperación de recursos autorizados previamente (decisiones de preautorización) | GET /api/v1/preauthorize (primera pantalla) GET /api/v1/preauthorize (segunda pantalla) |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Para obtener más información, consulte los siguientes documentos: |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de autorización? authorization-phase-v1-to-v2-faq1
En la migración de la API de REST V1 a la API de REST V2 hay cambios de alto nivel que se presentan en la siguiente tabla:
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Ámbito | API DE REST V1 | API DE REST V2 | Observaciones |
| Iniciar autorización de (MVPD) | GET /api/v1/authorize |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar token de autorización (decisión de autorización) | GET /api/v1/tokens/authz |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar token de autorización corto (token de medios) | GET /api/v1/tokens/media |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de cierre de sesión? logout-phase-v1-to-v2-faq1
En la migración de la API de REST V1 a la API de REST V2 hay cambios de alto nivel que se presentan en la siguiente tabla:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | API DE REST V1 | API DE REST V2 | Observaciones |
| Iniciar cierre de sesión | GET /api/v1/logout |
GET /api/v2/{serviceProvider}/logout |
Para obtener más información, consulte los siguientes documentos: |
Migración del SDK a la API de REST V2 migrate-sdk-to-rest-api-v2
Continúe con esta subsección si está trabajando en una aplicación que necesita migrar del SDK a la API de REST V2.
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de registro? registration-phase-sdk-to-v2-faq1
En la migración de los SDK a la API de REST V2 hay cambios de alto nivel que hay que tener en cuenta y que se presentan en las siguientes tablas:
SDK de JavaScript de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Registro dinámico de clientes (DCR) completo | Proporcionar instrucción de software al constructor | POST /o/client/register GET /o/client/token |
Para obtener más información, consulte los siguientes documentos: |
SDK de AccessEnabler para iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Registro dinámico de clientes (DCR) completo | Proporcionar instrucción de software al constructor | POST /o/client/register GET /o/client/token |
Para obtener más información, consulte los siguientes documentos: |
SDK de Android de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Registro dinámico de clientes (DCR) completo | Proporcionar instrucción de software al constructor | POST /o/client/register GET /o/client/token |
Para obtener más información, consulte los siguientes documentos: |
SDK de AccessEnabler FireOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Registro dinámico de clientes (DCR) completo | Proporcionar instrucción de software al constructor | POST /o/client/register GET /o/client/token |
Para obtener más información, consulte los siguientes documentos: |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de configuración? configuration-phase-sdk-to-v2-faq1
En la migración de los SDK a la API de REST V2 hay cambios de alto nivel que hay que tener en cuenta y que se presentan en las siguientes tablas:
SDK de JavaScript de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar lista de MVPD con integración activa | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
SDK de AccessEnabler para iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar lista de MVPD con integración activa | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
SDK de Android de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar lista de MVPD con integración activa | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
SDK de AccessEnabler FireOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar lista de MVPD con integración activa | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de autenticación? authentication-phase-sdk-to-v2-faq1
En la migración de los SDK a la API de REST V2 hay cambios de alto nivel que hay que tener en cuenta y que se presentan en las siguientes tablas:
SDK de JavaScript de AccessEnabler
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Iniciar autenticación (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar estado de autenticación del usuario | AccessEnabler.checkAuthentication | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar información de metadatos de usuario | AccessEnabler.getMetadata | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
SDK de iOS de AccessEnabler
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Iniciar autenticación (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar estado de autenticación del usuario | AccessEnabler.checkAuthentication | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar información de metadatos de usuario | AccessEnabler.getMetadata | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
SDK de tvOS de AccessEnabler
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar código de registro (código de autenticación) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar código de registro (código de autenticación) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/session/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Reanudar la autenticación (MVPD) en la segunda pantalla (aplicación) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/session/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Iniciar autenticación (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar estado de autenticación del usuario | AccessEnabler.checkAuthentication | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar información de metadatos de usuario | AccessEnabler.getMetadata | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
SDK de Android de AccessEnabler
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Iniciar autenticación (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar estado de autenticación del usuario | AccessEnabler.checkAuthentication | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar información de metadatos de usuario | AccessEnabler.getMetadata | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
SDK de AccessEnabler FireOS
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar código de registro (código de autenticación) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar código de registro (código de autenticación) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/session/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Reanudar la autenticación (MVPD) en la segunda pantalla (aplicación) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/session/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Iniciar autenticación (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Para obtener más información, consulte los siguientes documentos: |
| Comprobar estado de autenticación del usuario | AccessEnabler.checkAuthentication | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
| Recuperar información de metadatos de usuario | AccessEnabler.getMetadata | Utilice uno de los siguientes: GET /api/v2/{serviceProvider}/perfiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
La aplicación cliente puede utilizar la respuesta de estas API para varios fines a la vez:
Para obtener más información, consulte los siguientes documentos: |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de preautorización? preauthorization-phase-sdk-to-v2-faq1
En la migración de los SDK a la API de REST V2 hay cambios de alto nivel que hay que tener en cuenta y que se presentan en las siguientes tablas:
SDK de JavaScript de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperación de recursos autorizados previamente (decisiones de preautorización) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Para obtener más información, consulte los siguientes documentos: |
SDK de AccessEnabler para iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperación de recursos autorizados previamente (decisiones de preautorización) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Para obtener más información, consulte los siguientes documentos: |
SDK de Android de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperación de recursos autorizados previamente (decisiones de preautorización) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Para obtener más información, consulte los siguientes documentos: |
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperación de recursos autorizados previamente (decisiones de preautorización) | AccessEnabler.checkPreauthorizedResources | POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Para obtener más información, consulte los siguientes documentos: |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de autorización? authorization-phase-sdk-to-v2-faq1
En la migración de los SDK a la API de REST V2 hay cambios de alto nivel que hay que tener en cuenta y que se presentan en las siguientes tablas:
SDK de JavaScript de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar token de autorización corto (token de medios) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
SDK de AccessEnabler para iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar token de autorización corto (token de medios) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
SDK de Android de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar token de autorización corto (token de medios) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
SDK de AccessEnabler FireOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Recuperar token de autorización corto (token de medios) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de cierre de sesión? logout-phase-sdk-to-v2-faq1
En la migración de los SDK a la API de REST V2 hay cambios de alto nivel que hay que tener en cuenta y que se presentan en las siguientes tablas:
SDK de JavaScript de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Iniciar cierre de sesión | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
SDK de AccessEnabler para iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Iniciar cierre de sesión | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
SDK de Android de AccessEnabler
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Iniciar cierre de sesión | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
SDK de AccessEnabler FireOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ámbito | SDK | API DE REST V2 | Observaciones |
| Iniciar cierre de sesión | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |