Guía de API de REST V2 (de cliente a servidor)
- Temas:
- Autenticación
IMPORTANTE IMPORTANTEEl documento está dirigido a desarrolladores que están integrando la API de REST de autenticación de Adobe Pass V2 en sus aplicaciones de flujo continuo que tienen una arquitectura de cliente a servidor (C2S).
Requisitos previos
Para ver los términos y definiciones, consulte la documentación de Glosario de la API de REST V2.
Para conocer los requisitos obligatorios y las prácticas recomendadas, consulte la documentación de Lista de comprobación de la API de REST V2.
Para ver las preguntas más frecuentes, consulte la documentación de preguntas frecuentes sobre la API de REST V2.
A. Fase de registro
El propósito de la fase de registro es registrar la aplicación de flujo continuo con la autenticación de Adobe Pass a través del proceso de registro de cliente dinámico (DCR).
El proceso de registro dinámico de clientes (DCR) requiere que la aplicación de streaming obtenga un par de credenciales de cliente y recupere un token de acceso como objetivo final de la fase de registro.
La fase de registro es obligatoria, pero la aplicación de streaming puede omitir esta fase si tiene un par en caché de credenciales de cliente y un token de acceso que aún son válidos.
API:
Flujos:
Preguntas más frecuentes:
Paso 1: Registro de la aplicación
-
Recuperar credenciales de cliente: La aplicación de flujo continuo recupera las credenciales de cliente llamando al extremo /o/client/register.
- La aplicación de streaming debe almacenar las credenciales del cliente y utilizarlas indefinidamente cuando necesite recuperar un token de acceso.
-
Recuperar token de acceso: La aplicación de transmisión recupera el token de acceso llamando al extremo /o/client/token.
- La aplicación de streaming debe almacenar y utilizar el token de acceso hasta que caduque y luego descartarlo y obtener uno nuevo.
B. Fase de autenticación
El propósito de la fase de autenticación es proporcionar a la aplicación de transmisión 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 de autorización cuando la aplicación de streaming necesita reproducir contenido.
API
- Crear sesión de autenticación
- Reanudar sesión de autenticación
- Recuperar sesión de autenticación
- Realizar autenticación en el agente de usuario
- Recuperación de perfiles
- Recuperar perfil para mvpd específico
- Recuperar perfil para código específico
Flujos
- Flujo de autenticación básico realizado en la aplicación principal
- Flujo de autenticación básico realizado en la aplicación secundaria
- Flujo de perfiles básicos realizado dentro de la aplicación principal
- Flujo de perfiles básicos realizado en la aplicación secundaria
preguntas más frecuentes
Paso 2: Compruebe si hay perfiles autenticados existentes
-
Recuperar perfiles: La aplicación de streaming comprueba los perfiles existentes llamando al extremo /api/v2/{serviceProvider}/profiles.
-
Escenario 1: Hay perfiles existentes, la aplicación de streaming puede continuar con la Fase de preautorización o Fase de autorización.
-
Escenario 2: No existen perfiles, la aplicación de streaming puede continuar con el siguiente paso para Autenticar al usuario.
-
Escenario 3: No existen perfiles, la aplicación de streaming puede continuar para proporcionar al usuario acceso temporal a través de la característica TempPass.
- Este escenario está fuera del ámbito de este documento. Consulte la documentación de Flujos de acceso temporales para obtener más información.
Paso 3: Autenticar al usuario
-
Recuperar configuración: La aplicación de streaming recupera la lista de MVPD disponibles llamando al extremo /api/v2/{serviceProvider}/configuration.
- La aplicación de streaming puede implementar un mecanismo de filtrado personalizado para restringir la lista de MVPD de la respuesta de configuración, mostrando solo los proveedores deseados mientras oculta otros (por ejemplo, MVPD en desarrollo, MVPD de prueba, TempPass). Esto garantiza que los usuarios tengan una selección revisada al elegir su proveedor de TV.
-
Crear sesión de autenticación: La aplicación de transmisión inicia una sesión de autenticación llamando al extremo /api/v2/{serviceProvider}/session.
-
Escenario 1: La aplicación de transmisión por secuencias puede abrir un explorador o una vista web, por lo que debe cargar la autenticación
url.- El usuario envía su nombre de usuario y contraseña en la página de inicio de sesión de MVPD. Tras la autenticación correcta, la redirección final muestra una página de éxito.
-
Escenario 2: La aplicación de transmisión por secuencias no puede abrir un explorador, por lo que debe mostrar la autenticación
code. Se requiere una aplicación web independiente para solicitar al usuario que introduzcacode, construya la autenticaciónurly abra: /api/v2/authenticate/{serviceProvider}/{code}.- El usuario envía su nombre de usuario y contraseña en la página de inicio de sesión de MVPD. Tras la autenticación correcta, la redirección final muestra una página de éxito.
Paso 4: Comprobación de perfiles autenticados
-
Recuperar perfil para código específico: La aplicación de streaming debe implementar un mecanismo de sondeo usando
codepara comprobar si el perfil se generó y guardó correctamente llamando al extremo /api/v2/{serviceProvider}/profiles/code/{code}.-
La aplicación de streaming debe iniciar el mecanismo de sondeo bajo las siguientes condiciones:
-
Autenticación realizada en la aplicación principal (pantalla): La aplicación principal (flujo) 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
redirectUrlen la solicitud de extremo de Sessions. -
Autenticación realizada en una aplicación secundaria (pantalla): La aplicación primaria (streaming) debe comenzar a sondear en cuanto el usuario inicie el proceso de autenticación, justo después de recibir la respuesta de extremo Sessions y mostrar el código de autenticación al usuario.
-
-
La aplicación de streaming debe detener el mecanismo de sondeo bajo 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(por ejemplo, 30 minutos) 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.
-
-
La aplicación de streaming debe configurar la frecuencia del mecanismo de sondeo en las siguientes condiciones:
-
Autenticación realizada en la aplicación principal (pantalla): La aplicación principal (flujo) debe sondear cada 3-5 segundos o más.
-
Autenticación realizada en una aplicación secundaria (pantalla): La aplicación principal (flujo) debe sondear cada 3-5 segundos o más.
-
-
La aplicación de streaming debe almacenar en caché partes de la información de perfil del usuario en un almacenamiento persistente para evitar solicitudes innecesarias y mejorar la experiencia del usuario.
-
C. Fase de preautorización (opcional)
El propósito de la fase de preautorización es proporcionar a la aplicación de transmisión 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 de flujo continuo por primera vez o navega a una nueva sección.
La fase de preautorización no es obligatoria, la aplicación de streaming puede omitir esta fase si desea presentar un catálogo de recursos sin filtrarlos primero según el derecho del usuario.
Paso 5: buscar recursos autorizados previamente
-
Recuperar decisiones de preautorización: La aplicación de streaming recupera decisiones de preautorización para una lista de recursos llamando al extremo /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}.
-
La aplicación de streaming 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 a recursos que ya se han preautorizado, lo que reduce la latencia y mejora el rendimiento.
-
La aplicación de streaming 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 a insight el 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.
-
La aplicación de streaming puede obtener una decisión de preautorización para un número limitado de recursos en una sola solicitud de API, generalmente 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.
-
D. Fase de autorización
El propósito de la fase de autorización es proporcionar a la aplicación de streaming la capacidad de reproducir recursos que el usuario solicita después de validar sus derechos con MVPD.
La fase de autorización es obligatoria, la aplicación de streaming no puede omitir esta fase si desea reproducir recursos que el usuario solicita, ya que requiere verificar con la MVPD que el usuario tiene derecho antes de liberar el flujo.
API
Flujos
preguntas más frecuentes
Paso 6: buscar recursos autorizados
-
Recuperar decisión de autorización: La aplicación de transmisión recupera la decisión de autorización para un recurso específico llamando al extremo /api/v2/{serviceProvider}/decision/authorize/{mvpd}.
-
La aplicación de streaming no es necesaria para almacenar decisiones de autorización en almacenamiento persistente.
-
La aplicación de streaming 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 Decisions. Estos detalles proporcionan a insight el 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.
-
La aplicación de streaming 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 un recurso.
-
La aplicación de streaming puede obtener una decisión de autorización para un número limitado de recursos en una sola solicitud de API, generalmente hasta 1, debido a condiciones impuestas por MVPD.
-
E. Fase de cierre
El propósito de la fase de cierre de sesión es proporcionar a la aplicación de streaming la capacidad de finalizar el perfil autenticado del usuario dentro de la autenticación de Adobe Pass si el usuario lo solicita.
La fase de cierre de sesión es obligatoria, la aplicación de streaming debe proporcionar al usuario la capacidad de cerrar la sesión.
Paso 7: Cerrar sesión
-
Iniciar el cierre de sesión de Adobe Pass: La aplicación de streaming inicia el flujo de cierre de sesión llamando al extremo /api/v2/{serviceProvider}/logout/{mvpd}.
-
La aplicación de flujo continuo debe seguir las instrucciones proporcionadas en los atributos
actionNameyactionTypede la respuesta de extremo de cierre de sesión para garantizar que el proceso de cierre de sesión se complete correctamente.-
Si el atributo
actionTypede la respuesta está establecido en "interactivo":-
Escenario 1: La aplicación de flujo continuo puede abrir un explorador o una vista web, por lo que debe cargar el cierre de sesión
url. -
Escenario 2: La aplicación de transmisión por secuencias no puede abrir un explorador, por lo que el proceso de cierre de sesión se puede detener porque la sesión de MVPD no persistió en la memoria caché de un explorador de dispositivo de transmisión.
-
-
-