Preguntas frecuentes sobre la API de REST V2
- Temas:
- Autenticación
IMPORTANTEste 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
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.
Preguntas frecuentes sobre la fase de registro
Preguntas frecuentes sobre la fase de registro
Preguntas frecuentes sobre la fase de configuración
Preguntas frecuentes sobre la fase de configuración
1. ¿Cuál es el propósito de la fase de configuración?
El propósito de la fase de configuración es proporcionar a la aplicación cliente la lista de MVPD con las que está integrada activamente junto con los detalles de configuración (por ejemplo, id, displayName, logoUrl, etc.) 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?
La fase de configuración no es obligatoria, la aplicación cliente debe recuperar la configuración solo cuando el usuario necesite seleccionar su MVPD para autenticarse o volver a autenticarse.
La aplicación cliente puede omitir esta fase en los siguientes casos:
- El usuario ya se ha autenticado.
- Se ofrece acceso temporal al usuario a través de la característica TempPass básica o promocional.
- La autenticación del usuario ha caducado, pero la aplicación cliente ha almacenado en caché el MVPD seleccionado anteriormente como una opción motivada por la experiencia del usuario, y solo le pide que confirme que sigue siendo un suscriptor de ese MVPD.
3. ¿Qué es una configuración y durante cuánto tiempo es válida?
La configuración es un término definido en la documentación de Glosario.
La configuración contiene una lista de MVPD definidas por los siguientes atributos id, displayName, logoUrl, etc., que se pueden recuperar del extremo Configuration.
La aplicación cliente solo debe recuperar la configuración cuando el usuario necesite seleccionar su MVPD para autenticarse o volver a autenticarse.
La aplicación cliente puede utilizar la respuesta de configuración para presentar un selector de IU con opciones de MVPD disponibles cada vez que el usuario necesite seleccionar su proveedor de TV.
La aplicación cliente debe almacenar el identificador MVPD seleccionado del usuario, tal como lo especifica el atributo de nivel de configuración id de MVPD, para continuar con las fases Autenticación, Preautorización, Autorización o Cierre de sesión.
Para obtener más información, consulte la documentación de Recuperar configuración.
4. ¿Debe la aplicación cliente almacenar en caché la información de respuesta de configuración en un almacenamiento persistente?
La aplicación cliente solo debe recuperar la configuración cuando el usuario necesite seleccionar su MVPD para autenticarse o volver a autenticarse.
La aplicación cliente debe almacenar en caché la información de respuesta de configuración en un almacenamiento de memoria para evitar solicitudes innecesarias y mejorar la experiencia del usuario cuando:
- El usuario ya se ha autenticado.
- Se ofrece acceso temporal al usuario a través de la característica TempPass básica o promocional.
- La autenticación del usuario ha caducado, pero la aplicación cliente ha almacenado en caché el MVPD seleccionado anteriormente como una opción motivada por la experiencia del usuario, y solo le pide que confirme que sigue siendo un suscriptor de ese MVPD.
5. ¿Puede la aplicación cliente gestionar su propia lista de MVPD?
La aplicación cliente puede administrar su propia lista de MVPD, pero necesitaría mantener los identificadores de MVPD sincronizados con la autenticación de Adobe Pass. Por lo tanto, 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á un error de la API de REST de autenticación de Adobe Pass V2 si el identificador de MVPD proporcionado no es válido o si no tiene una integración activa con el proveedor de servicios especificado.
6. ¿Puede la aplicación cliente filtrar la lista de MVPD?
La aplicación cliente puede filtrar la lista de MVPD proporcionadas en la respuesta de configuración implementando un mecanismo personalizado basado en su propia lógica empresarial y en requisitos como la ubicación del usuario o el historial del usuario de selecciones anteriores.
La aplicación cliente puede filtrar la lista de TempPass MVPD o las MVPD que tienen su integración aún en desarrollo o prueba.
7. ¿Qué sucede si la integración con un MVPD está deshabilitada y marcada como inactiva?
Cuando la integración con un MVPD está deshabilitada y marcada como inactiva, MVPD se elimina de la lista de MVPD proporcionadas en respuestas de configuración adicionales y hay dos consecuencias importantes que considerar:
- Los usuarios no autenticados de ese MVPD ya no podrán completar la fase de autenticación con ese MVPD.
- Los usuarios autenticados de ese MVPD ya no podrán completar las fases de preautorización, autorización o cierre de sesión con ese 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.
8. ¿Qué sucede si la integración con una MVPD se vuelve a habilitar y se marca como activa?
Cuando la integración con un MVPD se vuelve a habilitar y se marca como activa, MVPD se vuelve a incluir en la lista de MVPD proporcionadas en respuestas de configuración adicionales y hay dos consecuencias importantes que se deben tener en cuenta:
- Los usuarios no autenticados de ese MVPD podrán completar de nuevo la fase de autenticación mediante ese MVPD.
- Los usuarios autenticados de ese MVPD podrán completar de nuevo las fases de preautorización, autorización o cierre de sesión con ese MVPD.
9. ¿Cómo se habilita o deshabilita la integración con un MVPD?
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.
Preguntas frecuentes sobre la fase de autenticación
Preguntas frecuentes sobre la fase de autenticación
1. ¿Cuál es el propósito de la fase de autenticación?
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. ¿Qué es una sesión de autenticación y durante cuánto tiempo es válida?
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 período de tiempo limitado y corto especificado en el momento de la emisión por la marca de tiempo notAfter, 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
3. ¿Qué es un código de autenticación y durante cuánto tiempo es válido?
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 para un período de tiempo limitado y corto especificado en el momento de iniciar la sesión de autenticación por la marca de tiempo notAfter, lo que indica la cantidad de tiempo que el usuario debe completar el proceso de autenticación antes de requerir reiniciar el flujo.
La aplicación cliente puede utilizar el código de autenticación para comprobar si el usuario ha completado correctamente la autenticación y recuperar la información de perfil del usuario, normalmente a través de un mecanismo de sondeo.
La aplicación cliente también 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 uno segundo (pantalla), 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
4. ¿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?
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 a uno de los extremos de sesiones responsables de reanudar la sesión de autenticación o recuperar la información de sesión de autenticación asociada con el código de autenticación.
La aplicación cliente recibiría un error si el código de autenticación proporcionado no se escribiera correctamente o en caso de que la sesión de autenticación expirara.
Para obtener más información, consulte los documentos Reanudar sesión de autenticación y Recuperar sesión de autenticación.
5. ¿Cómo puede saber la aplicación cliente si el usuario ya está autenticado?
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
6. ¿Qué es un perfil y durante cuánto tiempo es válido?
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, encontrar el método utilizado para autenticarse o la entidad utilizada para proporcionar identidad.
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 para un período de tiempo limitado especificado cuando se consulta mediante la marca de tiempo notAfter, lo que indica la cantidad de tiempo que el usuario tiene una autenticación válida antes de requerir pasar de nuevo 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.
7. ¿Debe la aplicación cliente almacenar en caché la información de perfil del usuario en un almacenamiento persistente?
La aplicación cliente debe almacenar en caché la información de perfil del usuario en un almacenamiento persistente para evitar solicitudes innecesarias y mejorar la experiencia del usuario teniendo en cuenta los siguientes aspectos:
attributeszip, maxRating, etc.).mvpdCuando caduca el perfil de usuario actual, la aplicación cliente puede utilizar la selección de MVPD recordada y solo pedirle al usuario que la confirme.
notAfterLa administración de errores de la aplicación cliente debe poder controlar el código de error authenticated_profile_expire, que indica que la aplicación cliente requiere que el usuario se vuelva a autenticar.
8. ¿Puede la aplicación cliente ampliar el perfil del usuario sin requerir una nueva autenticación?
No.
El perfil de usuario no puede extenderse más allá de su validez sin la interacción del usuario, ya que su caducidad está determinada por el TTL de autenticación establecido con MVPD.
Por lo tanto, la aplicación cliente debe solicitar al usuario que vuelva a autenticarse e interactúe con la página de inicio de sesión de MVPD para actualizar su perfil en el sistema.
Sin embargo, para las MVPD que admiten autenticación basada en el hogar (HBA), el usuario no tendrá que escribir credenciales.
9. ¿Cuáles son los casos de uso de cada extremo de perfiles disponible?
Los extremos básicos de perfiles están diseñados para proporcionar a la aplicación cliente la capacidad de conocer el estado de autenticación del usuario, acceder a la información de metadatos del usuario, encontrar el método utilizado para autenticarse o la entidad utilizada para proporcionar identidad.
Cada extremo se adapta a un caso de uso específico, como se indica a continuación:
En esta situación, la aplicación cliente no tiene el identificador de MVPD seleccionado del usuario en la caché en el almacenamiento persistente.
Como resultado, enviará una sola solicitud para recuperar todos los perfiles de usuario disponibles.
En este caso, la aplicación cliente debe tener el identificador de MVPD seleccionado anteriormente en la caché en el almacenamiento persistente.
Como resultado, enviará una única solicitud para recuperar el perfil del usuario para ese MVPD específico.
En este escenario, la aplicación cliente debe determinar si el usuario ha completado correctamente la autenticación y recuperar su información de perfil.
Como resultado, se iniciará un mecanismo de sondeo para recuperar el perfil del usuario asociado al código de autenticación.
Para obtener más información, consulte el flujo de perfiles básicos realizado en la aplicación principal y flujo de perfiles básicos realizado en documentos de la aplicación secundaria.
El extremo SSO de perfiles tiene un propósito diferente y proporciona a la aplicación cliente la capacidad de crear un perfil de usuario utilizando la respuesta de autenticación del socio y recuperarlo en una sola operación única.
En este caso, la aplicación cliente debe crear un perfil de usuario después de recibir la respuesta de autenticación del socio y recuperarlo en una única operación única.
Para cualquier consulta posterior, se deben usar los extremos básicos de perfiles para determinar el estado de autenticación del usuario, acceder a la información de metadatos del usuario, encontrar el método utilizado para autenticarse o la entidad utilizada para proporcionar identidad.
Para obtener más información, consulte los documentos Inicio de sesión único mediante flujos de socios y Guía de Apple SSO (API REST V2).
10. ¿Qué debe hacer la aplicación cliente si el usuario tiene varios perfiles de MVPD?
La decisión de admitir varios perfiles depende de los requisitos empresariales de la aplicación cliente.
La mayoría de los usuarios solo tendrán un perfil. Sin embargo, en los casos en los que existen varios perfiles (como se detalla a continuación), la aplicación cliente es la responsable de determinar la mejor experiencia del usuario para la selección de perfiles.
La aplicación cliente puede solicitar al usuario que seleccione el perfil de MVPD deseado o que realice la selección automáticamente, como elegir el primer perfil de usuario de la respuesta o el que tenga el periodo de validez más largo.
La API de REST v2 admite varios perfiles para admitir:
- Los usuarios que tengan que elegir entre un perfil de MVPD normal y uno obtenido mediante inicio de sesión único (SSO).
- A los usuarios se les ofrece acceso temporal sin necesidad de cerrar la sesión de su MVPD normal.
- Usuarios con suscripción a MVPD combinada con servicios directo al consumidor (DTC).
- Usuarios con varias suscripciones a MVPD.
11. ¿Qué sucede cuando los perfiles de usuario caducan?
Cuando los perfiles de usuario caducan, ya no se incluyen en la respuesta del extremo de perfiles.
Si el extremo Profiles devuelve una respuesta de asignación de perfiles vacía, la aplicación cliente debe crear una nueva sesión de autenticación y solicitar al usuario que vuelva a autenticarse.
Para obtener más información, consulte la Documentación de la API Crear sesión de autenticación.
12. ¿Cuándo los perfiles de usuario dejan de ser válidos?
Los perfiles de usuario dejan de ser válidos en los siguientes casos:
- Cuando caduca el TTL de autenticación, tal como indica la marca de tiempo
notAfteren la respuesta de extremo de perfiles. - Cuando la aplicación cliente cambia el valor del encabezado AP-Device-Identifier.
- Cuando la aplicación cliente actualiza las credenciales del cliente utilizadas para recuperar el valor del encabezado Authorization.
- Cuando la aplicación cliente revoca o actualiza la instrucción de software utilizada para obtener las credenciales del cliente.
13. ¿Cuándo debe iniciar la aplicación cliente el mecanismo de sondeo?
Para garantizar la eficacia y evitar solicitudes innecesarias, la aplicación cliente debe iniciar el mecanismo de sondeo en las siguientes condiciones:
Autenticación realizada en la aplicación principal (pantalla)
La aplicación principal (streaming) debe comenzar a sondear cuando el usuario llegue a la página de destino final, después de que el componente del explorador cargue la dirección URL especificada para el parámetro redirectUrl en la solicitud de extremo Sessions.
Autenticación realizada en una aplicación secundaria (pantalla)
La aplicación principal (streaming) debe comenzar a sondear en cuanto el usuario inicie el proceso de autenticación, justo después de recibir la respuesta del extremo Sessions y mostrar el código de autenticación al usuario.
14. ¿Cuándo debe detener la aplicación cliente el mecanismo de sondeo?
Para garantizar la eficacia y evitar solicitudes innecesarias, la aplicación cliente debe detener el mecanismo de sondeo en las siguientes condiciones:
Autenticación correcta
La información de perfil del usuario se ha recuperado correctamente, lo que confirma su estado de autenticación. En este punto, ya no es necesario el sondeo.
Sesión de autenticación y caducidad del código
La sesión de autenticación y el código caducan, tal como indica la marca de tiempo notAfter en la respuesta de extremo Sessions. Si esto sucede, el usuario debe reiniciar el proceso de autenticación y el sondeo con el código de autenticación anterior debe detenerse inmediatamente.
Nuevo código de autenticación generado
Si el usuario solicita un nuevo código de autenticación en el dispositivo principal (pantalla), la sesión existente ya no es válida y el sondeo con el código de autenticación anterior debe detenerse inmediatamente.
15. ¿Qué intervalo entre llamadas debe utilizar la aplicación cliente para el mecanismo de sondeo?
Para garantizar la eficacia y evitar solicitudes innecesarias, la aplicación cliente debe configurar la frecuencia del mecanismo de sondeo en las siguientes condiciones:
16. ¿Cuál es el número máximo de solicitudes de sondeo que puede enviar la aplicación cliente?
La aplicación cliente debe cumplir los límites actuales definidos por el mecanismo de limitación de autenticación de Adobe Pass.
La administración de errores de la aplicación cliente debe poder controlar el código de error 429 Demasiadas solicitudes, que indica que la aplicación cliente ha superado el número máximo de solicitudes permitidas.
Para obtener más información, consulte la documentación de Mecanismo de limitación.
17. ¿Cómo puede la aplicación cliente obtener la información de metadatos del usuario?
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)
Los metadatos del usuario están disponibles una vez finalizado el flujo de autenticación, por lo que la aplicación cliente no necesita consultar un extremo independiente para recuperar la información de metadatos del usuario, ya que ya está incluida en la información del perfil.
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
Algunos atributos de metadatos se pueden actualizar durante el flujo de autorización, según la MVPD y el atributo de metadatos específico. Como resultado, es posible que la aplicación cliente tenga que volver a consultar las API anteriores para recuperar los metadatos de usuario más recientes.
18. ¿Cómo debe administrar la aplicación cliente el acceso degradado?
La característica de degradación permite que la aplicación cliente mantenga una experiencia de transmisión perfecta para los usuarios, incluso cuando los servicios de autenticación o autorización de MVPD encuentren problemas.
En resumen, esto puede garantizar el acceso ininterrumpido al contenido a pesar de las interrupciones temporales del servicio de MVPD.
Dado que su organización tiene intención de utilizar la función de degradación Premium, la aplicación cliente debe gestionar los flujos de acceso degradados, que describen cómo se comportan los extremos de la API de REST v2 en estos casos.
Para obtener más información, consulte la documentación de Flujos de acceso degradados.
19. ¿Cómo debe administrar la aplicación cliente el acceso temporal?
La característica TempPass permite que la aplicación cliente proporcione acceso temporal al usuario.
En resumen, esto puede atraer a los usuarios al proporcionar acceso limitado al contenido o a un número predefinido de títulos de VOD durante un período de tiempo especificado.
Dado que su organización tiene intención de utilizar la función TempPass Premium, la aplicación cliente debe administrar los flujos de acceso temporales, que describen cómo se comportan los extremos de la API de REST v2 en estos casos.
En versiones anteriores de la API, la aplicación cliente tenía que cerrar la sesión de un usuario autenticado con su MVPD normal para ofrecer acceso temporal.
Con la API de REST v2, la aplicación cliente puede alternar sin problemas entre una MVPD normal y una MVPD TempPass al autorizar un flujo, lo que elimina la necesidad de cerrar la sesión del usuario.
Para obtener más información, consulte la documentación de Flujos de acceso temporales.
20. ¿Cómo debe administrar la aplicación cliente el acceso de inicio de sesión único entre dispositivos?
La API de REST v2 puede habilitar el inicio de sesión único entre dispositivos si la aplicación cliente proporciona un identificador de usuario único y coherente entre dispositivos.
La aplicación cliente debe generar este identificador, conocido como token de servicio, mediante la implementación o integración de un servicio de identidad externo de su elección.
Para obtener más información, consulte la documentación de Inicio de sesión único mediante flujos de token de servicio.
Preguntas frecuentes sobre la fase de preautorización
1. ¿Cuál es el propósito de la fase de preautorización?
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?
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?
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. ¿Debe la aplicación cliente almacenar en caché las decisiones de preautorización en un almacenamiento persistente?
La aplicación cliente no es necesaria para almacenar decisiones de preautorización en almacenamiento persistente. Sin embargo, se recomienda almacenar en caché las decisiones de permiso en la memoria para mejorar la experiencia del usuario. Esto ayuda a evitar llamadas innecesarias al extremo de preautorización de Decisions para recursos que ya se han preautorizado, lo que reduce la latencia y mejora el rendimiento.
5. ¿Cómo puede determinar la aplicación cliente por qué se denegó una decisión de preautorización?
La aplicación cliente puede determinar el motivo de una decisión de preautorización denegada inspeccionando el código de error y el mensaje incluidos en la respuesta del extremo de preautorización de Decisions. Estos detalles proporcionan una perspectiva del motivo específico por el que se denegó la solicitud de preautorización, lo que ayuda a informar a la experiencia del usuario o al déclencheur de cualquier tratamiento necesario en la aplicación.
Asegúrese de que cualquier mecanismo de reintento implementado para recuperar decisiones de preautorización no genere un bucle interminable si se deniega la decisión de preautorización.
Considere la posibilidad de limitar los reintentos a un número razonable y administrar las denegaciones correctamente mostrando comentarios claros al usuario.
6. ¿Por qué en la decisión de preautorización falta un token de medios?
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.
7. ¿Se puede omitir la fase de autorización si ya existe una decisión de preautorización?
No.
La fase de autorización no se puede omitir aunque haya una decisión de preautorización disponible. Las decisiones de preautorización son solo informativas y no otorgan derechos de reproducción reales. La fase de preautorización pretende proporcionar directrices tempranas, pero la fase de autorización sigue siendo necesaria antes de reproducir cualquier contenido.
8. ¿Qué es un recurso y qué formatos se admiten?
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 de Recursos protegidos.
9. ¿Para cuántos recursos puede la aplicación cliente obtener una decisión de preautorización a la vez?
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.
Preguntas frecuentes sobre la fase de autorización
1. ¿Cuál es el propósito de la fase de autorización?
El propósito de la fase de autorización es proporcionar a la aplicación cliente la capacidad de reproducir recursos que el usuario solicita después de validar sus derechos con MVPD.
2. ¿Es obligatoria la fase de autorización?
La fase de autorización es obligatoria, la aplicación cliente no puede omitir esta fase si desea reproducir recursos que solicita el usuario, ya que requiere verificar con 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?
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 extremo 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 solicitar consultar de nuevo 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. ¿Debe la aplicación cliente almacenar en caché las decisiones de autorización en un almacenamiento persistente?
La aplicación cliente no es necesaria para almacenar decisiones de autorización en almacenamiento persistente.
5. ¿Cómo puede determinar la aplicación cliente por qué se denegó una decisión de autorización?
La aplicación cliente puede determinar el motivo de una decisión de autorización denegada inspeccionando el código de error y el mensaje incluidos en la respuesta del extremo de autorización de decisiones. Estos detalles proporcionan una perspectiva del motivo específico por el que se denegó la solicitud de autorización, lo que ayuda a informar a la experiencia del usuario o al déclencheur de cualquier tratamiento necesario en la aplicación.
Asegúrese de que cualquier mecanismo de reintento implementado para recuperar decisiones de autorización no genere un bucle interminable si se deniega la decisión de autorización.
Considere la posibilidad de limitar los reintentos a un número razonable y administrar las denegaciones correctamente mostrando comentarios claros al usuario.
6. ¿Qué es un token de medios y durante cuánto tiempo es válido?
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 Comprobador de token 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 el límite de tiempo antes de que la aplicación cliente deba verificarlo y utilizarlo.
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
7. ¿Debe la aplicación cliente validar el token de medios antes de reproducir el flujo de recursos?
Sí.
La aplicación cliente debe validar el token de medios antes de iniciar la reproducción del flujo de recursos. Esta validación debe realizarse con el Comprobador de token de medios. Al comprobar serializedToken desde el objeto token devuelto, la aplicación cliente ayuda a evitar el acceso no autorizado, como la copia desde secuencias, y garantiza que solo los usuarios autorizados correctamente puedan reproducir el contenido.
8. ¿Debe la aplicación cliente actualizar un token de medios caducado durante la reproducción?
No.
La aplicación cliente no es necesaria para actualizar un token de medios caducado mientras el flujo se está reproduciendo activamente. Si el token de medios caduca durante la reproducción, se debe permitir que el flujo continúe ininterrumpidamente. Sin embargo, el cliente debe solicitar una nueva decisión de autorización y obtener un nuevo token de medios la próxima vez que el usuario intente reproducir el mismo recurso.
9. ¿Cuál es la finalidad de cada atributo de marca de tiempo en la decisión de autorización?
La decisión de autorización incluye varios atributos de marca de tiempo que proporcionan un contexto esencial sobre el periodo de validez de la propia autorización y el token de medios asociado. Estas marcas de tiempo tienen diferentes propósitos, dependiendo de si están relacionadas con la decisión de autorización o el token de medios.
Marcas de hora de nivel de decisión
Estas marcas de tiempo describen el periodo de validez de la decisión de autorización general:
notBeforenotAfterMarcas de hora a nivel de token
Estas marcas de tiempo describen el periodo de validez del token de medios asociado a la decisión de autorización:
notBeforenotAfter10. ¿Qué es un recurso y qué formatos se admiten?
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 de Recursos protegidos.
11. ¿Para cuántos recursos puede obtener la aplicación cliente una decisión de autorización a la vez?
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.
Preguntas frecuentes sobre la fase de cierre
1. ¿Cuál es el propósito de la fase de cierre de sesión?
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.
2. ¿Es obligatoria la fase de cierre de sesión?
La fase de cierre de sesión es obligatoria, la aplicación cliente debe proporcionar al usuario la capacidad de cerrar la sesión.
Preguntas frecuentes sobre encabezados
1. ¿Cómo se calcula el valor del encabezado Autorización?
IMPORTANTBearer que antes.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
2. ¿Cómo calcular el valor del encabezado AP-Device-Identifier?
IMPORTANTEl 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 ejemplos para las plataformas principales sobre cómo calcular el valor, pero la aplicación cliente puede elegir utilizar un método diferente según su propia lógica y requisitos empresariales.
3. ¿Cómo calcular el valor del encabezado X-Device-Info?
IMPORTANTEl 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 y se usa para determinar las reglas específicas de la plataforma que las MVPD pueden aplicar.
La documentación del encabezado X-Device-Info proporciona ejemplos para las plataformas principales sobre cómo calcular el valor, pero la aplicación cliente puede elegir utilizar un método diferente según su propia lógica y requisitos empresariales.
Si falta el encabezado X-Device-Info o contiene valores incorrectos, la solicitud puede clasificarse como originada en una plataforma unknown.
Esto puede hacer que la solicitud se trate como no segura y sujeta a reglas más restrictivas, como TTL de autenticación más cortos. Además, algunos campos, como el dispositivo de transmisión por secuencias connectionIp y connectionPort, son obligatorios para características como la autenticación de base principal de Spectrum.
Incluso cuando la solicitud se origina desde un servidor en nombre de un dispositivo, el valor del encabezado X-Device-Info debe reflejar la información real del dispositivo de flujo continuo.
Preguntas frecuentes varias
1. ¿Puedo explorar las solicitudes y respuestas de la API de REST V2 y probar la API?
Sí.
Puede explorar la API REST V2 a través de nuestro sitio web Adobe Developer. El sitio web de Adobe Developer proporciona acceso sin restricciones a:
Para interactuar con la API de REST V2, debe incluir el encabezado Autorización con un token de acceso de Bearer obtenido a través de la API de DCR.
Para usar la API de DCR, se requiere una instrucción de software con el ámbito de API de REST V2. Para obtener más información, consulte el documento Preguntas frecuentes sobre el registro dinámico de clientes (DCR).
2. ¿Puedo explorar las solicitudes y respuestas de la API de REST V2 mediante una herramienta de desarrollo de API compatible con OpenAPI?
Sí.
Puede descargar archivos de especificación OpenAPI para la API de DCR y la API de REST V2 desde el sitio web de Adobe Developer.
Para descargar los archivos de especificación de OpenAPI, haga clic en los botones de descarga para guardar los siguientes archivos en el equipo local:
A continuación, puede importar estos archivos en la herramienta de desarrollo de API que prefiera para explorar las solicitudes y respuestas de la API de REST V2 y probar la API.
3. ¿Puedo seguir utilizando la herramienta de prueba de API existente alojada en https://sp.auth-staging.adobe.com/apitest/api.html?
No.
Las aplicaciones cliente que migran a la API de REST V2 deben utilizar la nueva herramienta de prueba alojada en https://developer.adobe.com/adobe-pass/. El sitio web de Adobe Developer proporciona acceso sin restricciones a:
Para interactuar con la API de REST V2, debe incluir el encabezado Autorización con un token de acceso de Bearer obtenido a través de la API de DCR.
Para usar la API de DCR, se requiere una instrucción de software con el ámbito de API de REST V2. Para obtener más información, consulte el documento Preguntas frecuentes sobre el registro dinámico de clientes (DCR).
Preguntas frecuentes sobre migración
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.
Preguntas frecuentes generales sobre migración
1. ¿Debo implementar una nueva aplicación cliente migrada a la API de REST V2 para todos los usuarios a la vez?
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 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?
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 tanto la API de REST V2 como 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?
No.
No se conservará la autenticación de usuario obtenida en versiones anteriores de aplicaciones cliente que integran la API de REST V1 o 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. ¿Los códigos de error mejorados están habilitados de forma predeterminada en la API de REST V2?
Sí.
Las aplicaciones cliente que migran a la API de REST V2 se benefician automáticamente de esta función de forma predeterminada, lo que proporciona información de error más detallada y precisa.
Para obtener más información, consulte la documentación de Códigos de error mejorados.
5. ¿Las integraciones existentes requieren cambios de configuración al migrar a la API de REST V2?
No.
Las aplicaciones cliente que migran a la API de REST V2 no requieren ningún cambio de configuración para las integraciones de MVPD existentes. Además, seguirán usando los mismos identificadores para los proveedores de servicios y MVPD existentes.
Además, los protocolos utilizados por la autenticación de Adobe Pass para comunicarse con los extremos de MVPD permanecen inalterados.
Migración de la API de REST V1 a la API de REST V2
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.
Preguntas frecuentes sobre la fase de registro
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de registro?
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:
Preguntas frecuentes sobre la fase de configuración
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de configuración?
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:
Preguntas frecuentes sobre la fase de autenticación
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de autenticación?
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:
Para obtener más información, consulte los siguientes documentos:
Para obtener más información, consulte los siguientes documentos:
/api/v2/{serviceProvider}/sesiones/{code}
GET
/api/v2/authenticate/{serviceProvider}/{code}
Para obtener más información, consulte los siguientes documentos:
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
Preguntas frecuentes sobre la fase de preautorización
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de preautorización?
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:
Para obtener más información, consulte los siguientes documentos:
Preguntas frecuentes sobre la fase de autorización
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de autorización?
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:
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
- Iniciar autorización de (MVPD)
- Recuperar decisión de autorización
- Recuperar token de medios corto
Para obtener más información, consulte los siguientes documentos:
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
- Iniciar autorización de (MVPD)
- Recuperar decisión de autorización
- Recuperar token de medios corto
Para obtener más información, consulte los siguientes documentos:
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
- Iniciar autorización de (MVPD)
- Recuperar decisión de autorización
- Recuperar token de medios corto
Para obtener más información, consulte los siguientes documentos:
Preguntas frecuentes sobre la fase de cierre
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de cierre de sesión?
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:
Para obtener más información, consulte los siguientes documentos:
Migración de SDK a la API de REST V2
Continúe con esta subsección si está trabajando en una aplicación que necesita migrar de SDK a la API de REST V2.
Preguntas frecuentes sobre la fase de registro
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de registro?
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:
AccessEnabler JavaScript SDK
Para obtener más información, consulte los siguientes documentos:
AccessEnabler iOS/tvOS SDK
Para obtener más información, consulte los siguientes documentos:
AccessEnabler Android SDK
Para obtener más información, consulte los siguientes documentos:
AccessEnabler FireOS SDK
Para obtener más información, consulte los siguientes documentos:
Preguntas frecuentes sobre la fase de configuración
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de configuración?
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:
AccessEnabler JavaScript SDK
AccessEnabler iOS/tvOS SDK
AccessEnabler Android SDK
AccessEnabler FireOS SDK
Preguntas frecuentes sobre la fase de autenticación
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de autenticación?
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:
AccessEnabler JavaScript SDK
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
AccessEnabler iOS SDK
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
AccessEnabler tvOS SDK
Para obtener más información, consulte los siguientes documentos:
Para obtener más información, consulte los siguientes documentos:
/api/v2/{serviceProvider}/sesiones/{code}
GET
/api/v2/authenticate/{serviceProvider}/{code}
Para obtener más información, consulte los siguientes documentos:
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
AccessEnabler Android SDK
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
AccessEnabler FireOS SDK
Para obtener más información, consulte los siguientes documentos:
Para obtener más información, consulte los siguientes documentos:
/api/v2/{serviceProvider}/sesiones/{code}
GET
/api/v2/authenticate/{serviceProvider}/{code}
Para obtener más información, consulte los siguientes documentos:
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
GET
/api/v2/{serviceProvider}/profiles
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:
- Comprobar estado de autenticación del usuario
- Recuperar perfil de usuario
- Recuperar información de metadatos de usuario
Para obtener más información, consulte los siguientes documentos:
Preguntas frecuentes sobre la fase de preautorización
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de preautorización?
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:
AccessEnabler JavaScript SDK
Para obtener más información, consulte los siguientes documentos:
AccessEnabler iOS/tvOS SDK
Para obtener más información, consulte los siguientes documentos:
AccessEnabler Android SDK
Para obtener más información, consulte los siguientes documentos:
Para obtener más información, consulte los siguientes documentos:
Preguntas frecuentes sobre la fase de autorización
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de autorización?
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:
AccessEnabler JavaScript SDK
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
- Iniciar autorización de (MVPD)
- Recuperar decisión de autorización
- Recuperar token de medios corto
Para obtener más información, consulte los siguientes documentos:
AccessEnabler iOS/tvOS SDK
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
- Iniciar autorización de (MVPD)
- Recuperar decisión de autorización
- Recuperar token de medios corto
Para obtener más información, consulte los siguientes documentos:
AccessEnabler Android SDK
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
- Iniciar autorización de (MVPD)
- Recuperar decisión de autorización
- Recuperar token de medios corto
Para obtener más información, consulte los siguientes documentos:
AccessEnabler FireOS SDK
La aplicación cliente puede utilizar la respuesta de esta API para varios fines a la vez:
- Iniciar autorización de (MVPD)
- Recuperar decisión de autorización
- Recuperar token de medios corto
Para obtener más información, consulte los siguientes documentos:
Preguntas frecuentes sobre la fase de cierre
1. ¿Cuáles son las migraciones de API de alto nivel necesarias para la fase de cierre de sesión?
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:
AccessEnabler JavaScript SDK
Para obtener más información, consulte los siguientes documentos:
AccessEnabler iOS/tvOS SDK
Para obtener más información, consulte los siguientes documentos:
AccessEnabler Android SDK
Para obtener más información, consulte los siguientes documentos:
AccessEnabler FireOS SDK
Para obtener más información, consulte los siguientes documentos: