FAQ sur l’API REST V2 rest-api-v2-faqs

FAQ sur la phase d’enregistrement

Reportez-vous à la documentation FAQ sur l’enregistrement client dynamique (DCR).

FAQ sur la phase de configuration

​1. Quel est l’objectif de la phase de configuration ? configuration-phase-faq1

La phase de configuration a pour but de fournir à l’application cliente la liste des fichiers MVPD auxquels elle est activement intégrée, ainsi que les détails de la configuration (par exemple, id, displayName, logoUrl, etc.) enregistrés par l’authentification Adobe Pass pour chaque MVPD.

La phase de configuration fait office d’étape préalable à la phase d’authentification lorsque l’application cliente doit demander à l’utilisateur de sélectionner son fournisseur de télévision.

​2. La phase de configuration est-elle obligatoire ? configuration-phase-faq2

La phase de configuration n’est pas obligatoire, l’application cliente ne doit récupérer la configuration que lorsque l’utilisateur doit sélectionner son MVPD pour s’authentifier ou s’authentifier à nouveau.

L’application cliente peut ignorer cette phase dans les scénarios suivants :

• L’utilisateur est déjà authentifié.
• L’utilisateur se voit proposer un accès temporaire par le biais de la fonctionnalité de base ou promotionnelle TempPass.
• L’authentification de l’utilisateur a expiré, mais l’application cliente a mis en cache le MVPD précédemment sélectionné en tant que choix motivé par l’expérience utilisateur, et invite simplement l’utilisateur à confirmer qu’il est toujours abonné à ce MVPD.

​3. Qu’est-ce qu’une configuration et combien de temps est-elle valide ? configuration-phase-faq3

La configuration est un terme défini dans la documentation Glossaire.

La configuration contient une liste de fichiers MVPD définis par les attributs suivants id, displayName, logoUrl, etc., qui peuvent être récupérés à partir du point d’entrée Configuration.

L’application cliente ne doit récupérer la configuration que lorsque l’utilisateur doit sélectionner son MVPD pour s’authentifier ou se réauthentifier.

L’application cliente peut utiliser la réponse de configuration pour présenter un sélecteur d’interface utilisateur avec les options MVPD disponibles chaque fois que l’utilisateur doit sélectionner son fournisseur de télévision.

L’application cliente doit stocker l’identifiant MVPD sélectionné par l’utilisateur, tel que spécifié par l’attribut id au niveau de la configuration MVPD, pour procéder aux phases d’authentification, de préautorisation, d’autorisation ou de déconnexion.

Pour plus d’informations, consultez la documentation Récupérer la configuration.

​4. L’application cliente doit-elle mettre en cache les informations de réponse de configuration dans un espace de stockage persistant ? configuration-phase-faq4

L’application cliente ne doit récupérer la configuration que lorsque l’utilisateur doit sélectionner son MVPD pour s’authentifier ou se réauthentifier.

L’application cliente doit mettre en cache les informations de réponse de configuration dans un espace de stockage mémoire afin d’éviter les requêtes inutiles et d’améliorer l’expérience utilisateur lorsque :

• L’utilisateur est déjà authentifié.
• L’utilisateur se voit proposer un accès temporaire par le biais de la fonctionnalité de base ou promotionnelle TempPass.
• L’authentification de l’utilisateur a expiré, mais l’application cliente a mis en cache le MVPD précédemment sélectionné en tant que choix motivé par l’expérience utilisateur, et invite simplement l’utilisateur à confirmer qu’il est toujours abonné à ce MVPD.

​5. L’application cliente peut-elle gérer sa propre liste de fichiers MVPD ? configuration-phase-faq5

L’application cliente peut gérer sa propre liste de fichiers MVPD, mais elle doit synchroniser les identifiants MVPD avec l’authentification Adobe Pass. Par conséquent, il est recommandé d’utiliser la configuration fournie par Authentification Adobe Pass pour vous assurer que la liste est à jour et précise.

L’application cliente recevrait une erreur de l’API REST d’authentification Adobe Pass V2 si l’identifiant MVPD fourni n’est pas valide ou si elle ne dispose pas d’une intégration active avec le fournisseur de services spécifié.

​6. L’application cliente peut-elle filtrer la liste des fichiers MVPD ? configuration-phase-faq6

L’application cliente peut filtrer la liste des MVPD fournie dans la réponse de configuration en implémentant un mécanisme personnalisé en fonction de sa propre logique commerciale et de ses exigences, telles que l’emplacement de l’utilisateur ou l’historique de la sélection précédente.

L’application cliente peut filtrer la liste des MVPD TempPass ou des MVPD dont l’intégration est toujours en cours de développement ou de test.

​7. Que se passe-t-il si l’intégration à un MVPD est désactivée et marquée comme inactive ? configuration-phase-faq7

Lorsque l’intégration à un MVPD est désactivée et marquée comme inactive, le MVPD est supprimé de la liste des MVPD fournie dans les autres réponses de configuration. Il faut tenir compte de deux conséquences importantes :

• Les utilisateurs non authentifiés de ce MVPD ne pourront plus terminer la phase d’authentification à l’aide de ce MVPD.
• Les utilisateurs authentifiés de ce MVPD ne pourront plus terminer les phases de préautorisation, d’autorisation ou de déconnexion à l’aide de ce MVPD.

L’application cliente recevrait une erreur de l’API REST d’authentification Adobe Pass V2 si l’utilisateur a sélectionné MVPD ne dispose plus d’une intégration active avec le fournisseur de services spécifié.

​8. Que se passe-t-il si l’intégration à un MVPD est activée à l’arrière et marquée comme active ? configuration-phase-faq8

Lorsque l’intégration à un MVPD est réactivée et marquée comme active, le MVPD est de nouveau inclus dans la liste des MVPD fournie dans les autres réponses de configuration. Il faut tenir compte de deux conséquences importantes :

• Les utilisateurs non authentifiés de ce MVPD pourront à nouveau terminer la phase d’authentification à l’aide de ce MVPD.
• Les utilisateurs authentifiés de ce MVPD pourront à nouveau terminer les phases de préautorisation, d’autorisation ou de déconnexion à l’aide de ce MVPD.

​9. Comment activer ou désactiver l’intégration à MVPD ? configuration-phase-faq9

Cette opération peut être effectuée via le tableau de bord Adobe Pass TVE Dashboard par l’un des administrateurs de votre organisation ou par un représentant Adobe Pass Authentication agissant en votre nom.

Pour plus d’informations, reportez-vous à la documentation du Guide d’utilisation des intégrations de tableaux de bord TVE.

FAQ sur la phase d’authentification

​1. Quel est l’objectif de la phase d’authentification ? authentication-phase-faq1

La phase d’authentification a pour but de permettre à l’application cliente de vérifier l’identité de l’utilisateur et d’obtenir des informations sur les métadonnées de l’utilisateur.

La phase d’authentification agit comme une étape préalable à la phase de préautorisation ou à la phase d’autorisation lorsque l’application cliente doit lire du contenu.

​2. La phase d’authentification est-elle obligatoire ? authentication-phase-faq2

La phase d’authentification est obligatoire, l’application cliente doit authentifier l’utilisateur lorsqu’elle ne dispose pas d’un profil valide dans l’authentification Adobe Pass.

L’application cliente peut ignorer cette phase dans les scénarios suivants :

• L’utilisateur est déjà authentifié et le profil est toujours valide.
• L’utilisateur se voit proposer un accès temporaire par le biais de la fonctionnalité de base ou promotionnelle TempPass.

La gestion des erreurs de l’application cliente nécessite de gérer les codes error (par exemple, authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated, etc.), qui indiquent que l’application cliente nécessite que l’utilisateur s’authentifie.

​3. Qu’est-ce qu’une session d’authentification et combien de temps est-elle valide ? authentication-phase-faq3

La session d’authentification est un terme défini dans la documentation Glossaire.

La session d’authentification stocke des informations sur le processus d’authentification lancé qui peuvent être récupérées à partir du point d’entrée Sessions.

La session d’authentification est valide pendant une période limitée et courte spécifiée au moment de l’émission par l’horodatage notAfter, indiquant le temps dont dispose l’utilisateur pour terminer le processus d’authentification avant de devoir redémarrer le flux.

L’application cliente peut utiliser la réponse de session d’authentification pour savoir comment procéder au processus d’authentification. Notez qu’il existe des cas où l’utilisateur n’est pas tenu de s’authentifier, par exemple lorsqu’il fournit un accès temporaire, un accès dégradé ou lorsqu’il est déjà authentifié.

Pour plus d’informations, consultez les documents suivants :

• Créer une API de session d’authentification
• API Reprendre la session d’authentification
• Flux d’authentification de base effectué dans l’application principale
• Flux d’authentification de base effectué dans l’application secondaire

​4. Qu’est-ce qu’un code d’authentification et combien de temps est-il valide ? authentication-phase-faq4

Le code d’authentification est un terme défini dans la documentation Glossaire.

Le code d’authentification stocke une valeur unique générée lorsqu’un utilisateur lance le processus d’authentification et identifie de manière unique la session d’authentification d’un utilisateur jusqu’à ce que le processus soit terminé ou jusqu’à l’expiration de la session d’authentification.

Le code d’authentification est valide pendant une période limitée et courte spécifiée au moment du lancement de la session d’authentification par l’horodatage notAfter, indiquant le temps dont dispose l’utilisateur pour terminer le processus d’authentification avant de devoir redémarrer le flux.

L’application cliente peut utiliser le code d’authentification pour vérifier si l’utilisateur a terminé l’authentification avec succès et récupérer les informations de profil de l’utilisateur, généralement par le biais d’un mécanisme d’interrogation.

L’application cliente peut également utiliser le code d’authentification pour permettre à l’utilisateur ou à l’utilisatrice de terminer ou de reprendre le processus d’authentification sur le même appareil ou sur un second (écran), étant donné que la session d’authentification n’a pas expiré.

Pour plus d’informations, consultez les documents suivants :

• Créer une API de session d’authentification
• API Reprendre la session d’authentification
• Flux d’authentification de base effectué dans l’application principale
• Flux d’authentification de base effectué dans l’application secondaire

​5. Comment l’application cliente peut-elle savoir si l’utilisateur a saisi un code d’authentification valide et si la session d’authentification n’a pas encore expiré ? authentication-phase-faq5

L’application cliente peut valider le code d’authentification saisi par l’utilisateur dans une application secondaire (écran) en envoyant une requête à l’un des points d’entrée Sessions chargés de reprendre la session d’authentification ou de récupérer les informations de session d’authentification associées au code d’authentification.

L’application cliente recevait une erreur si le code d’authentification fourni était mal saisi ou si la session d’authentification arrivait à expiration.

Pour plus d’informations, reportez-vous aux documents Reprendre la session d’authentification et Récupérer la session d’authentification.

​6. Comment l’application cliente peut-elle savoir si l’utilisateur est déjà authentifié ? authentication-phase-faq6

L’application cliente peut interroger l’un des points d’entrée suivants capable de vérifier si un utilisateur est déjà authentifié et de renvoyer des informations de profil :

• API du point d’entrée des profils
• Point d’entrée des profils pour une API MVPD spécifique
• Point d’entrée des profils pour une API de code spécifique (authentification)

Pour plus d’informations, reportez-vous aux documents suivants :

• Flux de profils de base exécuté dans l’application principale
• Flux de profils de base exécuté dans l’application secondaire

​7. Qu’est-ce qu’un profil et combien de temps est-il valide ? authentication-phase-faq7

Le profil est un terme défini dans la documentation Glossaire.

Le profil stocke des informations sur la validité d’authentification de l’utilisateur, des informations de métadonnées et bien d’autres informations qui peuvent être récupérées à partir du point d’entrée des profils.

L’application cliente peut utiliser le profil pour connaître le statut d’authentification de l’utilisateur, accéder aux informations de métadonnées de l’utilisateur, trouver la méthode utilisée pour s’authentifier ou l’entité utilisée pour fournir l’identité.

Pour plus d’informations, reportez-vous aux documents suivants :

• API du point d’entrée des profils
• Point d’entrée des profils pour une API MVPD spécifique
• Point d’entrée des profils pour une API de code spécifique (authentification)
• Flux de profils de base exécuté dans l’application principale
• Flux de profils de base exécuté dans l’application secondaire

Le profil est valide pendant une période limitée spécifiée lors de l’interrogation de l’horodatage notAfter, indiquant la durée pendant laquelle l’utilisateur dispose d’une authentification valide avant de devoir repasser par la phase d’authentification.

Cette période limitée appelée authentification (authN) TTL peut être affichée et modifiée via le tableau de bord Adobe Pass TVE par l’un des administrateurs de votre organisation ou par un représentant Adobe Pass Authentication agissant en votre nom.

Pour plus d’informations, reportez-vous à la documentation du Guide d’utilisation des intégrations de tableaux de bord TVE.

​8. L’application cliente doit-elle mettre en cache les informations de profil de l’utilisateur dans un espace de stockage persistant ? authentication-phase-faq8

L’application cliente doit mettre en cache certaines parties des informations de profil de l’utilisateur dans un stockage persistant afin d’éviter les requêtes inutiles et d’améliorer l’expérience utilisateur, en tenant compte des aspects suivants :

table 0-row-2 1-row-2 2-row-2 3-row-2
Attribut	Expérience utilisateur
mvpd	L’application cliente peut l’utiliser pour suivre le fournisseur de télévision sélectionné par l’utilisateur et continuer à l’utiliser pendant les phases de préautorisation ou d’autorisation. À l’expiration du profil utilisateur actuel, l’application cliente peut utiliser la sélection MVPD mémorisée et demander à l’utilisateur de confirmer.
attributes	L’application cliente peut l’utiliser pour personnaliser l’expérience utilisateur en fonction de différentes clés métadonnées utilisateur (par exemple, zip, maxRating, etc.). Les métadonnées utilisateur sont disponibles une fois le flux d’authentification terminé. Par conséquent, l’application cliente n’a pas besoin d’interroger un point d’entrée distinct pour récupérer les informations métadonnées utilisateur, car elles sont déjà incluses dans les informations de profil. Certains attributs de métadonnées peuvent être mis à jour au cours du flux d’autorisation, selon le MVPD et l’attribut de métadonnées spécifique. Par conséquent, l’application cliente peut avoir besoin d’interroger à nouveau les API Profiles pour récupérer les dernières métadonnées de l’utilisateur.
notAfter	L’application cliente peut l’utiliser pour suivre la date d’expiration du profil utilisateur. La gestion des erreurs de l’application cliente nécessite de gérer les codes error (par exemple, authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated, etc.), ce qui indique que l’application cliente nécessite que l’utilisateur s’authentifie.

​9. L’application cliente peut-elle étendre le profil de l’utilisateur sans nécessiter de réauthentification ? authentication-phase-faq9

Non.

Le profil utilisateur ne peut pas être étendu au-delà de sa validité sans interaction utilisateur, car son expiration est déterminée par la durée de vie d’authentification établie avec les fichiers MVPD.

Par conséquent, l’application cliente doit inviter l’utilisateur à s’authentifier à nouveau et à interagir avec la page de connexion de MVPD pour actualiser son profil sur notre système.

Toutefois, pour les fichiers MVPD qui prennent en charge l’authentification à domicile (HBA), l’utilisateur n’est pas tenu de saisir les informations d’identification.

​10. Quels sont les cas d’utilisation de chaque point d’entrée de profil disponible ? authentication-phase-faq10

Les points d’entrée de profils de base sont conçus pour permettre à l’application cliente de connaître le statut d’authentification de l’utilisateur, d’accéder aux informations de métadonnées de l’utilisateur, de trouver la méthode utilisée pour s’authentifier ou l’entité utilisée pour fournir l’identité.

Chaque point d’entrée correspond à un cas d’utilisation spécifique, comme suit :

table 0-row-3 1-row-3 2-row-3 3-row-3
API	Description	Cas d’utilisation
API du point d’entrée des profils	Récupérez tous les profils utilisateur.	L’utilisateur ouvre l’application cliente pour la première fois Dans ce scénario, l’application cliente ne dispose pas de l’identifiant MVPD sélectionné par l’utilisateur mis en cache dans le stockage persistant. Par conséquent, il envoie une seule demande pour récupérer tous les profils utilisateur disponibles.
Point d’entrée des profils pour une API MVPD spécifique	Récupérez le profil utilisateur associé à un MVPD spécifique.	L’utilisateur revient à l’application cliente après s’être authentifié lors d’une visite précédente Dans ce cas, l’application cliente doit avoir l’identifiant MVPD de l’utilisateur précédemment sélectionné mis en cache dans le stockage persistant. Par conséquent, il envoie une seule demande pour récupérer le profil de l’utilisateur pour ce MVPD spécifique.
Point d’entrée des profils pour une API de code (d’authentification) spécifique	Récupérez le profil utilisateur associé à un code d’authentification spécifique.	L’utilisateur lance le processus d’authentification Dans ce scénario, l’application cliente doit déterminer si l’utilisateur a terminé l’authentification avec succès et récupérer ses informations de profil. Par conséquent, il lance un mécanisme d’interrogation pour récupérer le profil de l’utilisateur associé au code d’authentification.

Pour plus d’informations, reportez-vous aux documents Flux de profils de base exécuté dans l’application principale et Flux de profils de base exécuté dans l’application secondaire.

Le point d’entrée de l’authentification unique des profils a un autre objectif. Il permet à l’application cliente de créer un profil utilisateur à l’aide de la réponse d’authentification du partenaire et de le récupérer en une seule opération unique.

table 0-row-3 1-row-3
API	Description	Cas d’utilisation
API du point d’entrée de l’authentification unique des profils	Créez et récupérez un profil utilisateur à l’aide de la réponse d’authentification du partenaire.	L’utilisateur autorise l’application à utiliser l’authentification unique du partenaire pour s’authentifier Dans ce scénario, l’application cliente doit créer un profil utilisateur après avoir reçu la réponse d’authentification du partenaire et la récupérer en une seule opération unique.

Pour toute requête ultérieure, les points d’entrée Profils de base doivent être utilisés pour déterminer le statut d’authentification de l’utilisateur, accéder aux informations de métadonnées de l’utilisateur, trouver la méthode utilisée pour l’authentification ou l’entité utilisée pour fournir l’identité.

Pour plus d’informations, reportez-vous aux documents Authentification unique à l’aide des flux de partenaireet Cookbook SSO d’Apple (API REST V2).

​11. Que doit faire l’application cliente si l’utilisateur dispose de plusieurs profils MVPD ? authentication-phase-faq11

La décision de prendre en charge plusieurs profils dépend des exigences commerciales de l’application cliente.

La plupart des utilisateurs n’auront qu’un seul profil. Cependant, dans les cas où il existe plusieurs profils (comme décrit ci-dessous), l’application cliente est chargée de déterminer la meilleure expérience utilisateur pour la sélection des profils.

L’application cliente peut choisir d’inviter l’utilisateur à sélectionner le profil MVPD souhaité ou d’effectuer la sélection automatiquement, par exemple en choisissant le premier profil utilisateur dans la réponse ou celui dont la période de validité est la plus longue.

L’API REST v2 prend en charge plusieurs profils pour s’adapter aux éléments suivants :

• Les utilisateurs qui peuvent avoir à choisir entre un profil MVPD standard et un profil obtenu par authentification unique (SSO).
• Les utilisateurs se voient proposer un accès temporaire sans avoir à se déconnecter de leur MVPD standard.
• Utilisateurs disposant d’un abonnement MVPD associé à des services de type « Direct-to-Consumer » (DTC).
• Utilisateurs disposant de plusieurs abonnements MVPD.

​12. Que se passe-t-il lorsque les profils utilisateur expirent ? authentication-phase-faq12

Lorsque les profils utilisateur expirent, ils ne sont plus inclus dans la réponse du point d’entrée Profils .

Si le point d’entrée Profils renvoie une réponse de mappage de profils vide, l’application cliente doit créer une session d’authentification et inviter l’utilisateur à s’authentifier à nouveau.

Pour plus d’informations, consultez la documentation Créer une API de session d’authentification.

​13. À quel moment les profils utilisateur deviennent-ils non valides ? authentication-phase-faq13

Les profils utilisateur ne sont plus valides dans les scénarios suivants :

• Lorsque la TTL d’authentification expire, comme indiqué par la date et l’heure notAfter dans la réponse de point d’entrée des profils .
• Lorsque l’application cliente modifie la valeur de l’en-tête AP-Device-Identifier.
• Lorsque l’application cliente met à jour les informations d’identification du client utilisées pour récupérer la valeur de l’en-tête Authorization.
• Lorsque l’application cliente révoque ou met à jour l’instruction logicielle utilisée pour obtenir les informations d’identification du client.

​14. Quand l’application cliente doit-elle démarrer le mécanisme d’interrogation ? authentication-phase-faq14

Pour garantir l’efficacité et éviter les requêtes inutiles, l’application cliente doit démarrer le mécanisme d’interrogation dans les conditions suivantes :

Authentification effectuée dans l’application principale (écran)

L’application principale (de diffusion en continu) doit commencer à interroger l’utilisateur ou l’utilisatrice lorsqu’il ou elle atteint la page de destination finale, une fois que le composant de navigateur charge l’URL spécifiée pour le paramètre redirectUrl dans la requête de point d’entrée Sessions.

Authentification effectuée dans une application secondaire (écran)

L’application principale (de diffusion en continu) doit commencer à interroger l’utilisateur dès qu’il initie le processus d’authentification, juste après avoir reçu la réponse de point d’entrée Sessions et affiché le code d’authentification à l’utilisateur.

​15. Quand l’application cliente doit-elle arrêter le mécanisme d’interrogation ? authentication-phase-faq15

Pour garantir l’efficacité et éviter les requêtes inutiles, l’application cliente doit arrêter le mécanisme d’interrogation dans les conditions suivantes :

Authentification réussie

Les informations de profil de l’utilisateur sont récupérées avec succès, confirmant leur statut d’authentification. À ce stade, l’interrogation n’est plus nécessaire.

Session d’authentification et expiration du code

La session d’authentification et le code expirent, comme indiqué par l’horodatage notAfter (par exemple, 30 minutes) dans la réponse de point d’entrée Sessions. Si cela se produit, l’utilisateur ou l’utilisatrice doit redémarrer le processus d’authentification et l’interrogation à l’aide du code d’authentification précédent doit être arrêtée immédiatement.

Nouveau code d’authentification généré

Si l’utilisateur demande un nouveau code d’authentification sur l’appareil principal (écran), la session existante n’est plus valide et l’interrogation à l’aide du code d’authentification précédent doit être arrêtée immédiatement.

​16. Quel intervalle entre les appels l’application cliente doit-elle utiliser pour le mécanisme d’interrogation ? authentication-phase-faq16

Pour garantir l’efficacité et éviter les requêtes inutiles, l’application cliente doit configurer la fréquence du mécanisme d’interrogation dans les conditions suivantes :

table 0-row-2 1-row-2
Authentification effectuée dans l’application principale (écran)	Authentification effectuée dans une application secondaire (écran)
L’application principale (de diffusion en continu) doit effectuer une interrogation toutes les 3 à 5 secondes ou plus.	L’application principale (de diffusion en continu) doit effectuer une interrogation toutes les 3 à 5 secondes ou plus.

​17. Quel est le nombre maximal de requêtes d’interrogation que l’application cliente peut envoyer ? authentication-phase-faq17

