Häufig gestellte Fragen zur REST API V2
- Themen:
- Authentifizierung
WICHTIGDieses Dokument bietet allgemeine Antworten auf häufig gestellte Fragen zur Verwendung der Adobe Pass Authentication REST API V2.
Weitere Informationen zur REST API V2 insgesamt finden Sie in der Dokumentation REST API V2 - Übersicht .
Allgemeine FAQs
Beginnen Sie mit diesem Abschnitt, wenn Sie an einem Programm arbeiten, das die REST-API V2 integrieren muss, unabhängig davon, ob es sich um ein neues oder ein bestehendes Programm handelt, das von REST-API V1 oder SDK migriert.
Weitere Informationen zu Migrationsdetails und -schritten finden Sie auch in den nächsten Abschnitten.
Häufig gestellte Fragen zur Registrierungsphase
Häufig gestellte Fragen zur Registrierungsphase
Häufig gestellte Fragen zur Konfigurationsphase
Häufig gestellte Fragen zur Konfigurationsphase
1. Was ist der Zweck der Konfigurationsphase?
Die Konfigurationsphase dient dazu, der Client-Anwendung die Liste der MVPDs bereitzustellen, mit denen sie aktiv integriert ist, sowie Konfigurationsdetails (z. B. id, displayName, logoUrl usw.), die von der Adobe Pass-Authentifizierung für jede MVPD gespeichert wurden.
Die Konfigurationsphase dient als erforderlicher Schritt für die Authentifizierungsphase, wenn das Client-Programm den Benutzer bzw. die Benutzerin auffordern muss, seinen/ihren TV-Anbieter auszuwählen.
2. Ist die Konfigurationsphase obligatorisch?
Die Konfigurationsphase ist nicht obligatorisch. Die Client-Anwendung muss die Konfiguration nur abrufen, wenn der Benutzer seine MVPD zur Authentifizierung oder erneuten Authentifizierung auswählen muss.
Die Client-Anwendung kann diese Phase in den folgenden Szenarien überspringen:
- Der Benutzer ist bereits authentifiziert.
- Dem Benutzer wird temporärer Zugriff über die Basis- oder Werbe-Funktion TempPass angeboten.
- Die Benutzerauthentifizierung ist abgelaufen, aber die Client-Anwendung hat die zuvor ausgewählte MVPD als benutzererlebnismotivierte Auswahl zwischengespeichert und fordert die Benutzenden lediglich auf zu bestätigen, dass sie weiterhin Abonnenten dieser MVPD sind.
3. Was ist eine Konfiguration und wie lange ist sie gültig?
Die Konfiguration ist ein Begriff, der in der Dokumentation Glossar definiert ist.
Die Konfiguration enthält eine Liste von MVPDs, die durch die folgenden Attribute id, displayName, logoUrl usw. definiert sind, die vom Endpunkt Configuration abgerufen werden können.
Die Client-Anwendung darf die Konfiguration nur abrufen, wenn die Benutzerin bzw. der Benutzer ihre MVPD zur Authentifizierung oder erneuten Authentifizierung auswählen muss.
Die Client-Anwendung kann die Konfigurationsantwort verwenden, um eine UI-Auswahl mit verfügbaren MVPD-Optionen zu präsentieren, wenn der Benutzer seinen TV-Anbieter auswählen muss.
Die Client-Anwendung muss die vom Benutzer ausgewählte MVPD-Kennung speichern, wie sie im id auf Konfigurationsebene von MVPD angegeben ist, um mit der Authentifizierungs-, Vorautorisierungs-, Autorisierungs- oder Abmeldephase fortzufahren.
Weitere Informationen finden Sie in der Dokumentation Konfiguration abrufen .
4. Sollte die Client-Anwendung die Konfigurationsantwortinformationen in einem persistenten Speicher zwischenspeichern?
Die Client-Anwendung darf die Konfiguration nur abrufen, wenn die Benutzerin bzw. der Benutzer ihre MVPD zur Authentifizierung oder erneuten Authentifizierung auswählen muss.
Die Client-Anwendung sollte die Konfigurationsantwortinformationen in einem Arbeitsspeicher zwischenspeichern, um unnötige Anfragen zu vermeiden und das Benutzererlebnis zu verbessern, wenn:
- Der Benutzer ist bereits authentifiziert.
- Dem Benutzer wird temporärer Zugriff über die Basis- oder Werbe-Funktion TempPass angeboten.
- Die Benutzerauthentifizierung ist abgelaufen, aber die Client-Anwendung hat die zuvor ausgewählte MVPD als benutzererlebnismotivierte Auswahl zwischengespeichert und fordert die Benutzenden lediglich auf zu bestätigen, dass sie weiterhin Abonnenten dieser MVPD sind.
5. Kann die Client-Anwendung eine eigene Liste von MVPDs verwalten?
Die Client-Anwendung kann ihre eigene Liste von MVPDs verwalten, erfordert jedoch, dass die MVPD-IDs mit der Adobe Pass-Authentifizierung synchronisiert bleiben. Es wird daher empfohlen, die von der Adobe Pass-Authentifizierung bereitgestellte Konfiguration zu verwenden, um sicherzustellen, dass die Liste aktuell und korrekt ist.
Die Client-Anwendung erhält einen Fehler von der Adobe Pass-Authentifizierungs-REST-API V2, wenn die angegebene MVPD-Kennung ungültig ist oder keine aktive Integration mit dem angegebenen Dienstleister“.
6. Kann die Client-Anwendung die Liste der MVPDs filtern?
Die Client-Anwendung kann die Liste der in der Konfigurationsantwort bereitgestellten MVPDs filtern, indem ein benutzerdefinierter Mechanismus implementiert wird, der auf ihrer eigenen Geschäftslogik und ihren Anforderungen basiert, z. B. dem Benutzerstandort oder dem Benutzerverlauf der vorherigen Auswahl.
Die Client-Anwendung kann die Liste der MVPDs TempPass oder der MVPDs filtern, deren Integration noch in Entwicklung oder Test ist.
7. Was passiert, wenn die Integration mit einer MVPD deaktiviert und als inaktiv markiert ist?
Wenn die Integration mit einer MVPD deaktiviert und als inaktiv markiert ist, wird die MVPD aus der Liste der MVPDs entfernt, die in weiteren Konfigurationsantworten bereitgestellt werden, und es sind zwei wichtige Folgen zu berücksichtigen:
- Die nicht authentifizierten Benutzer dieser MVPD können die Authentifizierungsphase mit dieser MVPD nicht mehr abschließen.
- Die authentifizierten Benutzenden dieser MVPD können die Vorautorisierungs-, Autorisierungs- oder Abmeldephasen mit dieser MVPD nicht mehr abschließen.
Die Client-Anwendung erhält einen Fehler von der Adobe Pass-Authentifizierungs-REST-API V2, wenn der ausgewählte Benutzer in MVPD keine aktive Integration mehr mit dem angegebenen Dienstleister hat.
8. Was passiert, wenn die Integration mit MVPD wieder aktiviert und als aktiv markiert wird?
Wenn die Integration mit einer MVPD wieder aktiviert und als aktiviert markiert ist, wird die MVPD wieder in die Liste der MVPDs aufgenommen, die in weiteren Konfigurationsantworten bereitgestellt werden, und es sind zwei wichtige Konsequenzen zu beachten:
- Die nicht authentifizierten Benutzer dieser MVPD können die Authentifizierungsphase mithilfe dieser MVPD erneut abschließen.
- Die authentifizierten Benutzer dieser MVPD können die Vorautorisierungs-, Autorisierungs- oder Abmeldephasen mit dieser MVPD erneut abschließen.
9. Wie kann ich die Integration mit MVPD aktivieren oder deaktivieren?
Dieser Vorgang kann über das Adobe Pass TVE-Dashboard von einem Ihrer Organisationsadministratoren oder einem in Ihrem Namen handelnden Adobe Pass-Authentifizierungsmitarbeiter ausgeführt werden.
Weitere Informationen finden Sie in der Dokumentation TVE Dashboard Integrations-Benutzerhandbuch.
Häufig gestellte Fragen zur Authentifizierungsphase
Häufig gestellte Fragen zur Authentifizierungsphase
1. Was ist der Zweck der Authentifizierungsphase?
Der Zweck der Authentifizierungsphase besteht darin, der Client-Anwendung die Möglichkeit zu geben, die Identität des Benutzers zu überprüfen und Benutzermetadaten-Informationen abzurufen.
Die Authentifizierungsphase fungiert als erforderlicher Schritt für die Vorautorisierungsphase oder Autorisierungsphase, wenn die Client-Anwendung Inhalte wiedergeben muss.
2. Ist die Authentifizierungsphase obligatorisch?
Die Authentifizierungsphase ist obligatorisch. Die Client-Anwendung muss den Benutzer authentifizieren, wenn sie innerhalb der Adobe Pass-Authentifizierung kein gültiges Profil hat.
Die Client-Anwendung kann diese Phase in den folgenden Szenarien überspringen:
- Der Benutzer ist bereits authentifiziert und das Profil ist weiterhin gültig.
- Dem Benutzer wird temporärer Zugriff über die Basis- oder Werbe-Funktion TempPass angeboten.
Die Fehlerbehandlung in der Client-Anwendung erfordert die Verarbeitung der Fehler-Codes (z. B. authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated usw.), die angeben, dass die Client-Anwendung eine Authentifizierung des Benutzers erfordert.
3. Was ist eine Authentifizierungssitzung und wie lange ist sie gültig?
Die Authentifizierungssitzung ist ein Begriff, der in der Dokumentation Glossar definiert ist.
Die Authentifizierungssitzung speichert Informationen zum initiierten Authentifizierungsprozess, die vom Sitzungs-Endpunkt abgerufen werden können.
Die Authentifizierungssitzung ist für einen begrenzten und kurzen Zeitraum gültig, der zum Zeitpunkt der Ausgabe durch den notAfter Zeitstempel angegeben wird. Dies gibt an, wie lange der Benutzer bis zum Abschluss des Authentifizierungsprozesses muss, bevor der Fluss neu gestartet werden muss.
Die Client-Anwendung kann die Antwort der Authentifizierungssitzung verwenden, um zu erfahren, wie mit dem Authentifizierungsprozess fortgefahren werden soll. Beachten Sie, dass es Fälle gibt, in denen der Benutzer sich nicht authentifizieren muss, z. B. bei Bereitstellung eines temporären Zugriffs, eingeschränktem Zugriff oder wenn der Benutzer bereits authentifiziert ist.
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Authentifizierungssitzung-API erstellen
- Authentifizierungssitzung-API fortsetzen
- Grundlegender Authentifizierungsfluss innerhalb der primären Anwendung
- Grundlegender Authentifizierungsfluss innerhalb der sekundären Anwendung
4. Was ist ein Authentifizierungs-Code und wie lange ist er gültig?
Der Authentifizierungs-Code ist ein Begriff, der in der Dokumentation Glossar definiert ist.
Der Authentifizierungs-Code speichert einen eindeutigen Wert, der generiert wird, wenn ein Benutzer den Authentifizierungsprozess initiiert, und identifiziert die Authentifizierungssitzung eines Benutzers eindeutig, bis der Prozess abgeschlossen ist oder die Authentifizierungssitzung abläuft.
Der Authentifizierungs-Code ist für einen begrenzten und kurzen Zeitraum gültig, der zum Zeitpunkt der Initiierung der Authentifizierungssitzung durch den notAfter Zeitstempel angegeben wird. Er gibt an, wie lange der Benutzer den Authentifizierungsprozess abschließen muss, bevor der Fluss neu gestartet werden muss.
Die Client-Anwendung kann den Authentifizierungs-Code verwenden, um zu überprüfen, ob der Benutzer die Authentifizierung erfolgreich abgeschlossen hat, und um die Profilinformationen des Benutzers abzurufen, normalerweise über einen Abrufmechanismus.
Die Client-Anwendung kann den Authentifizierungs-Code auch verwenden, um dem Benutzer zu ermöglichen, den Authentifizierungsprozess entweder auf demselben Gerät oder auf einem zweiten (Bildschirm-)Gerät abzuschließen oder fortzusetzen, da die Authentifizierungssitzung noch nicht abgelaufen ist.
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Authentifizierungssitzung-API erstellen
- Authentifizierungssitzung-API fortsetzen
- Grundlegender Authentifizierungsfluss innerhalb der primären Anwendung
- Grundlegender Authentifizierungsfluss innerhalb der sekundären Anwendung
5. Wie kann die Client-Anwendung erkennen, ob der Benutzer einen gültigen Authentifizierungscode eingegeben hat und dass die Authentifizierungssitzung noch nicht abgelaufen ist?
Die Client-Anwendung kann den vom Benutzer in eine sekundäre (Bildschirm-)Anwendung eingegebenen Authentifizierungscode überprüfen, indem sie eine Anfrage an einen der Sitzungs-Endpunkte sendet, der dafür verantwortlich ist, die Authentifizierungssitzung fortzusetzen oder Authentifizierungssitzungsinformationen abzurufen, die mit dem Authentifizierungscode verknüpft sind.
Die Client-Anwendung erhält einen Fehler, wenn der angegebene Authentifizierungscode falsch eingegeben wurde oder wenn die Authentifizierungssitzung abgelaufen ist.
Weitere Informationen finden Sie in den Dokumenten Fortsetzen der Authentifizierungssitzung und Abrufen der).
6. Wie kann die Client-Anwendung erkennen, ob der Benutzer bereits authentifiziert ist?
Die Client-Anwendung kann einen der folgenden Endpunkte abfragen, die überprüfen können, ob ein Benutzer bereits authentifiziert ist, und Profilinformationen zurückgeben:
- Profil-Endpunkt-API
- Profile-Endpunkt für bestimmte MVPD-APIs
- Profile-Endpunkt für bestimmte (Authentifizierungs-)Code-API
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Fluss von grundlegenden Profilen, der in der primären Anwendung ausgeführt wird
- Fluss der grundlegenden Profile, der in der sekundären Anwendung ausgeführt wird
7. Was ist ein Profil und wie lange ist es gültig?
Das Profil ist ein Begriff, der in der Dokumentation Glossar definiert ist.
Das Profil speichert Informationen über die Authentifizierungsgültigkeit des Benutzers, Metadateninformationen und viele mehr, die vom Endpunkt „Profiles“ abgerufen werden können.
Die Client-Anwendung kann das Profil verwenden, um den Authentifizierungsstatus des Benutzers zu ermitteln, auf Benutzermetadaten-Informationen zuzugreifen, die zur Authentifizierung verwendete Methode zu finden oder die Entität zu ermitteln, die zur Bereitstellung der Identität verwendet wird.
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Profil-Endpunkt-API
- Profile-Endpunkt für bestimmte MVPD-APIs
- Profile-Endpunkt für bestimmte (Authentifizierungs-)Code-API
- Fluss von grundlegenden Profilen, der in der primären Anwendung ausgeführt wird
- Fluss der grundlegenden Profile, der in der sekundären Anwendung ausgeführt wird
Das Profil ist für einen begrenzten Zeitraum gültig, der bei der Abfrage durch den notAfter Zeitstempel angegeben wird. Dies gibt an, wie lange der Benutzer über eine gültige Authentifizierung verfügt, bevor er die Authentifizierungsphase erneut durchlaufen muss.
Dieser begrenzte Zeitraum, der als Authentifizierung (authN) TTL bezeichnet wird, kann über das Adobe Pass TVE-Dashboardvon einem Ihrer Organisationsadministratoren oder einem in Ihrem Namen handelnden Adobe Pass-Authentifizierungsbeauftragten angezeigt und geändert werden.
Weitere Informationen finden Sie in der Dokumentation TVE Dashboard Integrations-Benutzerhandbuch.
8. Sollte die Client-Anwendung die Profilinformationen des Benutzers in einem beständigen Speicher zwischenspeichern?
Die Client-Anwendung sollte Teile der Profilinformationen des Benutzers in einem beständigen Speicher zwischenspeichern, um unnötige Anfragen zu vermeiden und das Benutzererlebnis unter Berücksichtigung der folgenden Aspekte zu verbessern:
mvpdWenn das aktuelle Benutzerprofil abläuft, kann die Client-Anwendung die gespeicherte MVPD-Auswahl verwenden und den Benutzer einfach zur Bestätigung auffordern.
attributeszip, maxRating usw.) zu personalisieren.Benutzermetadaten werden nach Abschluss des Authentifizierungsflusses verfügbar, daher muss die Client-Anwendung keinen separaten Endpunkt abfragen, um die Benutzermetadaten-Informationen abzurufen, da sie bereits in den Profilinformationen enthalten sind.
Bestimmte Metadatenattribute können je nach MVPD und spezifischem Metadatenattribut während des Autorisierungsflusses aktualisiert werden. Daher muss die Client-Anwendung möglicherweise die Profil-APIs erneut abfragen, um die neuesten Benutzermetadaten abzurufen.
notAfterDie Fehlerbehandlung in der Client-Anwendung erfordert die Verarbeitung der Fehler-Codes (z. B.
authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated usw.), was darauf hinweist, dass die Client-Anwendung eine Authentifizierung des Benutzers erfordert.9. Kann die Client-Anwendung das Benutzerprofil erweitern, ohne dass eine erneute Authentifizierung erforderlich ist?
Anzahl
Das Benutzerprofil kann ohne Benutzerinteraktion nicht über seine Gültigkeit hinaus verlängert werden, da sein Ablauf durch die mit MVPDs eingerichtete Authentifizierungs-TTL bestimmt wird.
Daher muss die Client-Anwendung den Benutzer auffordern, sich erneut zu authentifizieren und mit der MVPD-Anmeldeseite zu interagieren, um sein Profil auf unserem System zu aktualisieren.
Bei MVPDs, die Home-Based Authentication (HBA) unterstützen, muss der Benutzer jedoch keine Anmeldeinformationen eingeben.
10. Was sind die Anwendungsfälle für jeden verfügbaren Profilendpunkt?
Die einfachen Profil-Endpunkte sind so konzipiert, dass sie Client-Anwendungen die Möglichkeit bieten, den Authentifizierungsstatus des Benutzers zu kennen, auf Benutzermetadaten-Informationen zuzugreifen, die zur Authentifizierung verwendete Methode oder die Entität zu finden, die zur Bereitstellung der Identität verwendet wird.
Jeder Endpunkt eignet sich für einen bestimmten Anwendungsfall wie folgt:
In diesem Szenario verfügt die Client-Anwendung nicht über die vom Benutzer ausgewählte MVPD-Kennung, die in einem persistenten Speicher zwischengespeichert ist.
Daher wird eine einzige Anfrage gesendet, um alle verfügbaren Benutzerprofile abzurufen.
In diesem Fall muss die zuvor ausgewählte MVPD-Kennung des Benutzers in einem persistenten Speicher zwischengespeichert sein.
Daher wird eine einzige Anfrage gesendet, um das Benutzerprofil für diese spezifische MVPD abzurufen.
In diesem Szenario muss die Client-Anwendung feststellen, ob der Benutzer die Authentifizierung erfolgreich abgeschlossen hat, und muss seine Profilinformationen abrufen.
Daher wird ein Abrufmechanismus gestartet, um das mit dem Authentifizierungs-Code verknüpfte Benutzerprofil abzurufen.
Weitere Informationen finden Sie in den Dokumenten Fluss „Grundlegende Profile“, der in derausgeführt wird und „Fluss „Grundlegende Profile“, der in der sekundären Anwendung ausgeführt).
Der SSO-Endpunkt Profile erfüllt einen anderen Zweck. Er bietet der Client-Anwendung die Möglichkeit, ein Benutzerprofil mithilfe der Antwort der Partnerauthentifizierung zu erstellen und es in einem einzigen, einmaligen Vorgang abzurufen.
In diesem Szenario muss die Client-Anwendung ein Benutzerprofil erstellen, nachdem sie die Antwort zur Partnerauthentifizierung erhalten hat, und sie in einem einzigen, einmaligen Vorgang abrufen.
Für alle nachfolgenden Abfragen müssen die Endpunkte „Basic Profiles“ verwendet werden, um den Authentifizierungsstatus des Benutzers zu bestimmen, auf Benutzermetadaten-Informationen zuzugreifen, die zur Authentifizierung verwendete Methode zu finden oder die Entität zu finden, die zur Bereitstellung der Identität verwendet wird.
Weitere Informationen finden Sie in den Dokumenten Single Sign-on using Partner Flows und Apple SSO Cookbook (REST API V2).
11. Was sollte die Client-Anwendung tun, wenn die Benutzerin bzw. der Benutzer über mehrere MVPD-Profile verfügt?
Die Entscheidung, mehrere Profile zu unterstützen, hängt von den Geschäftsanforderungen der Client-Anwendung ab.
Die meisten Benutzer haben nur ein Profil. Wenn jedoch mehrere Profile vorhanden sind (wie unten beschrieben), ist die Client-Anwendung dafür verantwortlich, das beste Benutzererlebnis für die Profilauswahl zu bestimmen.
Die Client-Anwendung kann den Benutzer auffordern, das gewünschte MVPD-Profil auszuwählen, oder die Auswahl automatisch vornehmen, z. B. das erste Benutzerprofil aus der Antwort oder das Profil mit der längsten Gültigkeitsdauer auswählen.
Die REST-API v2 unterstützt mehrere Profile, um Folgendes zu ermöglichen:
- Benutzer, die möglicherweise zwischen einem regulären MVPD-Profil und einem Profil wählen müssen, das über Single Sign-on (SSO) abgerufen wurde.
- Benutzern wird temporärer Zugriff angeboten, ohne dass sie sich von ihrem regulären MVPD abmelden müssen.
- Benutzende mit MVPD-Abonnement in Kombination mit Direct-to-Consumer-Services (DTC).
- Benutzende mit mehreren MVPD-Abonnements.
12. Was passiert, wenn Benutzerprofile ablaufen?
Wenn Benutzerprofile ablaufen, werden sie nicht mehr in die Antwort vom Endpunkt „Profile“ aufgenommen.
Wenn der Endpunkt Profiles eine leere Antwort auf die Profilzuordnung zurückgibt, muss die Client-Anwendung eine neue Authentifizierungssitzung erstellen und den Benutzer zur erneuten Authentifizierung auffordern.
Weitere Informationen finden Sie in der Dokumentation Erstellen einer Authentifizierungssitzung-API .
13. Wann werden Benutzerprofile ungültig?
Benutzerprofile werden in den folgenden Szenarien ungültig:
- Wann die Authentifizierungs-TTL abläuft, wie durch den
notAfterZeitstempel in der Antwort des Profilendpunkts angegeben. - Wenn die Client-Anwendung den Header-AP-Device-Identifier ändert.
- Wenn die Client-Anwendung die Client-Anmeldeinformationen aktualisiert, die zum Abrufen des Authorization-Header-Werts verwendet werden.
- Wenn die Client-Anwendung die Software-Anweisung widerruft oder aktualisiert, die zum Abrufen der Client-Anmeldeinformationen verwendet wird.
14. Wann sollte die Client-Anwendung den Abrufmechanismus starten?
Um Effizienz zu gewährleisten und unnötige Anfragen zu vermeiden, muss die Client-Anwendung den Abrufmechanismus unter folgenden Bedingungen starten:
Authentifizierung wird innerhalb der primären (Bildschirm-)Anwendung durchgeführt
Die primäre (Streaming-)Anwendung sollte den Abfragevorgang starten, wenn die Benutzerin oder der Benutzer die endgültige Zielseite erreicht, nachdem die Browser-Komponente die in der Endpunktanforderung redirectUrlSitzungen für denangegebene URL geladen hat.
Authentifizierung wird in einer sekundären (Bildschirm-)Anwendung durchgeführt
Die primäre (Streaming-) Anwendung sollte den Abfragevorgang starten, sobald der Benutzer den Authentifizierungsprozess einleitet - direkt nach Erhalt der Endpunktantwort Sitzungen und Anzeige des Authentifizierungs-Codes für den Benutzer.
15. Wann sollte die Client-Anwendung den Abrufmechanismus stoppen?
Um Effizienz zu gewährleisten und unnötige Anfragen zu vermeiden, muss die Client-Anwendung den Abrufmechanismus unter folgenden Bedingungen stoppen:
Erfolgreiche Authentifizierung
Die Profilinformationen des Benutzers wurden erfolgreich abgerufen, wodurch der Authentifizierungsstatus bestätigt wird. Zu diesem Zeitpunkt ist keine Abfrage mehr erforderlich.
Authentifizierungssitzung und Code-Ablauf
Die Authentifizierungssitzung und der Code laufen ab, wie durch den notAfter Zeitstempel (z. B. 30 Minuten) in der Endpunktantwort Sitzungen angegeben. In diesem Fall muss der Benutzer den Authentifizierungsprozess neu starten, und das Abrufen mit dem vorherigen Authentifizierungs-Code sollte sofort gestoppt werden.
Neuer Authentifizierungs-Code generiert
Wenn der Benutzer einen neuen Authentifizierungscode auf dem Primärgerät (Bildschirm) anfordert, ist die vorhandene Sitzung nicht mehr gültig und das Abrufen mit dem vorherigen Authentifizierungscode sollte sofort gestoppt werden.
16. Welches Intervall zwischen Aufrufen sollte die Client-Anwendung für den Abrufmechanismus verwenden?
Um die Effizienz zu gewährleisten und unnötige Anfragen zu vermeiden, muss die Client-Anwendung die Häufigkeit des Abrufmechanismus unter den folgenden Bedingungen konfigurieren:
17. Wie viele Abrufanfragen kann die Client-Anwendung maximal senden?
Die Client-Anwendung muss die aktuellen Beschränkungen einhalten, die vom Adobe Pass-Authentifizierungsmechanismus () definiert.
Die Fehlerbehandlung in der Client-Anwendung muss den Fehlercode 429: Zu viele Anfragen verarbeiten können, der angibt, dass die Client-Anwendung die maximal zulässige Anzahl von Anfragen überschritten hat.
Weitere Informationen finden Sie in der Dokumentation Drosselungsmechanismus .
18. Wie kann die Client-Anwendung die Metadateninformationen des Benutzers abrufen?
Die Client-Anwendung kann einen der folgenden Endpunkte abfragen, die Benutzermetadaten als Teil der Profilinformationen zurückgeben können:
- Profil-Endpunkt-API
- Profile-Endpunkt für bestimmte MVPD-APIs
- Profile-Endpunkt für bestimmte (Authentifizierungs-)Code-API
Benutzermetadaten werden nach Abschluss des Authentifizierungsflusses verfügbar, daher muss die Client-Anwendung keinen separaten Endpunkt abfragen, um die Benutzermetadaten-Informationen abzurufen, da sie bereits in den Profilinformationen enthalten sind.
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Fluss von grundlegenden Profilen, der in der primären Anwendung ausgeführt wird
- Fluss der grundlegenden Profile, der in der sekundären Anwendung ausgeführt wird
Bestimmte Metadatenattribute können je nach MVPD und spezifischem Metadatenattribut während des Autorisierungsflusses aktualisiert werden. Daher muss die Client-Anwendung möglicherweise die oben genannten APIs erneut abfragen, um die neuesten Benutzermetadaten abzurufen.
19. Wie sollte die Client-Anwendung einen eingeschränkten Zugriff verwalten?
Die Abbaufunktion ermöglicht es der Client-Anwendung, ein nahtloses Streaming-Erlebnis für Benutzende aufrechtzuerhalten, auch wenn bei den Authentifizierungs- oder Autorisierungs-Services ihrer MVPD Probleme auftreten.
Zusammenfassend lässt sich sagen, dass dadurch trotz temporärer Service-Unterbrechungen in MVPD ein unterbrechungsfreier Zugriff auf Inhalte sichergestellt werden kann.
Da Ihr Unternehmen beabsichtigt, die Premium-Funktion zur Beeinträchtigung zu verwenden, muss die Client-Anwendung eingeschränkte Zugriffsflüsse handhaben, die beschreiben, wie sich REST-API-v2-Endpunkte in solchen Szenarien verhalten.
Weitere Informationen finden Sie in der Dokumentation Gestörte".
20. Wie sollte die Client-Anwendung den temporären Zugriff verwalten?
Mit TempPass-Funktion kann die Client-Anwendung dem Benutzer temporären Zugriff gewähren.
Zusammenfassend lässt sich sagen, dass dies für Benutzende interessant sein kann, indem für einen bestimmten Zeitraum ein zeitlich begrenzter Zugriff auf Inhalte oder eine vordefinierte Anzahl von VOD-Titeln bereitgestellt wird.
Da Ihr Unternehmen beabsichtigt, die Premium-TempPass-Funktion zu verwenden, muss die Client-Anwendung temporäre Zugriffsflüsse verarbeiten, die beschreiben, wie sich REST-API-v2-Endpunkte in solchen Szenarien verhalten.
In früheren API-Versionen musste sich die Client-Anwendung von einem Benutzer abmelden, der sich bei seiner regulären MVPD authentifiziert hatte, um einen temporären Zugriff anzubieten.
Mit der REST-API v2 kann die Client-Anwendung bei der Autorisierung eines Streams nahtlos zwischen einer regulären MVPD und einer TempPass-MVPD wechseln, sodass sich der Benutzer nicht mehr abmelden muss.
Weitere Informationen finden Sie in der Dokumentation Temporäre Zugriffsflüsse .
21. Wie sollte die Client-Anwendung den geräteübergreifenden Single-Sign-On-Zugriff verwalten?
Die REST-API v2 kann geräteübergreifendes Single Sign-on aktivieren, wenn die Client-Anwendung eine konsistente eindeutige Benutzerkennung über Geräte hinweg bereitstellt.
Diese Kennung, auch als Service-Token bezeichnet, muss von der Client-Anwendung durch die Implementierung oder Integration eines externen Identity Services Ihrer Wahl generiert werden.
Weitere Informationen finden Sie in der Dokumentation Single Sign-on using Service Token Flows.
Häufig gestellte Fragen zur Vorautorisierungsphase
1. Was ist der Zweck der Vorabgenehmigungsphase?
Der Zweck der Vorautorisierungsphase besteht darin, der Client-Anwendung die Möglichkeit zu geben, eine Untergruppe von Ressourcen aus ihrem Katalog darzustellen, auf die der Benutzer zugreifen könnte.
Die Vorautorisierungsphase kann das Benutzererlebnis verbessern, wenn der Benutzer die Client-Anwendung zum ersten Mal öffnet oder zu einem neuen Abschnitt navigiert.
2. Ist die Phase vor der Autorisierung obligatorisch?
Die Vorautorisierungsphase ist nicht obligatorisch. Die Client-Anwendung kann diese Phase überspringen, wenn sie einen Katalog von Ressourcen präsentieren möchte, ohne sie zuerst auf der Grundlage der Benutzerberechtigung zu filtern.
3. Was ist eine Entscheidung vor der Zulassung?
Die Vorautorisierung ist ein Begriff, der in der Glossar-Dokumentation definiert ist, während der Entscheidungsbegriff auch im Glossar)ist.
Die Vorautorisierungsentscheidung speichert Informationen zum Abfrageergebnis des MVPD-Vorautorisierungsprozesses, die vom Endpunkt Decisions Preauthorize abgerufen werden können.
Die Client-Anwendung kann die Entscheidungen vor der Autorisierung verwenden, um eine Untergruppe von Ressourcen darzustellen, auf die der TV-Anbieter (informative) Entscheidungen dem Benutzer Zugriff gewähren würde.
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Abrufen der Vorabautorisierungsentscheidungen-API
- Grundlegender Vorautorisierungsfluss innerhalb der primären Anwendung
4. Sollte die Client-Anwendung die Entscheidungen zur Vorabautorisierung in einem persistenten Speicher zwischenspeichern?
Die Client-Anwendung ist nicht erforderlich, um Entscheidungen vor der Autorisierung in einem persistenten Speicher zu speichern. Es wird jedoch empfohlen, Zulassungsentscheidungen im Speicher zwischenzuspeichern, um das Benutzererlebnis zu verbessern. Auf diese Weise können unnötige Aufrufe des Endpunkts Decisions Preauthorize für bereits vorautorisierte Ressourcen vermieden werden, wodurch die Latenz verringert und die Leistung verbessert wird.
5. Wie kann der Client-Antrag feststellen, warum eine Vorabautorisierungsentscheidung verweigert wurde?
Die Client-Anwendung kann den Grund für eine abgelehnte Vorautorisierungsentscheidung ermitteln, indem sie den Fehlercode und die Nachricht) überprüft die in der Antwort vom Vorautorisierungs-Endpunkt für Entscheidungen enthalten sind. Diese Details geben insight den spezifischen Grund an, aus dem die Vorabautorisierungsanfrage abgelehnt wurde. So kann das Benutzererlebnis oder der Trigger über die erforderliche Verarbeitung in der Anwendung informiert werden.
Stellen Sie sicher, dass ein Wiederholungsmechanismus, der zum Abrufen von Entscheidungen vor der Autorisierung implementiert ist, nicht zu einer Endlosschleife führt, wenn die Entscheidung vor der Autorisierung abgelehnt wird.
Erwägen Sie, weitere Zustellversuche auf eine angemessene Anzahl zu beschränken und Ablehnungen elegant zu handhaben, indem Sie dem Benutzer klares Feedback senden.
6. Warum fehlt in der Vorabautorisierungsentscheidung ein Medien-Token?
Der Vorautorisierungsentscheidung fehlt ein Medien-Token, da die Vorautorisierungsphase nicht zum Wiedergeben von Ressourcen verwendet werden darf, da dies der Zweck der Autorisierungsphase ist.
7. Kann die Autorisierungsphase übersprungen werden, wenn bereits eine Entscheidung vor der Autorisierung existiert?
Anzahl
Die Autorisierungsphase kann auch dann nicht übersprungen werden, wenn eine Entscheidung vor der Autorisierung verfügbar ist. Entscheidungen vor der Autorisierung dienen nur zu Informationszwecken und gewähren keine tatsächlichen Wiedergaberechte. Die Vorautorisierungsphase soll eine frühe Anleitung bieten, aber die Autorisierungsphase ist weiterhin erforderlich, bevor Inhalte wiedergegeben werden können.
8. Was ist eine Ressource und welche Formate werden unterstützt?
Die Ressource ist ein Begriff, der in der Dokumentation Glossar definiert ist.
Die Ressource ist eine eindeutige Kennung, die mit MVPDs vereinbart wird und mit einem Inhalt verknüpft ist, den die Client-Anwendung streamen könnte.
Die eindeutige Kennung der Ressource kann zwei Formate aufweisen:
- Ein einfaches Zeichenfolgenformat wie eine eindeutige Kennung für einen Kanal (eine Marke).
- Ein RSS-Format für Medien (MRSS), das zusätzliche Informationen wie Titel, Bewertungen und Metadaten zur elterlichen Kontrolle enthält.
Weitere Informationen finden Sie in der Dokumentation Geschützte Ressourcen .
9. Für wie viele Ressourcen kann die Client-Anwendung gleichzeitig eine Vorabautorisierungsentscheidung erhalten?
Die Client-Anwendung kann aufgrund von Bedingungen, die von MVPDs auferlegt werden, in einer einzelnen API-Anfrage eine Vorabautorisierungsentscheidung für eine begrenzte Anzahl von Ressourcen erhalten, normalerweise bis zu 5.
Diese maximale Anzahl von Ressourcen kann angezeigt und geändert werden, nachdem eine Vereinbarung mit MVPDs über das Adobe Pass TVE-Dashboard von einem Ihrer Organisationsadministratoren oder einem in Ihrem Namen handelnden Adobe Pass-Authentifizierungsmitarbeiter getroffen wurde.
Weitere Informationen finden Sie in der Dokumentation TVE Dashboard Integrations-Benutzerhandbuch.
Häufig gestellte Fragen zur Genehmigungsphase
1. Was ist der Zweck der Genehmigungsphase?
In der Autorisierungsphase soll der Client-Anwendung die Möglichkeit gegeben werden, die von den Benutzenden angeforderten Ressourcen abzuspielen, nachdem ihre Rechte bei der MVPD validiert wurden.
2. Ist die Autorisierungsphase obligatorisch?
Die Autorisierungsphase ist obligatorisch. Die Client-Anwendung kann diese Phase nicht überspringen, wenn sie die von der Benutzerin oder dem Benutzer angeforderten Ressourcen wiedergeben möchte, da sie bzw. er bei der MVPD überprüfen muss, ob die Benutzerin oder der Benutzer berechtigt ist, bevor der Stream freigegeben wird.
3. Was ist eine Zulassungsentscheidung und wie lange ist sie gültig?
Der Begriff Autorisierung ist in der Glossar-Dokumentation definiert, während der Begriff Entscheidung auch im Glossar)ist.
Die Autorisierungsentscheidung speichert Informationen zum Abfrageergebnis des MVPD-Autorisierungsprozesses, die vom Entscheidungsautorisierungs-Endpunkt abgerufen werden können.
Die Client-Anwendung kann die Autorisierungsentscheidung mit einem Medien-Token verwenden, um den Ressourcen-Stream abzuspielen, falls die Entscheidung des TV-Anbieters (autorisierend) dem Benutzer den Zugriff darauf ermöglichen würde.
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Abrufen der Autorisierungsentscheidungen-API
- Grundlegender Autorisierungsfluss innerhalb der primären Anwendung
Die Autorisierungsentscheidung ist für einen begrenzten und kurzen Zeitraum gültig, der zum Zeitpunkt der Ausgabe angegeben ist. Dabei wird die Zeit angegeben, die von der Adobe Pass-Authentifizierung zwischengespeichert wird, bevor die MVPD erneut abgefragt werden muss.
Dieser begrenzte Zeitraum, der als Autorisierung (authZ) TTL bezeichnet wird, kann über das Adobe Pass TVE-Dashboardvon einem Ihrer Organisationsadministratoren oder einem in Ihrem Namen handelnden Adobe Pass-Authentifizierungsbeauftragten angezeigt und geändert werden.
Weitere Informationen finden Sie in der Dokumentation TVE Dashboard Integrations-Benutzerhandbuch.
4. Sollte die Client-Anwendung die Autorisierungsentscheidungen in einem persistenten Speicher zwischenspeichern?
Die Client-Anwendung ist nicht erforderlich, um Autorisierungsentscheidungen in einem persistenten Speicher zu speichern.
5. Wie kann der Kundenantrag feststellen, warum eine Autorisierungsentscheidung verweigert wurde?
Die Client-Anwendung kann den Grund für eine Entscheidung bezüglich der verweigerten Autorisierung ermitteln, indem sie den Fehlercode und die Nachricht) überprüft die in der Antwort vom Endpunkt Decisions Authorize enthalten sind. Diese Details geben insight den spezifischen Grund an, aus dem die Autorisierungsanfrage abgelehnt wurde. So kann das Benutzererlebnis oder der Trigger über die erforderliche Verarbeitung in der Anwendung informiert werden.
Stellen Sie sicher, dass ein zum Abrufen von Autorisierungsentscheidungen implementierter Wiederholungsmechanismus nicht zu einer Endlosschleife führt, wenn die Autorisierungsentscheidung abgelehnt wird.
Erwägen Sie, weitere Zustellversuche auf eine angemessene Anzahl zu beschränken und Ablehnungen elegant zu handhaben, indem Sie dem Benutzer klares Feedback senden.
6. Was ist ein Medien-Token und wie lange ist es gültig?
Das Medien-Token ist ein Begriff, der in der Dokumentation Glossar definiert ist.
Das Medien-Token besteht aus einer signierten Zeichenfolge, die als Klartext gesendet wird und vom Entscheidungsautorisierungs-Endpunkt abgerufen werden kann.
Weitere Informationen finden Sie in der Dokumentation Media Token Verifier .
Das Medien-Token ist für einen begrenzten und kurzen Zeitraum gültig, der zum Zeitpunkt der Ausgabe angegeben ist. Es gibt die Zeitspanne an, bevor es von der Client-Anwendung überprüft und verwendet werden muss.
Die Client-Anwendung kann das Medien-Token verwenden, um einen Ressourcen-Stream abzuspielen, falls die Entscheidung des TV-Anbieters (autoritär) dem Benutzer den Zugriff darauf ermöglichen würde.
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Abrufen der Autorisierungsentscheidungen-API
- Grundlegender Autorisierungsfluss innerhalb der primären Anwendung
7. Soll die Client-Anwendung das Medien-Token validieren, bevor der Ressourcen-Stream wiedergegeben wird?
Ja.
Die Client-Anwendung muss das Medien-Token validieren, bevor die Wiedergabe des Ressourcen-Streams gestartet wird. Diese Validierung sollte mit dem „Media Verifier“ durchgeführt. Durch die Überprüfung der serializedToken aus der zurückgegebenen token verhindert die Client-Anwendung nicht autorisierten Zugriff, wie z. B. das Stream-Ripping, und stellt sicher, dass nur ordnungsgemäß autorisierte Benutzer den Inhalt wiedergeben können.
8. Soll die Client-Anwendung während der Wiedergabe ein abgelaufenes Medien-Token aktualisieren?
Anzahl
Die Client-Anwendung ist nicht erforderlich, um ein abgelaufenes Medien-Token zu aktualisieren, während der Stream aktiv wiedergegeben wird. Wenn das Medien-Token während der Wiedergabe abläuft, sollte der Stream ununterbrochen fortgesetzt werden können. Der Client muss jedoch beim nächsten Versuch, eine Ressource abzuspielen, eine neue Autorisierungsentscheidung anfordern und ein neues Medien-Token abrufen.
9. Was ist der Zweck jedes Zeitstempelattributs in der Autorisierungsentscheidung?
Die Autorisierungsentscheidung enthält mehrere Zeitstempelattribute, die einen wesentlichen Kontext zur Gültigkeitsdauer der Autorisierung selbst und des zugehörigen Medien-Tokens bieten. Diese Zeitstempel dienen verschiedenen Zwecken, je nachdem, ob sie sich auf die Autorisierungsentscheidung oder das Medien-Token beziehen.
Zeitstempel auf Entscheidungsebene
Diese Zeitstempel beschreiben den Gültigkeitszeitraum der gesamten Autorisierungsentscheidung:
notBeforenotAfterZeitstempel auf Token-Ebene
Diese Zeitstempel beschreiben den Gültigkeitszeitraum des Medien-Tokens, das an die Autorisierungsentscheidung gebunden ist:
notBeforenotAfter10. Was ist eine Ressource und welche Formate werden unterstützt?
Die Ressource ist ein Begriff, der in der Dokumentation Glossar definiert ist.
Die Ressource ist eine eindeutige Kennung, die mit MVPDs vereinbart wird und mit einem Inhalt verknüpft ist, den die Client-Anwendung streamen könnte.
Die eindeutige Kennung der Ressource kann zwei Formate aufweisen:
- Ein einfaches Zeichenfolgenformat wie eine eindeutige Kennung für einen Kanal (eine Marke).
- Ein RSS-Format für Medien (MRSS), das zusätzliche Informationen wie Titel, Bewertungen und Metadaten zur elterlichen Kontrolle enthält.
Weitere Informationen finden Sie in der Dokumentation Geschützte Ressourcen .
11. Für wie viele Ressourcen kann die Client-Anwendung gleichzeitig eine Autorisierungsentscheidung erhalten?
Die Client-Anwendung kann in einer einzelnen API-Anfrage, in der Regel bis zu 1, eine Autorisierungsentscheidung für eine begrenzte Anzahl von Ressourcen erhalten. Dies ist auf die von MVPDs auferlegten Bedingungen zurückzuführen.
Häufig gestellte Fragen zur Abmeldephase
1. Was ist der Zweck der Abmeldephase?
Die Abmeldephase soll der Client-Anwendung die Möglichkeit geben, das authentifizierte Benutzerprofil innerhalb der Adobe Pass-Authentifizierung auf Benutzeranfrage zu beenden.
2. Ist die Abmeldephase obligatorisch?
Die Abmeldephase ist obligatorisch. Die Client-Anwendung muss dem Benutzer die Möglichkeit zum Abmelden bereitstellen.
Häufig gestellte Fragen zu Kopfzeilen
1. Wie wird der Wert für die Autorisierungs-Kopfzeile berechnet?
IMPORTANTBearer Zugriffstokens wie zuvor abzurufen.Der Autorisierungs-Anfrage-Header enthält das Bearer Zugriffstoken, das von der Client-Anwendung für den Zugriff auf durch Adobe Pass geschützte APIs benötigt wird.
Der Wert der Autorisierungs-Kopfzeile muss während der Registrierungsphase von der Adobe Pass-Authentifizierung abgerufen werden.
Weitere Informationen finden Sie in den folgenden Dokumenten:
- Übersicht über die dynamische Client-Registrierung
- Abrufen von Client-Anmeldeinformationen API
- Zugriffstoken-API abrufen
- Dynamischer Client-Registrierungsfluss
2. Wie wird der Wert für die Kopfzeile „AP-Device-Identifier“ berechnet?
IMPORTANTDer AP-Device-Identifier-Anforderungsheader enthält die Streaming-Gerätekennung, wie sie von der Client-Anwendung erstellt wurde.
Die Kopfzeilendokumentation AP-Device-Identifier enthält Beispiele für die wichtigsten Plattformen für die Berechnung des Werts, aber die Client-Anwendung kann basierend auf ihrer eigenen Geschäftslogik und ihren Anforderungen eine andere Methode verwenden.
3. Wie wird der Wert für den X-Device-Info-Header berechnet?
IMPORTANTDer X-Device-Info-Anfrage-Header enthält die Client-Informationen (Gerät, Verbindung und Anwendung), die sich auf das eigentliche Streaming-Gerät beziehen, und wird verwendet, um plattformspezifische Regeln zu bestimmen, die von MVPDs erzwungen werden können.
Die X-Device-Info-Header-Dokumentation enthält Beispiele für Hauptplattformen zur Berechnung des Werts, aber die Client-Anwendung kann basierend auf ihrer eigenen Geschäftslogik und ihren Anforderungen eine andere Methode verwenden.
Wenn der Header X-Device-Info fehlt oder falsche Werte enthält, kann die Anfrage als von einer unknown Plattform stammend klassifiziert werden.
Dies kann dazu führen, dass die Anfrage als unsicher behandelt wird und restriktiveren Regeln unterliegt, wie z. B. kürzeren Authentifizierungs-TTLs. Darüber hinaus sind einige Felder, wie die connectionIp und connectionPort des Streaming-Geräts, für Funktionen wie die „Home Base Authentication von Spectrum.
Selbst wenn die Anfrage im Auftrag eines Geräts von einem Server stammt, muss der X-Device-Info-Header-Wert die tatsächlichen Streaming-Geräteinformationen widerspiegeln.
Häufig gestellte Fragen (FAQ)
1. Kann ich REST API V2-Anfragen und -Antworten untersuchen und die API testen?
Ja.
Sie können die REST-API V2 über unsere spezielle Adobe Developer-Website erkunden. Die Adobe Developer-Website bietet uneingeschränkten Zugriff auf:
Um mit REST API V2 zu interagieren, müssen Sie den Authorization-Header mit einem Bearer Zugriffstoken einfügen, das über die DCR-API.
Für die Verwendung der DCR API ist eine Software-Anweisung mit dem REST API V2-Umfang erforderlich. Weitere Informationen finden Sie in den häufig gestellten zur Dynamic Client-Registrierung (DCR.
2. Kann ich REST API V2-Anfragen und -Antworten mithilfe eines API-Entwicklungs-Tools mit OpenAPI-Unterstützung durchsuchen?
Ja.
Sie können OpenAPI-Spezifikationsdateien für die DCR API und REST API V2 von der Adobe Developer-Website herunterladen.
Um die OpenAPI-Spezifikationsdateien herunterzuladen, klicken Sie auf die Download-Schaltflächen, um die folgenden Dateien auf Ihrem lokalen Computer zu speichern:
Sie können diese Dateien dann in Ihr bevorzugtes API-Entwicklungs-Tool importieren, um REST-API-V2-Anfragen und -Antworten zu untersuchen und die API zu testen.
3. Kann ich weiterhin das vorhandene API-Test-Tool verwenden, das unter https://sp.auth-staging.adobe.com/apitest/api.html gehostet wird?
Anzahl
Die Client-Programme, die zur REST API V2 migrieren, sollten das neue Test-Tool verwenden, das unter https://developer.adobe.com/adobe-pass/ gehostet wird. Die Adobe Developer-Website bietet uneingeschränkten Zugriff auf:
Um mit REST API V2 zu interagieren, müssen Sie den Authorization-Header mit einem Bearer Zugriffstoken einfügen, das über die DCR-API.
Für die Verwendung der DCR API ist eine Software-Anweisung mit dem REST API V2-Umfang erforderlich. Weitere Informationen finden Sie in den häufig gestellten zur Dynamic Client-Registrierung (DCR.
Häufig gestellte Fragen zur Migration
Fahren Sie mit diesem Abschnitt fort, wenn Sie an einem Programm arbeiten, das ein vorhandenes Programm zu REST API V2 migrieren muss.
Häufig gestellte Fragen zur allgemeinen Migration
1. Muss ich eine neue Client-Anwendung einführen, die zu REST API V2 migriert wurde, und zwar für alle Benutzer gleichzeitig?
Anzahl
Die Client-Anwendung ist nicht erforderlich, um eine neue Version einzuführen, die die REST-API V2 gleichzeitig für alle Benutzer integriert.
Die Adobe Pass-Authentifizierung unterstützt bis Ende 2025 weiterhin ältere Client-Anwendungsversionen, die die REST-API V1 oder SDK integrieren.
2. Muss ich eine neue Client-Anwendung einführen, die zur REST-API V2 über alle APIs und Flüsse hinweg gleichzeitig migriert wurde?
Ja.
Die Client-Anwendung ist erforderlich, um eine neue Version einzuführen, die die REST-API V2 über alle Adobe Pass-Authentifizierungs-APIs und -Flüsse hinweg gleichzeitig integriert.
Im Falle des Flusses „Authentifizierung auf dem zweiten Bildschirm“ ist die Client-Anwendung erforderlich, um eine neue Version einzuführen, die die REST-API V2 für die primären und sekundären-Anwendungen gleichzeitig integriert.
Die Adobe Pass-Authentifizierung unterstützt keine „hybriden“ Implementierungen, die sowohl die REST-API V2 als auch die REST-API V1/SDK zwischen APIs und Flüssen integrieren.
3. Wird die Benutzerauthentifizierung beim Aktualisieren auf eine neue Client-Anwendung beibehalten, die zur REST API V2 migriert wurde?
Anzahl
Die Benutzerauthentifizierung, die in älteren Client-Anwendungsversionen mit der REST-API V1 oder SDK erhalten wurde, wird nicht beibehalten.
Daher muss sich der Benutzer innerhalb der neuen Client-Anwendung, die zur REST-API V2 migriert wurde, erneut authentifizieren.
4. Sind die erweiterten Fehler-Codes in der REST-API V2 standardmäßig aktiviert?
Ja.
Die Client-Programme, die zur REST API V2 migrieren, profitieren standardmäßig automatisch von dieser Funktion und bieten detailliertere und präzisere Fehlerinformationen.
Weitere Informationen finden Sie in der Dokumentation Erweiterte).
5. Benötigen bestehende Integrationen bei der Migration auf REST API V2 Konfigurationsänderungen?
Anzahl
Für die Client-Programme, die zur REST API V2 migrieren, sind keine Konfigurationsänderungen für bestehende MVPD-Integrationen erforderlich. Außerdem werden sie weiterhin dieselben Kennungen für bestehende Dienstleister und MVPDs verwenden.
Darüber hinaus bleiben die Protokolle, die von der Adobe Pass-Authentifizierung zur Kommunikation mit MVPD-Endpunkten verwendet werden, unverändert.
Migration von der REST API V1 zur REST API V2
Fahren Sie mit diesem Unterabschnitt fort, wenn Sie an einem Programm arbeiten, das von REST API V1 zu REST API V2 migriert werden muss.
Häufig gestellte Fragen zur Registrierungsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Registrierungsphase erforderlich?
Bei der Migration von REST API V1 zu REST API V2 gibt es keine allgemeinen Änderungen in Bezug auf die Registrierungsphase.
Die Client-Anwendung kann denselben Fluss weiterhin verwenden, um sich über den Dynamische Client-Registrierung (DCR) bei der Adobe PassAuthentifizierung zu registrieren und ein Zugriffstoken zu erhalten.
Weitere Informationen finden Sie in den folgenden Dokumenten:
Häufig gestellte Fragen zur Konfigurationsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Konfigurationsphase erforderlich?
Bei der Migration von REST API V1 zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in der folgenden Tabelle aufgeführt sind:
Häufig gestellte Fragen zur Authentifizierungsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Authentifizierungsphase erforderlich?
Bei der Migration von REST API V1 zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in der folgenden Tabelle aufgeführt sind:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
Häufig gestellte Fragen zur Vorautorisierungsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Vorautorisierungsphase erforderlich?
Bei der Migration von REST API V1 zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in der folgenden Tabelle aufgeführt sind:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Häufig gestellte Fragen zur Genehmigungsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Autorisierungsphase erforderlich?
Bei der Migration von REST API V1 zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in der folgenden Tabelle aufgeführt sind:
Die Client-Anwendung kann die Antwort dieser API für mehrere Zwecke gleichzeitig verwenden:
- (MVPD)-Autorisierung initiieren
- Autorisierungsentscheidung abrufen
- Abrufen eines kurzen Medien-Tokens
Weitere Informationen finden Sie in den folgenden Dokumenten:
Die Client-Anwendung kann die Antwort dieser API für mehrere Zwecke gleichzeitig verwenden:
- (MVPD)-Autorisierung initiieren
- Autorisierungsentscheidung abrufen
- Abrufen eines kurzen Medien-Tokens
Weitere Informationen finden Sie in den folgenden Dokumenten:
Die Client-Anwendung kann die Antwort dieser API für mehrere Zwecke gleichzeitig verwenden:
- (MVPD)-Autorisierung initiieren
- Autorisierungsentscheidung abrufen
- Abrufen eines kurzen Medien-Tokens
Weitere Informationen finden Sie in den folgenden Dokumenten:
Häufig gestellte Fragen zur Abmeldephase
1. Welche API-Migrationen auf hoher Ebene sind für die Abmeldephase erforderlich?
Bei der Migration von REST API V1 zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in der folgenden Tabelle aufgeführt sind:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Migration von SDK zur REST-API V2
Fahren Sie mit diesem Unterabschnitt fort, wenn Sie an einem Programm arbeiten, das von SDK zu REST API V2 migriert werden muss.
Häufig gestellte Fragen zur Registrierungsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Registrierungsphase erforderlich?
Bei der Migration von SDKs zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in den folgenden Tabellen aufgeführt sind:
AccessEnabler JavaScript SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler iOS/tvOS SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler Android SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler FireOS SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
Häufig gestellte Fragen zur Konfigurationsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Konfigurationsphase erforderlich?
Bei der Migration von SDKs zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in den folgenden Tabellen aufgeführt sind:
AccessEnabler JavaScript SDK
AccessEnabler iOS/tvOS SDK
AccessEnabler Android SDK
AccessEnabler FireOS SDK
Häufig gestellte Fragen zur Authentifizierungsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Authentifizierungsphase erforderlich?
Bei der Migration von SDKs zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in den folgenden Tabellen aufgeführt sind:
AccessEnabler JavaScript SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler iOS SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler tvOS SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler Android SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler FireOS SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
GET
/api/v2/{serviceProvider}/profiles
GET
/api/v2/{serviceProvider}/profiles/{mvpd}
GET
/api/v2/{serviceProvider}/profiles/code/{code}
Die Client-Anwendung kann die Antwort dieser APIs für mehrere Zwecke gleichzeitig verwenden:
- Überprüfen des Benutzerauthentifizierungsstatus
- Abrufen von Benutzerprofilen
- Abrufen von Benutzermetadaten-Informationen
Weitere Informationen finden Sie in den folgenden Dokumenten:
Häufig gestellte Fragen zur Vorautorisierungsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Vorautorisierungsphase erforderlich?
Bei der Migration von SDKs zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in den folgenden Tabellen aufgeführt sind:
AccessEnabler JavaScript SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler iOS/tvOS SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler Android SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
Weitere Informationen finden Sie in den folgenden Dokumenten:
Häufig gestellte Fragen zur Genehmigungsphase
1. Welche API-Migrationen auf hoher Ebene sind für die Autorisierungsphase erforderlich?
Bei der Migration von SDKs zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in den folgenden Tabellen aufgeführt sind:
AccessEnabler JavaScript SDK
Die Client-Anwendung kann die Antwort dieser API für mehrere Zwecke gleichzeitig verwenden:
- (MVPD)-Autorisierung initiieren
- Autorisierungsentscheidung abrufen
- Abrufen eines kurzen Medien-Tokens
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler iOS/tvOS SDK
Die Client-Anwendung kann die Antwort dieser API für mehrere Zwecke gleichzeitig verwenden:
- (MVPD)-Autorisierung initiieren
- Autorisierungsentscheidung abrufen
- Abrufen eines kurzen Medien-Tokens
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler Android SDK
Die Client-Anwendung kann die Antwort dieser API für mehrere Zwecke gleichzeitig verwenden:
- (MVPD)-Autorisierung initiieren
- Autorisierungsentscheidung abrufen
- Abrufen eines kurzen Medien-Tokens
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler FireOS SDK
Die Client-Anwendung kann die Antwort dieser API für mehrere Zwecke gleichzeitig verwenden:
- (MVPD)-Autorisierung initiieren
- Autorisierungsentscheidung abrufen
- Abrufen eines kurzen Medien-Tokens
Weitere Informationen finden Sie in den folgenden Dokumenten:
Häufig gestellte Fragen zur Abmeldephase
1. Welche API-Migrationen auf hoher Ebene sind für die Abmeldephase erforderlich?
Bei der Migration von SDKs zu REST API V2 sind wichtige Änderungen zu berücksichtigen, die in den folgenden Tabellen aufgeführt sind:
AccessEnabler JavaScript SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler iOS/tvOS SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler Android SDK
Weitere Informationen finden Sie in den folgenden Dokumenten:
AccessEnabler FireOS SDK
Weitere Informationen finden Sie in den folgenden Dokumenten: