Présentation de l’API REST rest-api-overview
Vue d’ensemble over
L’API REST d’authentification Adobe Pass permet d’accéder directement aux services d’authentification et d’autorisation de TV Everywhere (TVE). Cette API prend en charge deux architectures principales : Serveur à serveur ou Périphériques connectés (par exemple, consoles de jeux, télévisions dynamiques, décodeurs, etc.). applications qui ne disposent pas de fonctionnalités de navigation web.
Mécanisme de ralentissement
L’API REST d’authentification Adobe Pass est régie par un mécanisme de limitation.
Serveur à serveur
Les solutions serveur à serveur impliquent des applications clientes de programmeur qui s’intègrent aux services de programmeur qui se connectent aux services d’authentification Adobe Pass pour les flux TVE. Cette approche déplace la plupart de l’implémentation de TVE du client vers le serveur où un seul module d’autorisation unifié peut être créé et géré. La principale responsabilité restante des applications clientes est la gestion d’un affichage web pour l’authentification des utilisateurs.
Périphériques connectés
Les applications Périphériques connectés communiquent directement avec l’authentification Adobe Pass via les API REST pour effectuer la configuration, l’enregistrement, les vérifications d’état d’authentification et les flux d’autorisation, tandis qu’un second écran (navigateur) est requis pour le flux d’authentification. Par conséquent, les SDK natifs ne sont pas utilisés.
Autres architectures
Outre les deux principales architectures basées sur les API REST, les solutions serveur à serveur et client direct pour les appareils intelligents, il existe d’autres architectures. L’architecture du SDK, qui utilise un composant client appelé Access Enabler fourni par l’authentification Adobe Pass aux programmeurs, est l’un des Principal de cette architecture. L’application utilise les API Access Enabler pour gérer le démarrage, l’authentification, l’autorisation et la déconnexion. Toute communication entre l’application du programmeur et les serveurs d’authentification Adobe Pass se fait via l’Access Enabler. Une version différente de Access Enabler est disponible pour les plateformes suivantes : JavaScript, iOS, tvOS, Android et FireTV.
Bien qu’il soit possible d’utiliser l’API REST directement sur les plateformes clientes qui prennent en charge les SDK natifs en dehors d’une solution serveur à serveur, cette approche n’est pas recommandée.
Avantages et inconvénients de l’API REST ProsAndCons
L’API REST d’authentification Adobe Pass a été créée pour fournir une solution TV Everywhere (TVE) pour les périphériques qui ne disposent pas de fonctionnalités de navigation web ni de stockage persistant. L’API REST prend en charge tous les flux d’authentification et d’autorisation, mais elle manque d’un composant SDK natif. Les SDK fournis et gérés par l’authentification Adobe Pass sont fournis avec des fonctionnalités prêtes à l’emploi qui implémentent des règles de fonctionnement qui, dans le cas de l’API REST, doivent être implémentées et gérées par les programmeurs. Dans le tableau des responsabilités du programmeur ci-dessous, nous décrivons les limites de l’API REST actuelle qui doivent être traitées par les programmeurs.
Avantages et inconvénients serveur à serveur par rapport aux avantages et aux inconvénients basés sur le client
Une architecture serveur à serveur permet de consolider la majeure partie de la logique liée à l’authentification et à l’autorisation en une seule unité logique ou implémentation. Cette approche a ses avantages et ses inconvénients. Les avantages incluent :
- Mise en oeuvre unique pour la logique métier d’authentification et d’autorisation.
- Évitez d’implémenter cette logique sur chaque plateforme prise en charge à l’aide de ces plateformes avec des outils natifs.
- La possibilité de mettre à jour les fonctionnalités sans avoir à mettre à jour les clients avec toutes les exigences associées (par exemple, les mises à jour de la boutique d’applications).
- Plus facilement étendez et personnalisez les fonctionnalités authN et authZ (par exemple, ajoutez D2C).
- Gestion directe du trafic associé pour un meilleur contrôle, une meilleure qualité et une meilleure surveillance.
Encore une fois, les icônes sont répertoriées dans les responsabilités du programmeur, mais incluent les éléments suivants :
- SSO doit être mis en oeuvre pour chaque client pour les plateformes sans SSO Platform.
- Si nécessaire, les programmeurs doivent implémenter une logique spécifique au MVPD.
- Toutes les plateformes qui utilisent l’API REST partagent une configuration unique qui régit les propriétés telles que les TTL d’authentification.
Périphériques connectés
Pour la plupart des appareils connectés, l’API REST doit être utilisée d’une manière ou d’une autre, car un SDK n’est pas disponible. L’appareil connecté utilise directement l’API REST ou s’intègre à une solution serveur à serveur qui utilise l’API REST.
Responsabilités du programmeur programmer-responsibilities
Les points suivants s’appliquent à la fois aux applications Serveur à Serveur et Appareil connecté.
-
Dans le cadre de notre nouvelle initiative Une API , nous prévoyons de corriger cette limitation et de pouvoir appliquer des règles par plateforme en fonction de l’identification de l’appareil.
-
Adobe continue de travailler avec toutes les principales plateformes pour mettre en oeuvre la connexion unique à Platform qui peut être utilisée avec notre API REST. Notre initiative d’une seule API offre une prise en charge SSO entre les applications implémentées à l’aide de SDK natifs et des applications implémentées à l’aide de l’API REST.
Configuration minimale requise pour les périphériques min_reqs
Pour utiliser l’API REST d’authentification Adobe Pass, les périphériques doivent satisfaire ou dépasser les exigences techniques minimales répertoriées dans la section API REST du document Plateforme d’authentification Adobe Pass / Exigences en matière d’appareils / outils.