L’application cliente doit respecter les limites actuelles définies par le mécanisme de limitation d’authentification d’Adobe Pass.

La gestion des erreurs de l’application cliente doit être en mesure de gérer le code d’erreur 429 Too Many Requests, qui indique que l’application cliente a dépassé le nombre maximal de requêtes autorisées.

Pour plus d’informations, consultez la documentation Mécanisme de limitation.

​18. Comment l’application cliente peut-elle obtenir les informations sur les métadonnées de l’utilisateur ? authentication-phase-faq18

L’application cliente peut interroger l’un des points d’entrée suivants capables de renvoyer des informations métadonnées de l’utilisateur dans le cadre des informations de profil :

• API du point d’entrée des profils
• Point d’entrée des profils pour une API MVPD spécifique
• Point d’entrée des profils pour une API de code spécifique (authentification)

Les métadonnées de l’utilisateur sont disponibles une fois le flux d’authentification terminé. Par conséquent, l’application cliente n’a pas besoin d’interroger un point d’entrée distinct pour récupérer les informations métadonnées de l’utilisateur, car elles sont déjà incluses dans les informations de profil.

Pour plus d’informations, reportez-vous aux documents suivants :

• Flux de profils de base exécuté dans l’application principale
• Flux de profils de base exécuté dans l’application secondaire

Certains attributs de métadonnées peuvent être mis à jour pendant le flux d’autorisation, selon le MVPD et l’attribut de métadonnées spécifique. Par conséquent, l’application cliente peut avoir besoin d’interroger à nouveau les API ci-dessus pour récupérer les dernières métadonnées de l’utilisateur.

​19. Comment l’application cliente doit-elle gérer l’accès dégradé ? authentication-phase-faq19

La fonctionnalité de dégradation permet à l’application cliente de conserver une expérience de diffusion en continu transparente pour les utilisateurs et utilisatrices, même lorsque leurs services d’authentification ou d’autorisation MVPD rencontrent des problèmes.

En résumé, cela peut garantir un accès ininterrompu au contenu malgré les perturbations temporaires des services de MVPD.

Étant donné que votre entreprise a l’intention d’utiliser la fonctionnalité de dégradation Premium, l’application cliente doit gérer les flux d’accès dégradés, qui décrivent le comportement des points d’entrée de l’API REST v2 dans de tels scénarios.

Pour plus d'informations, consultez la documentation Flux d'accès dégradés.

​20. Comment l’application cliente doit-elle gérer l’accès temporaire ? authentication-phase-faq20

La fonction TempPass permet à l'application cliente de fournir un accès temporaire à l'utilisateur.

En résumé, cela peut intéresser les utilisateurs et les utilisatrices en leur fournissant un accès limité dans le temps au contenu ou à un nombre prédéfini de titres VOD pendant une période spécifiée.

Étant donné que votre entreprise a l’intention d’utiliser la fonctionnalité TempPass Premium, l’application cliente doit gérer les flux d’accès temporaires, qui décrivent le comportement des points d’entrée de l’API REST v2 dans de tels scénarios.

Dans les versions précédentes de l’API, l’application cliente devait déconnecter un utilisateur authentifié avec son MVPD standard pour offrir un accès temporaire.

Avec l’API REST v2, l’application cliente peut basculer facilement entre un MVPD standard et un MVPD TempPass lors de l’autorisation d’un flux, éliminant ainsi la nécessité pour l’utilisateur d’être déconnecté.

Pour plus d'informations, consultez la documentation Flux d'accès temporaires.

​21. Comment l’application cliente doit-elle gérer l’accès avec authentification unique sur plusieurs appareils ? authentication-phase-faq21

L’API REST v2 peut activer l’authentification unique entre appareils si l’application cliente fournit un identifiant utilisateur unique cohérent entre les appareils.

Cet identifiant, appelé jeton de service, doit être généré par l’application cliente par l’implémentation ou l’intégration d’un service d’identités externe de votre choix.

Pour plus d’informations, reportez-vous à la documentation Authentification unique à l’aide des flux de jeton de service.

FAQ sur la phase de préautorisation

​1. Quel est l’objectif de la phase de préautorisation ? preauthorization-phase-faq1

L’objectif de la phase de préautorisation est de permettre à l’application cliente de présenter un sous-ensemble de ressources de son catalogue auquel l’utilisateur ou l’utilisatrice serait autorisé à accéder.

La phase de préautorisation peut améliorer l’expérience de l’utilisateur lorsqu’il ouvre l’application cliente pour la première fois ou accède à une nouvelle section.

​2. La phase de préautorisation est-elle obligatoire ? preauthorization-phase-faq2

La phase de préautorisation n’est pas obligatoire, l’application cliente peut ignorer cette phase si elle souhaite présenter un catalogue de ressources sans les filtrer au préalable en fonction des droits de l’utilisateur.

​3. Qu’est-ce qu’une décision de préautorisation ? preauthorization-phase-faq3

La préautorisation est un terme défini dans la documentation Glossaire, tandis que le terme de décision se trouve également dans le Glossaire.

La décision de préautorisation stocke des informations sur le résultat de la recherche du processus de préautorisation MVPD qui peuvent être récupérées à partir du point d’entrée de préautorisation des décisions.

L’application cliente peut utiliser les décisions de préautorisation pour présenter un sous-ensemble de ressources auxquelles les décisions (informatives) du fournisseur de télévision permettraient à l’utilisateur d’accéder.

Pour plus d’informations, reportez-vous aux documents suivants :

• Récupération de l’API de décisions de préautorisation
• Flux de préautorisation de base exécuté dans l’application principale

​4. L’application cliente doit-elle mettre en cache les décisions de préautorisation dans un stockage persistant ? preauthorization-phase-faq4

L’application cliente n’est pas nécessaire pour stocker les décisions de préautorisation dans un stockage persistant. Cependant, il est recommandé de mettre en cache les décisions d’autorisation en mémoire pour améliorer l’expérience de l’utilisateur. Cela permet d’éviter les appels inutiles au point d’entrée de préautorisation des décisions pour les ressources qui ont déjà été préautorisées, ce qui réduit la latence et améliore les performances.

​5. Comment l’application cliente peut-elle déterminer pourquoi une décision de préautorisation a été refusée ? preauthorization-phase-faq5

L’application cliente peut déterminer la raison d’un refus de décision de préautorisation en examinant le code d’erreur et le messageinclus dans la réponse à partir du point d’entrée de préautorisation des décisions . Ces détails fournissent à insight la raison spécifique pour laquelle la demande de préautorisation a été refusée, ce qui permet d’informer l’expérience utilisateur ou de déclencher toute gestion nécessaire dans l’application.

Assurez-vous que tout mécanisme de reprise implémenté pour récupérer les décisions de préautorisation ne génère pas de boucle sans fin si la décision de préautorisation est refusée.

Envisagez de limiter les reprises à un nombre raisonnable et de gérer les refus de manière élégante en présentant des commentaires clairs à l’utilisateur.

​6. Pourquoi un jeton de média est-il manquant dans la décision de préautorisation ? preauthorization-phase-faq6

Il manque un jeton multimédia dans la décision de préautorisation, car la phase de préautorisation ne doit pas être utilisée pour lire les ressources, car c’est l’objectif de la phase d’autorisation.

​7. La phase d’autorisation peut-elle être ignorée si une décision de préautorisation existe déjà ? preauthorization-phase-faq7

Non.

La phase d’autorisation ne peut pas être ignorée même si une décision de préautorisation est disponible. Les décisions de préautorisation sont uniquement informatives et n’accordent pas de droits de lecture réels. La phase de préautorisation est destinée à fournir des conseils précoces, mais la phase d’autorisation est toujours requise avant la lecture de tout contenu.

​8. Qu’est-ce qu’une ressource et quels formats sont pris en charge ? preauthorization-phase-faq8

La ressource est un terme défini dans la documentation Glossaire.

La ressource est un identifiant unique convenu avec les MVPD et associé à un contenu que l’application cliente peut diffuser.

