Guía de la API de REST (heredada) (de cliente a servidor) rest-api-cookbook-client-to-server
Información general overview
Este documento proporciona instrucciones paso a paso para que el equipo de ingeniería de un programador integre un "dispositivo inteligente" (consola de juegos, aplicación de Smart TV, descodificador, etc.) con la autenticación de Adobe Pass mediante los servicios de API de REST. Este método de cliente a servidor, que utiliza API de REST en lugar de una SDK de cliente, ofrece una compatibilidad más amplia con diferentes plataformas para las que no sería posible desarrollar un número significativo de SDK únicos. Para obtener una amplia descripción técnica del funcionamiento de la solución sin cliente, vea Información general técnica sin cliente.
Este método requiere dos componentes (aplicación de streaming y aplicación AuthN) para completar los flujos necesarios: los flujos de inicio, registro, autorización y medios de visualización en la aplicación de streaming, y el flujo de autenticación en la aplicación AuthN.
Mecanismo de limitación
La API de REST de autenticación de Adobe Pass se rige por un mecanismo de restricción.
Componentes components
En una solución de cliente a servidor en funcionamiento están implicados los siguientes componentes:
Flujos flows
Registro dinámico de clientes (DCR)
Adobe Pass utiliza DCR para proteger las comunicaciones de cliente entre una aplicación o un servidor de programación y los servicios de Adobe Pass. El flujo de DCR es independiente y se describe en la documentación de información general sobre el registro dinámico de clientes.
Flujos de aplicaciones de streaming (Smart Device)
Flujo de inicio
-
La aplicación se inicia y carga su interfaz de usuario inicial.
-
Obtenga o genere un ID de dispositivo.
-
Ejecute una llamada de autenticación de comprobación para ver si el dispositivo ya está autenticado. Por ejemplo:
<SP_FQDN>/api/v1/checkauthn [device ID] -
Si la llamada a
checkauthnse realiza correctamente, continúe con el Flujo de autorización a partir del paso 2. Si se produce un error, inicie el flujo de registro.
Flujo de registro
-
Obtenga un código de registro y una URL para que el usuario utilice para acceder a la aplicación de inicio de sesión en la segunda pantalla y preséntele al usuario lo siguiente:
a. Envíe una petición POST al servicio Adobe Registration Code, pasando un ID de dispositivo con hash y una "URL de registro". Por ejemplo:
<REGGIE_FQDN>/reggie/v1/[requestorId]/regcode [device ID]b. Presente el código de registro devuelto y la dirección URL al usuario.
c. Indique al usuario que cambie a un dispositivo compatible con la web, vaya a la URL y, a continuación, introduzca el código de registro.
Flujo de autorización
-
El usuario vuelve de la aplicación de la segunda pantalla y pulsa el botón "Continuar" del dispositivo. Alternativamente, puede implementar un mecanismo de sondeo para comprobar el estado de autenticación, pero la autenticación de Adobe Pass recomienda el método del botón Continuar sobre el sondeo. Por ejemplo: <SP_FQDN>/api/v1/tokens/authn
-
Envíe una solicitud de GET al servicio de autorización de autenticación de Adobe Pass para iniciar la autorización. Por ejemplo:
<SP_FQDN>/api/v1/authorize [device ID, Requestor ID, Resource ID]
-
Si la respuesta indica éxito: El usuario tiene un token de AuthN válido Y el usuario está autorizado a ver los medios solicitados (hay un token de AuthZ válido para este usuario).
-
Si la respuesta indica un error: Examine la excepción producida para determinar su tipo (AuthN, AuthZ o algo más):
-
Si se ha producido un error de AuthN, vuelva a iniciar el flujo de registro.
-
Si se ha producido un error de AuthZ, el usuario no tiene autorización para ver el contenido solicitado y se le debe mostrar algún tipo de mensaje de error.
-
Si se ha producido algún otro error (error de conexión, error de red, etc.), muestre un mensaje de error apropiado al usuario.
-
Ver flujo de medios
-
Opciones de medios actuales. El usuario selecciona los medios que desea ver.
-
¿Están protegidos los medios?
a. La aplicación comprueba si los medios están protegidos.
b. Si el medio está protegido, la aplicación inicia la Autorización
(AuthZ) Flujo superior.c. Si los medios no están protegidos, reproduzca los medios para el
usuario. -
Reproducción de los medios.
Flujo de aplicación AuthN (2ª pantalla)
-
Obtenga una lista de MVPD para este usuario. Por ejemplo:
<SP_FQDN>/api/v1/config/[requestorID] -
Inicie el flujo de autenticación. Por ejemplo:
<SP_FQDN>/api/v1/authenticate [requestorID, MVPD ID, Redirect URL, Domain name, Registration Code, "noflash=true"] -
Compruebe si la autenticación se realizó correctamente. Por ejemplo:
<SP_FQDN>/api/v1/checkauthn/[registration code][requestor ID] -
Envíe al usuario de nuevo a la aplicación de Smart Device para completar el flujo de autorización.
Inicio de sesión único de socio partner-sso
Algunos dispositivos proporcionan compatibilidad dedicada para el inicio de sesión único (SSO) de Partner:
Inicio de sesión único de Platform platform-sso
Algunos dispositivos proporcionan compatibilidad dedicada para el inicio de sesión único (SSO) de Platform:
TempPass y TempPass promocional para la API de REST temppass
En el caso de implementaciones de TempPass y Promotional TempPass en las que no se requiere que el usuario introduzca credenciales, la autenticación se puede implementar directamente en la aplicación de streaming.
Para usar esta API, la aplicación de streaming debe asegurarse de que el ID del dispositivo sea único, ya que se está usando para identificar el token, junto con los datos adicionales opcionales.
