Manuel de l’API REST (hérité) (client à serveur) rest-api-cookbook-client-to-server
Vue d’ensemble overview
Ce document fournit des instructions détaillées à l’équipe d’ingénierie d’un programmeur pour intégrer un « appareil intelligent » (console de jeu, application de télévision intelligente, décodeur, etc.) à l’authentification Adobe Pass à l’aide des services d’API REST. Cette approche client à serveur, qui utilise des API REST plutôt qu’un SDK client, permet une prise en charge plus large de différentes plateformes pour lesquelles le développement d’un nombre important de SDK uniques ne serait pas possible. Pour une présentation technique générale du fonctionnement de la solution découplée, reportez-vous à la Présentation technique du découplage.
Cette approche nécessite deux composants (application de streaming et application AuthN) pour terminer les flux requis : les flux de démarrage, d’enregistrement, d’autorisation et de média d’affichage dans l’application de streaming, ainsi que le flux d’authentification dans votre application AuthN.
Mécanisme de limitation
L’API REST d’authentification Adobe Pass est régie par un mécanisme de limitation.
Composants components
Dans une solution client à serveur opérationnelle, les composants suivants sont impliqués :
Flux flows
Enregistrement de client dynamique (DCR)
Adobe Pass utilise le DCR pour sécuriser les communications client entre une application ou un serveur de programmation et les services Adobe Pass. Le flux DCR est distinct et est décrit dans la documentation Présentation de l’enregistrement du client dynamique .
Flux D’Applications De Diffusion En Continu (Smart Device)
Flux de démarrage
-
Votre application démarre et charge son interface utilisateur initiale.
-
Obtenir/générer un identifiant d’appareil.
-
Émettez un appel Check-authentication pour vérifier si l’appareil est déjà authentifié. Par exemple :
<SP_FQDN>/api/v1/checkauthn [device ID] -
Si l’appel
checkauthnréussit, passez au flux d’autorisation à partir de l’étape 2. En cas d’échec, démarrez le flux d’enregistrement.
Flux d’enregistrement
-
Obtenez un code d’enregistrement et une URL que votre utilisateur peut utiliser pour accéder à l’application de connexion du deuxième écran, puis présentez-les à l’utilisateur :
a. Envoyez une requête POST au service Adobe Registration Code, en transmettant un ID d’appareil haché et une « URL d’enregistrement ». Par exemple :
<REGGIE_FQDN>/reggie/v1/[requestorId]/regcode [device ID]b. Présentez le code d’enregistrement et l’URL renvoyés à l’utilisateur.
c. Demandez à l’utilisateur de passer à un appareil compatible avec le Web, accédez à l’URL, puis saisissez le code d’enregistrement.
Flux d’autorisation
-
L’utilisateur revient de l’application du deuxième écran et appuie sur le bouton « Continuer » sur votre appareil. Vous pouvez également implémenter un mécanisme d’interrogation pour vérifier le statut de l’authentification, mais l’Authentification Adobe Pass recommande la méthode du bouton Continuer plutôt que l’interrogation. Par exemple : <SP_FQDN>/api/v1/tokens/authn
-
Envoyez une requête GET au service d’autorisation Authentification Adobe Pass pour lancer l’autorisation. Par exemple :
<SP_FQDN>/api/v1/authorize [device ID, Requestor ID, Resource ID]
-
Si la réponse indique la réussite : l’utilisateur possède un jeton AuthN valide ET il est autorisé à regarder le média demandé (il existe un jeton AuthZ valide pour cet utilisateur).
-
Si la réponse indique un échec : examinez l’exception renvoyée pour déterminer son type (AuthN, AuthZ ou autre chose) :
-
S’il s’agissait d’une erreur d’authentification, redémarrez le flux d’enregistrement.
-
S’il s’agissait d’une erreur AuthZ, l’utilisateur n’est pas autorisé à regarder le média demandé et un message d’erreur doit s’afficher à l’intention de l’utilisateur.
-
Si une autre erreur s’est produite (erreur de connexion, erreur réseau, etc.), affichez un message d’erreur approprié à l’intention de l’utilisateur.
-
Afficher le flux multimédia
-
Présenter les choix de médias. L’utilisateur sélectionne le média à afficher.
-
Les médias sont-ils protégés ?
a. Votre application vérifie si le média est protégé.
b. Si le média est protégé, votre application démarre l’autorisation.
(AuthZ) Flux ci-dessus.c. Si le média n’est pas protégé, lisez le média pour le
utilisateur. -
Lire le média.
Flux d’application AuthN (deuxième écran)
-
Obtenez une liste des fichiers MVPD pour cet utilisateur. Par exemple :
<SP_FQDN>/api/v1/config/[requestorID] -
Lancez le flux d’authentification. Par exemple :
<SP_FQDN>/api/v1/authenticate [requestorID, MVPD ID, Redirect URL, Domain name, Registration Code, "noflash=true"] -
Vérifiez si l’authentification a réussi. Par exemple :
<SP_FQDN>/api/v1/checkauthn/[registration code][requestor ID] -
Renvoyez l’utilisateur à votre application Smart Device pour terminer le flux d’autorisation.
Authentification SSO Du Partenaire partner-sso
Certains appareils fournissent une prise en charge dédiée à l’authentification unique (SSO) du partenaire :
Authentification Unique Platform platform-sso
Certains appareils fournissent une prise en charge dédiée à l’authentification unique (SSO) de Platform :
TempPass et TempPass promotionnel pour l’API REST temppass
Pour les implémentations TempPass et Promotionnel TempPass où l’utilisateur n’est pas tenu de saisir ses informations d’identification, l’authentification peut être mise en œuvre directement dans l’application de diffusion en continu.
Pour utiliser cette API, l’application de diffusion en continu doit s’assurer de l’unicité de l’identifiant de l’appareil, car il est utilisé pour identifier le jeton, avec les données supplémentaires facultatives.