L’identifiant unique de la ressource peut avoir deux formats :

• Format de chaîne simple, tel qu’un identifiant unique pour un canal (marque).
• Format RSS (Media RSS) contenant des informations supplémentaires telles que le titre, les évaluations et les métadonnées de contrôle parental.

Pour plus d’informations, consultez la documentation Ressources protégées.

​9. Pour combien de ressources l’application cliente peut-elle obtenir une décision de préautorisation à la fois ? preauthorization-phase-faq9

L’application cliente peut obtenir une décision de préautorisation pour un nombre limité de ressources dans une seule requête API, généralement jusqu’à 5, en raison des conditions imposées par les MVPD.

Ce nombre maximal de ressources peut être consulté et modifié après accord avec les MVPD via le tableau de bord Adobe Pass TVE Dashboard par l’un des administrateurs de votre entreprise ou par un représentant Adobe Pass Authentication agissant en votre nom.

Pour plus d’informations, reportez-vous à la documentation du Guide d’utilisation des intégrations de tableaux de bord TVE.

FAQ sur la phase d’autorisation

​1. Quel est l’objectif de la phase d’autorisation ? authorization-phase-faq1

La phase d’autorisation a pour but de permettre à l’application cliente de lire les ressources demandées par l’utilisateur ou l’utilisatrice après validation de ses droits avec MVPD.

​2. La phase d’autorisation est-elle obligatoire ? authorization-phase-faq2

La phase d’autorisation est obligatoire, l’application cliente ne peut pas ignorer cette phase si elle souhaite lire les ressources demandées par l’utilisateur ou l’utilisatrice, car elle doit vérifier auprès du MVPD que l’utilisateur ou l’utilisatrice a le droit de lire avant de libérer le flux.

​3. Qu'est-ce qu'une décision d'autorisation et quelle est sa durée de validité ? authorization-phase-faq3

L’autorisation est un terme défini dans la documentation Glossaire, tandis que le terme de décision se trouve également dans le Glossaire.

La décision d’autorisation stocke des informations sur le résultat de la recherche du processus d’autorisation MVPD qui peuvent être récupérées à partir du point d’entrée Autoriser les décisions .

L’application cliente peut utiliser la décision d’autorisation contenant un jeton multimédia pour lire le flux de ressources au cas où la décision Fournisseur de télévision (faisant autorité) permettrait à l’utilisateur d’y accéder.

Pour plus d’informations, reportez-vous aux documents suivants :

• Récupérer l’API des décisions d’autorisation
• Flux d’autorisation de base exécuté dans l’application principale

La décision d’autorisation est valide pendant une période limitée et courte spécifiée au moment de l’émission, indiquant la durée pendant laquelle elle sera mise en cache par l’authentification Adobe Pass avant de devoir réitérer la requête au MVPD.

Cette période limitée appelée autorisation (authZ) TTL peut être consultée et modifiée via le tableau de bord Adobe Pass TVE par l’un des administrateurs de votre organisation ou par un représentant Adobe Pass Authentication agissant en votre nom.

Pour plus d’informations, reportez-vous à la documentation du Guide d’utilisation des intégrations de tableaux de bord TVE.

​4. L’application cliente doit-elle mettre en cache les décisions d’autorisation dans un stockage persistant ? authorization-phase-faq4

L’application cliente n’est pas nécessaire pour stocker les décisions d’autorisation dans un stockage persistant.

​5. Comment l’application cliente peut-elle déterminer pourquoi une décision d’autorisation a été refusée ? authorization-phase-faq5

L’application cliente peut déterminer la raison d’un refus d’autorisation en examinant le code d’erreur et le messageinclus dans la réponse à partir du point d’entrée Autoriser les décisions . Ces détails fournissent à insight la raison spécifique pour laquelle la demande d’autorisation a été refusée, ce qui permet d’informer l’expérience utilisateur ou de déclencher toute gestion nécessaire dans l’application.

Assurez-vous que tout mécanisme de reprise implémenté pour récupérer les décisions d’autorisation ne génère pas de boucle sans fin si la décision d’autorisation est refusée.

Envisagez de limiter les reprises à un nombre raisonnable et de gérer les refus de manière élégante en présentant des commentaires clairs à l’utilisateur.

​6. Qu’est-ce qu’un jeton multimédia et combien de temps est-il valide ? authorization-phase-faq6

Le jeton de média est un terme défini dans la documentation Glossaire.

Le jeton de média se compose d’une chaîne signée envoyée en texte clair qui peut être récupérée à partir du point d’entrée Autoriser les décisions .

Pour plus d’informations, consultez la documentation du Vérificateur de jeton multimédia.

Le jeton de média est valide pendant une période limitée et courte spécifiée au moment de l’émission, indiquant le délai avant lequel il doit être vérifié et utilisé par l’application cliente.

L’application cliente peut utiliser le jeton multimédia pour lire un flux de ressources au cas où la décision du fournisseur de télévision (faisant autorité) permettrait à l’utilisateur d’y accéder.

Pour plus d’informations, reportez-vous aux documents suivants :

• Récupérer l’API des décisions d’autorisation
• Flux d’autorisation de base exécuté dans l’application principale

​7. L’application cliente doit-elle valider le jeton de média avant de lire le flux de ressources ? authorization-phase-faq7

Oui.

L’application cliente doit valider le jeton de média avant de commencer la lecture du flux de ressources. Cette validation doit être effectuée à l’aide du Vérificateur de jeton multimédia. En vérifiant le serializedToken du token renvoyé, l’application cliente empêche tout accès non autorisé, tel que l’extraction de flux, et garantit que seuls les utilisateurs correctement autorisés peuvent lire le contenu.

​8. L’application cliente doit-elle actualiser un jeton de média expiré pendant la lecture ? authorization-phase-faq8

Non.

L’application cliente n’est pas tenue d’actualiser un jeton de média expiré pendant que le flux est en cours de lecture. Si le jeton de média expire pendant la lecture, le flux doit pouvoir continuer sans interruption. Cependant, le client doit demander une nouvelle décision d’autorisation et obtenir un nouveau jeton de média la prochaine fois que l’utilisateur tente de lire une ressource.

​9. À quoi sert chaque attribut d’horodatage dans la décision d’autorisation ? authorization-phase-faq9

La décision d’autorisation comprend plusieurs attributs d’horodatage qui fournissent un contexte essentiel sur la période de validité de l’autorisation elle-même et du jeton de média associé. Ces horodatages ont des fins différentes, selon qu’ils se rapportent à la décision d’autorisation ou au jeton multimédia.

Horodatages Au Niveau De La Décision

Ces dates et heures décrivent la période de validité de la décision d’autorisation globale :

table 0-row-3 1-row-3 2-row-3
Attribut	Description	Notes
notBefore	Heure en millisecondes à laquelle la décision d’autorisation a été émise.	Ceci marque le début de la fenêtre de validité de l’autorisation.
notAfter	Heure en millisecondes à laquelle la décision d’autorisation expire.	La durée de vie (TTL) de l’autorisation déterminedurée pendant laquelle l’autorisation reste valide avant d’exiger une nouvelle autorisation. Cette TTL est négociée avec les représentants de MVPD.

Horodatages au niveau des jetons

Ces horodatages décrivent la période de validité du jeton multimédia lié à la décision d’autorisation :

table 0-row-3 1-row-3 2-row-3
Attribut	Description	Notes
notBefore	Heure en millisecondes d’émission du jeton multimédia.	Cela marque le moment où le jeton devient valide pour la lecture.
notAfter	Heure en millisecondes à laquelle le jeton de média expire.	Les jetons multimédias ont une durée de vie délibérément courte (généralement 7 minutes) afin de minimiser les risques d’utilisation abusive et de tenir compte des différences d’horloge potentielles entre le serveur de génération de jetons et le serveur de vérification des jetons.

​10. Qu’est-ce qu’une ressource et quels formats sont pris en charge ? authorization-phase-faq10

La ressource est un terme défini dans la documentation Glossaire.

La ressource est un identifiant unique convenu avec les MVPD et associé à un contenu que l’application cliente peut diffuser.

L’identifiant unique de la ressource peut avoir deux formats :

• Format de chaîne simple, tel qu’un identifiant unique pour un canal (marque).
• Format RSS (Media RSS) contenant des informations supplémentaires telles que le titre, les évaluations et les métadonnées de contrôle parental.

Pour plus d’informations, consultez la documentation Ressources protégées.

​11. Pour combien de ressources la demande du client peut-elle obtenir une décision d’autorisation à la fois ? authorization-phase-faq11

L’application cliente peut obtenir une décision d’autorisation pour un nombre limité de ressources dans une seule requête API, généralement jusqu’à 1, en raison des conditions imposées par les MVPD.

FAQ sur la phase de déconnexion

​1. Quel est l’objectif de la phase de déconnexion ? logout-phase-faq1

L’objectif de la phase de déconnexion est de permettre à l’application cliente de mettre fin au profil authentifié de l’utilisateur dans l’authentification Adobe Pass à la demande de l’utilisateur.

​2. La phase de déconnexion est-elle obligatoire ? logout-phase-faq2

La phase de déconnexion est obligatoire, l’application cliente doit permettre à l’utilisateur de se déconnecter.

FAQ sur les en-têtes

​1. Comment calculer la valeur de l’en-tête d’autorisation ? headers-faq1

note important
IMPORTANT
Si l’application cliente migre de l’API REST V1 vers l’API REST V2, elle peut continuer à utiliser la même méthode pour obtenir la valeur du jeton d’accès Bearer que précédemment.

L’en-tête de requête Authorization contient le jeton d’accès Bearer requis par l’application cliente pour accéder aux API protégées d’Adobe Pass.

La valeur de l’en-tête Autorisation doit être obtenue à partir de l’authentification Adobe Pass pendant la phase d’enregistrement.

Pour plus d’informations, reportez-vous aux documents suivants :

• Présentation de l’enregistrement client dynamique
• API de récupération des informations d’identification du client
• Récupérer l’API du jeton d’accès
• Flux d’enregistrement client dynamique

​2. Comment calculer la valeur de l’en-tête AP-Device-Identifier ? headers-faq2

note important
IMPORTANT
Si l’application cliente migre de l’API REST V1 vers l’API REST V2, elle peut continuer à utiliser la même méthode pour calculer la valeur de l’identifiant de l’appareil que précédemment.

L’en-tête de requête AP-Device-Identifier contient l’identifiant de l’appareil de diffusion en continu tel qu’il a été créé par l’application cliente.

La documentation de l’en-tête AP-Device-Identifier fournit des exemples pour les principales plateformes sur la manière de calculer la valeur, mais l’application cliente peut choisir d’utiliser une méthode différente en fonction de sa propre logique commerciale et de ses propres exigences.

​3. Comment calculer la valeur de l’en-tête X-Device-Info ? headers-faq3

note important
IMPORTANT
Si l’application cliente migre de l’API REST V1 vers l’API REST V2, elle peut continuer à utiliser la même méthode pour calculer la valeur des informations sur l’appareil que précédemment.

L’en-tête de requête X-Device-Info contient les informations client (appareil, connexion et application) liées à l’appareil de diffusion en continu actuel et est utilisé pour déterminer les règles spécifiques à la plateforme que les MVPD peuvent appliquer.

La documentation de l’en-tête X-Device-Info fournit des exemples pour les principales plateformes sur la manière de calculer la valeur, mais l’application cliente peut choisir d’utiliser une autre méthode en fonction de sa propre logique commerciale et de ses propres exigences.

Si l’en-tête X-Device-Info est manquant ou contient des valeurs incorrectes, la requête peut être classée comme provenant d’une plateforme unknown.

Cela peut entraîner le traitement de la requête comme non sécurisée et soumise à des règles plus restrictives, telles que des TTL d’authentification plus courtes. De plus, certains champs, comme le connectionIp et le connectionPort de l'appareil de diffusion en continu, sont obligatoires pour des fonctions comme l'authentification de base d'accueil de Spectrum.

Même lorsque la requête provient d’un serveur pour le compte d’un appareil, la valeur de l’en-tête X-Device-Info doit refléter les informations réelles de l’appareil de diffusion en continu.

Questions fréquentes diverses

​1. Puis-je explorer les requêtes et réponses de l’API REST V2 et tester l’API ? misc-faq1

Oui.

Vous pouvez explorer l’API REST V2 via notre site web Adobe Developer dédié. Le site Web d’Adobe Developer offre un accès illimité aux éléments suivants :

• API DCR
• API REST V2

Pour interagir avec API REST V2, vous devez inclure l’en-tête Authorization avec un jeton d’accès Bearer obtenu via l’API DCR.

Pour utiliser l’API DCR, une instruction logicielle avec la portée API REST V2 est requise. Pour plus d’informations, consultez le document FAQ sur l’enregistrement client dynamique (DCR).

​2. Puis-je explorer les requêtes et réponses de l’API REST V2 à l’aide d’un outil de développement d’API avec prise en charge d’OpenAPI ? misc-faq2

Oui.

Vous pouvez télécharger les fichiers de spécification OpenAPI pour l’API DCR et l’API REST V2 à partir du site web Adobe Developer.

Pour télécharger les fichiers de spécification OpenAPI, cliquez sur les boutons de téléchargement pour enregistrer les fichiers suivants sur votre ordinateur local :

• JSON DE L’API DCR
• JSON DE L’API REST V2

Vous pouvez ensuite importer ces fichiers dans votre outil de développement d’API préféré pour explorer les requêtes et réponses de l’API REST V2 et tester l’API.

​3. Puis-je toujours utiliser l’outil de test d’API existant hébergé sur https://sp.auth-staging.adobe.com/apitest/api.html ? misc-faq3

Non.

Les applications clientes qui migrent vers l’API REST V2 doivent utiliser le nouvel outil de test hébergé sur https://developer.adobe.com/adobe-pass/. Le site Web d’Adobe Developer offre un accès illimité aux éléments suivants :

• API DCR
• API REST V2

Pour interagir avec API REST V2, vous devez inclure l’en-tête Authorization avec un jeton d’accès Bearer obtenu via l’API DCR.

Pour utiliser l’API DCR, une instruction logicielle avec la portée API REST V2 est requise. Pour plus d’informations, consultez le document FAQ sur l’enregistrement client dynamique (DCR).

Questions fréquentes générales sur la migration

​1. Dois-je déployer une nouvelle application cliente migrée vers l’API REST V2 en une seule fois pour tous les utilisateurs ? migration-faq1

Non.

L’application cliente n’est pas tenue de déployer simultanément une nouvelle version intégrant la version V2 de l’API REST à tous les utilisateurs.

L’authentification Adobe Pass continuera à prendre en charge les anciennes versions d’applications clientes intégrant l’API REST V1 ou SDK jusqu’à la fin de 2025.

​2. Dois-je déployer simultanément une nouvelle application cliente migrée vers l’API REST V2 sur toutes les API et tous les flux ? migration-faq2

Oui.

L’application cliente est requise pour déployer simultanément une nouvelle version intégrant l’API REST V2 à tous les flux et API d’authentification Adobe Pass.

Dans le cas du flux « deuxième authentification de l’écran », l’application cliente doit déployer simultanément une nouvelle version intégrant l’API REST V2 pour les applications principales et secondaires.

L’authentification Adobe Pass ne prend pas en charge les implémentations « hybrides » qui intègrent à la fois l’API REST V2 et l’API REST V1/SDK entre les API et les flux.

​3. L’authentification de l’utilisateur sera-t-elle conservée lors de la mise à jour vers une nouvelle application cliente migrée vers l’API REST V2 ? migration-faq3

Non.

L’authentification de l’utilisateur obtenue dans les anciennes versions de l’application cliente intégrant l’API REST V1 ou SDK n’est pas conservée.

Par conséquent, l’utilisateur devra s’authentifier à nouveau dans la nouvelle application cliente migrée vers l’API REST V2.

​4. Les codes d’erreur améliorés sont-ils activés par défaut dans l’API REST V2 ? migration-faq4

Oui.

Les applications clientes qui migrent vers l’API REST V2 bénéficient automatiquement de cette fonctionnalité par défaut, fournissant des informations d’erreur plus détaillées et plus précises.

Pour plus d’informations, consultez la documentation Codes d’erreur améliorés.

​5. Les intégrations existantes nécessitent-elles des modifications de configuration lors de la migration vers l’API REST V2 ? migration-faq5

Non.

Les applications clientes qui migrent vers l’API REST V2 ne nécessitent aucune modification de configuration pour les intégrations MVPD existantes. En outre, ils continueront à utiliser les mêmes identifiants pour les fournisseurs de services et MVPD existants.

En outre, les protocoles utilisés par l’authentification Adobe Pass pour communiquer avec les points d’entrée MVPD restent inchangés.

FAQ sur la phase d’enregistrement

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase d’enregistrement ? registration-phase-v1-to-v2-faq1

Dans la migration de l’API REST V1 vers l’API REST V2, il n’y a aucune modification de haut niveau en ce qui concerne la phase d’enregistrement.

L’application cliente peut continuer à utiliser le même flux pour s’enregistrer auprès de l’authentification Adobe Pass par le biais du processus Dynamic Client Registration (DCR) et obtenir un jeton d’accès.

Pour plus d’informations, consultez les documents suivants :

• Présentation de l’enregistrement client dynamique
• API de récupération des informations d’identification du client
• Récupérer l’API du jeton d’accès
• Flux d’enregistrement client dynamique

FAQ sur la phase de configuration

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase de configuration ? configuration-phase-v1-to-v2-faq1

Dans la migration de l’API REST V1 vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans le tableau suivant :

table 0-row-4 1-row-4
Champ d’application	API REST V1	API REST V2	Observations
Récupération de la liste des MVPD avec l’intégration active	GET /api/v1/config/{serviceProvider}	GET /api/v2/{serviceProvider}/configuration

FAQ sur la phase d’authentification

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase d’authentification ? authentication-phase-v1-to-v2-faq1

Dans la migration de l’API REST V1 vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans le tableau suivant :

table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 7-row-4
Champ d’application	API REST V1	API REST V2	Observations
Récupérer le code d’enregistrement (code d’authentification)	POST /reggie/v1/{serviceProvider}/regcode	POST /api/v2/{serviceProvider}/sessions	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le code d’enregistrement (code d’authentification)	GET /reggie/v1/{serviceProvider}/regcode/{code}	GET /api/v2/{serviceProvider}/sessions/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application secondaire
Reprendre l’authentification (MVPD) sur le deuxième écran (application)	GET /api/v1/authenticate	POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application secondaire
Lancer l’authentification (MVPD)	GET /api/v1/authenticate	GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le statut d’authentification de l’utilisateur	GET /api/v1/checkauthn (premier écran) GET /api/v1/checkauthn (deuxième écran)	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire
Récupérer le jeton d’authentification de l’utilisateur (profil)	GET /api/v1/tokens/authn	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire
Récupération des informations de métadonnées utilisateur	GET /api/v1/tokens/usermetadata	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire

FAQ sur la phase de préautorisation

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase de préautorisation ? preauthorization-phase-v1-to-v2-faq1

Dans la migration de l’API REST V1 vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans le tableau suivant :

table 0-row-4 1-row-4
Champ d’application	API REST V1	API REST V2	Observations
Récupération des ressources préautorisées (décisions de préautorisation)	GET /api/v1/preauthorize (premier écran) GET /api/v1/preauthorize (deuxième écran)	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	Pour plus d’informations, consultez les documents suivants : Flux de préautorisation de base exécuté dans l’application principale

FAQ sur la phase d’autorisation

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase d’autorisation ? authorization-phase-v1-to-v2-faq1

Dans la migration de l’API REST V1 vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans le tableau suivant :

table 0-row-4 1-row-4 2-row-4 3-row-4
Champ d’application	API REST V1	API REST V2	Observations
Lancer l’autorisation (MVPD)	GET /api/v1/authorize	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	L’application cliente peut utiliser la réponse de cette API à plusieurs fins à la fois : Lancer l’autorisation (MVPD) Récupérer la décision d’autorisation Récupérer un jeton de média court Pour plus d’informations, consultez les documents suivants : Flux d’autorisation de base exécuté dans l’application principale
Récupération du jeton d’autorisation (décision d’autorisation)	GET /api/v1/tokens/authz	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	L’application cliente peut utiliser la réponse de cette API à plusieurs fins à la fois : Lancer l’autorisation (MVPD) Récupérer la décision d’autorisation Récupérer un jeton de média court Pour plus d’informations, consultez les documents suivants : Flux d’autorisation de base exécuté dans l’application principale
Récupération du jeton d’autorisation court (jeton multimédia)	GET /api/v1/tokens/media	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	L’application cliente peut utiliser la réponse de cette API à plusieurs fins à la fois : Lancer l’autorisation (MVPD) Récupérer la décision d’autorisation Récupérer un jeton de média court Pour plus d’informations, consultez les documents suivants : Flux d’autorisation de base exécuté dans l’application principale

FAQ sur la phase de déconnexion

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase de déconnexion ? logout-phase-v1-to-v2-faq1

Dans la migration de l’API REST V1 vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans le tableau suivant :

table 0-row-4 1-row-4
Champ d’application	API REST V1	API REST V2	Observations
Lancer la déconnexion	GET /api/v1/logout	GET /api/v2/{serviceProvider}/logout	Pour plus d’informations, consultez les documents suivants : Flux de déconnexion de base effectué dans l’application principale

FAQ sur la phase d’enregistrement

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase d’enregistrement ? registration-phase-sdk-to-v2-faq1

Dans la migration des SDK vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans les tableaux suivants :

SDK JavaScript AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Terminer l’enregistrement dynamique du client (DCR)	Transmission d’une instruction logicielle au constructeur	POST /o/client/register GET /o/client/token	Pour plus d’informations, consultez les documents suivants : Présentation de l’enregistrement client dynamique Flux d’enregistrement client dynamique

SDK AccessEnabler iOS/tvOS

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Terminer l’enregistrement dynamique du client (DCR)	Transmission d’une instruction logicielle au constructeur	POST /o/client/register GET /o/client/token	Pour plus d’informations, consultez les documents suivants : Présentation de l’enregistrement client dynamique Flux d’enregistrement client dynamique

SDK AccessEnabler Android

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Terminer l’enregistrement dynamique du client (DCR)	Transmission d’une instruction logicielle au constructeur	POST /o/client/register GET /o/client/token	Pour plus d’informations, consultez les documents suivants : Présentation de l’enregistrement client dynamique Flux d’enregistrement client dynamique

SDK FireOS AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Terminer l’enregistrement dynamique du client (DCR)	Transmission d’une instruction logicielle au constructeur	POST /o/client/register GET /o/client/token	Pour plus d’informations, consultez les documents suivants : Présentation de l’enregistrement client dynamique Flux d’enregistrement client dynamique

FAQ sur la phase de configuration

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase de configuration ? configuration-phase-sdk-to-v2-faq1

Dans la migration des SDK vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans les tableaux suivants :

SDK JavaScript AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération de la liste des MVPD avec l’intégration active	AccessEnabler.getAuthentication	GET /api/v2/{serviceProvider}/configuration

SDK AccessEnabler iOS/tvOS

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération de la liste des MVPD avec l’intégration active	AccessEnabler.getAuthentication	GET /api/v2/{serviceProvider}/configuration

SDK AccessEnabler Android

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération de la liste des MVPD avec l’intégration active	AccessEnabler.getAuthentication	GET /api/v2/{serviceProvider}/configuration

SDK FireOS AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération de la liste des MVPD avec l’intégration active	AccessEnabler.getAuthentication	GET /api/v2/{serviceProvider}/configuration

FAQ sur la phase d’authentification

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase d’authentification ? authentication-phase-sdk-to-v2-faq1

Dans la migration des SDK vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans les tableaux suivants :

SDK JavaScript AccessEnabler

table 0-row-4 1-row-4 2-row-4 3-row-4
Champ d’application	SDK	API REST V2	Observations
Lancer l’authentification (MVPD)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le statut d’authentification de l’utilisateur	AccessEnabler.checkAuthentication	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire
Récupération des informations de métadonnées utilisateur	AccessEnabler.getMetadata	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire

SDK AccessEnabler iOS

table 0-row-4 1-row-4 2-row-4 3-row-4
Champ d’application	SDK	API REST V2	Observations
Lancer l’authentification (MVPD)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le statut d’authentification de l’utilisateur	AccessEnabler.checkAuthentication	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire
Récupération des informations de métadonnées utilisateur	AccessEnabler.getMetadata	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire

SDK tvOS AccessEnabler

table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4
Champ d’application	SDK	API REST V2	Observations
Récupérer le code d’enregistrement (code d’authentification)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le code d’enregistrement (code d’authentification)	GET /reggie/v1/{serviceProvider}/regcode/{code}	GET /api/v2/{serviceProvider}/sessions/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application secondaire
Reprendre l’authentification (MVPD) sur le deuxième écran (application)	GET /api/v1/authenticate	POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application secondaire
Lancer l’authentification (MVPD)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le statut d’authentification de l’utilisateur	AccessEnabler.checkAuthentication	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire
Récupération des informations de métadonnées utilisateur	AccessEnabler.getMetadata	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire

SDK AccessEnabler Android

table 0-row-4 1-row-4 2-row-4 3-row-4
Champ d’application	SDK	API REST V2	Observations
Lancer l’authentification (MVPD)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le statut d’authentification de l’utilisateur	AccessEnabler.checkAuthentication	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire
Récupération des informations de métadonnées utilisateur	AccessEnabler.getMetadata	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire

SDK FireOS AccessEnabler

table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4
Champ d’application	SDK	API REST V2	Observations
Récupérer le code d’enregistrement (code d’authentification)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le code d’enregistrement (code d’authentification)	GET /reggie/v1/{serviceProvider}/regcode/{code}	GET /api/v2/{serviceProvider}/sessions/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application secondaire
Reprendre l’authentification (MVPD) sur le deuxième écran (application)	GET /api/v1/authenticate	POST /api/v2/{serviceProvider}/sessions/{code} GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application secondaire
Lancer l’authentification (MVPD)	AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider	POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code}	Pour plus d’informations, consultez les documents suivants : Flux d’authentification de base effectué dans l’application principale Flux d’authentification de base effectué dans l’application secondaire
Vérifier le statut d’authentification de l’utilisateur	AccessEnabler.checkAuthentication	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire
Récupération des informations de métadonnées utilisateur	AccessEnabler.getMetadata	Utilisez l’une des méthodes suivantes : GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code}	L’application cliente peut utiliser la réponse de ces API à plusieurs fins à la fois : Vérifier le statut d’authentification de l’utilisateur Récupérer le profil utilisateur Récupération des informations de métadonnées utilisateur Pour plus d’informations, consultez les documents suivants : Flux de profils de base exécuté dans l’application principale Flux de profils de base exécuté dans l’application secondaire

FAQ sur la phase de préautorisation

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase de préautorisation ? preauthorization-phase-sdk-to-v2-faq1

Dans la migration des SDK vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans les tableaux suivants :

SDK JavaScript AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération des ressources préautorisées (décisions de préautorisation)	AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	Pour plus d’informations, consultez les documents suivants : Flux de préautorisation de base exécuté dans l’application principale

SDK AccessEnabler iOS/tvOS

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération des ressources préautorisées (décisions de préautorisation)	AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	Pour plus d’informations, consultez les documents suivants : Flux de préautorisation de base exécuté dans l’application principale

SDK AccessEnabler Android

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération des ressources préautorisées (décisions de préautorisation)	AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	Pour plus d’informations, consultez les documents suivants : Flux de préautorisation de base exécuté dans l’application principale

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération des ressources préautorisées (décisions de préautorisation)	AccessEnabler.checkPreauthorizedResources	POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}	Pour plus d’informations, consultez les documents suivants : Flux de préautorisation de base exécuté dans l’application principale

FAQ sur la phase d’autorisation

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase d’autorisation ? authorization-phase-sdk-to-v2-faq1

Dans la migration des SDK vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans les tableaux suivants :

SDK JavaScript AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération du jeton d’autorisation court (jeton multimédia)	AccessEnabler.checkAuthorization AccessEnabler.getAuthorization	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	L’application cliente peut utiliser la réponse de cette API à plusieurs fins à la fois : Lancer l’autorisation (MVPD) Récupérer la décision d’autorisation Récupérer un jeton de média court Pour plus d’informations, consultez les documents suivants : Flux d’autorisation de base exécuté dans l’application principale

SDK AccessEnabler iOS/tvOS

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération du jeton d’autorisation court (jeton multimédia)	AccessEnabler.checkAuthorization AccessEnabler.getAuthorization	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	L’application cliente peut utiliser la réponse de cette API à plusieurs fins à la fois : Lancer l’autorisation (MVPD) Récupérer la décision d’autorisation Récupérer un jeton de média court Pour plus d’informations, consultez les documents suivants : Flux d’autorisation de base exécuté dans l’application principale

SDK AccessEnabler Android

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération du jeton d’autorisation court (jeton multimédia)	AccessEnabler.checkAuthorization AccessEnabler.getAuthorization	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	L’application cliente peut utiliser la réponse de cette API à plusieurs fins à la fois : Lancer l’autorisation (MVPD) Récupérer la décision d’autorisation Récupérer un jeton de média court Pour plus d’informations, consultez les documents suivants : Flux d’autorisation de base exécuté dans l’application principale

SDK FireOS AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Récupération du jeton d’autorisation court (jeton multimédia)	AccessEnabler.checkAuthorization AccessEnabler.getAuthorization	POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd}	L’application cliente peut utiliser la réponse de cette API à plusieurs fins à la fois : Lancer l’autorisation (MVPD) Récupérer la décision d’autorisation Récupérer un jeton de média court Pour plus d’informations, consultez les documents suivants : Flux d’autorisation de base exécuté dans l’application principale

FAQ sur la phase de déconnexion

​1. Quelles sont les migrations d’API de haut niveau requises pour la phase de déconnexion ? logout-phase-sdk-to-v2-faq1

Dans la migration des SDK vers l’API REST V2, des modifications de haut niveau doivent être prises en compte et sont présentées dans les tableaux suivants :

SDK JavaScript AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Lancer la déconnexion	AccessEnabler.logout	GET /api/v2/{serviceProvider}/logout	Pour plus d’informations, consultez les documents suivants : Flux de déconnexion de base effectué dans l’application principale

SDK AccessEnabler iOS/tvOS

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Lancer la déconnexion	AccessEnabler.logout	GET /api/v2/{serviceProvider}/logout	Pour plus d’informations, consultez les documents suivants : Flux de déconnexion de base effectué dans l’application principale

SDK AccessEnabler Android

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Lancer la déconnexion	AccessEnabler.logout	GET /api/v2/{serviceProvider}/logout	Pour plus d’informations, consultez les documents suivants : Flux de déconnexion de base effectué dans l’application principale

SDK FireOS AccessEnabler

table 0-row-4 1-row-4
Champ d’application	SDK	API REST V2	Observations
Lancer la déconnexion	AccessEnabler.logout	GET /api/v2/{serviceProvider}/logout	Pour plus d’informations, consultez les documents suivants : Flux de déconnexion de base effectué dans l’application principale