REST API V2 の FAQ rest-api-v2-faqs
このドキュメントでは、Adobe Pass認証 REST API V2 の導入に関するよくある質問に対する概要の回答を示します。
REST API V2 全体について詳しくは、REST API V2 の概要ドキュメントを参照してください。
一般的な FAQ general-faqs
REST API V1} またはSDK から移行する新規または既存のアプリケーションにかかわらず、REST API V2 を統合する必要があるアプリケーションを使用している場合は、この節から開始しください。
移行の詳細と手順については、次の節も参照してください。
登録フェーズに関するよくある質問 registration-phase-faqs-general
設定フェーズの FAQ configuration-phase-faqs-general
1.設定フェーズの目的は何ですか？ configuration-phase-faq1
設定フェーズの目的は、MVPDごとにAdobe Pass Authentication によって保存された設定の詳細（id、displayName、logoUrl など）と、アクティブに統合される MVPD のリストをクライアントアプリケーションに提供することです。
設定フェーズは、クライアントアプリケーションがユーザーに TV プロバイダーの選択を依頼する必要がある場合に、認証フェーズの前提条件の手順として機能します。
2.設定フェーズは必須ですか？ configuration-phase-faq2
設定フェーズは必須ではありません。クライアントアプリケーションは、認証または再認証のためにMVPDを選択する必要がある場合にのみ、設定を取得する必要があります。
クライアントアプリケーションは、次のシナリオでは、このフェーズをスキップできます。
- ユーザーは既に認証済みです。
- ユーザーは、基本的またはプロモーションの TempPass 機能を通じて一時的なアクセスが提供されます。
- ユーザー認証の有効期限が切れているが、クライアントアプリケーションは、以前に選択したMVPDをユーザーエクスペリエンスの動機に基づく選択としてキャッシュし、まだMVPDの購読者であることを確認するように求めるだけです。
3.設定とは何で、どれくらい有効ですか？ configuration-phase-faq3
設定とは、Glossary ドキュメントで定義されている用語です。
設定には、idConfigurationdisplayName エンドポイントから取得できる、次の属性 logoUrl、、 などで定義された MVPD のリストが含まれています。
クライアントアプリケーションは、ユーザーが認証または再認証のためにMVPDを選択する必要がある場合にのみ、設定を取得する必要があります。
クライアントアプリケーションは、設定応答を使用して、ユーザーがテレビプロバイダーを選択する必要があるときに、使用可能なMVPD オプションを UI ピッカーに表示できます。
クライアントアプリケーションは、認証、事前認証、認証、ログアウトの各フェーズに進むために、MVPDの configuration-level id 属性で指定された、ユーザーの選択したMVPD ID を保存する必要があります。
詳しくは、 設定の取得ドキュメントを参照してください。
4. クライアントアプリケーションは、永続的なストレージに設定応答情報をキャッシュする必要がありますか？ configuration-phase-faq4
クライアントアプリケーションは、ユーザーが認証または再認証のためにMVPDを選択する必要がある場合にのみ、設定を取得する必要があります。
次の場合に、クライアントアプリケーションは設定応答情報をメモリストレージにキャッシュして、不要なリクエストを回避し、ユーザーエクスペリエンスを向上させる必要があります。
- ユーザーは既に認証済みです。
- ユーザーは、基本的またはプロモーションの TempPass 機能を通じて一時的なアクセスが提供されます。
- ユーザー認証の有効期限が切れているが、クライアントアプリケーションは、以前に選択したMVPDをユーザーエクスペリエンスの動機に基づく選択としてキャッシュし、まだMVPDの購読者であることを確認するように求めるだけです。
5. クライアントアプリケーションは、独自の MVPD リストを管理できますか。 configuration-phase-faq5
クライアントアプリケーションは MVPD の独自のリストを管理できますが、MVPD ID とAdobe Pass Authentication を同期させる必要があります。 そのため、Adobe Pass Authentication から提供される設定を使用して、リストを最新かつ正確にすることをお勧めします。
指定されたAdobe Pass ID が無効な場合や、指定された サービスプロバイダーとのアクティブな統合がない場合、クライアントアプリケーションはMVPD認証 REST API V2 から エラーを受け取ります。
6. クライアントアプリケーションは MVPD のリストをフィルタリングできますか。 configuration-phase-faq6
クライアントアプリケーションは、独自のビジネスロジックおよび要件（以前に選択したユーザーの場所やユーザーの履歴など）に基づいてカスタムメカニズムを実装することで、設定応答で提供される MVPD のリストをフィルタリングできます。
クライアントアプリケーションは、開発中またはテスト中の統合を持つ TempPass MVPD または MVPD のリストをフィルタリングできます。
7. MVPDとの統合が無効になり、非アクティブとしてマークされた場合、どうなりますか？ configuration-phase-faq7
MVPDとの統合が無効で非アクティブとしてマークされている場合、MVPDは、以降の設定応答で提供される MVPD のリストから削除されます。考慮すべき重要な結果が 2 つあります。
- そのMVPDの認証されていないユーザーは、そのMVPDを使用して認証フェーズを完了できなくなります。
- そのMVPDの認証済みユーザーは、そのMVPDを使用して事前認証、認証、ログアウトの各フェーズを実行できなくなります。
選択したMVPDが指定の サービスプロバイダーとのアクティブな統合を持たなくなった場合、クライアントアプリケーションはAdobe Pass認証 REST API V2 から エラーを受け取ります。
8. MVPDとの統合が有効になり、アクティブとしてマークされた場合、どうなりますか？ configuration-phase-faq8
MVPDとの統合が有効になり、アクティブとしてマークされると、MVPDは、以降の設定応答で提供される MVPD のリストに戻されます。考慮すべき重要な結果は 2 つあります。
- そのMVPDの認証されていないユーザーは、そのMVPDを使用して認証フェーズを再び完了できます。
- そのMVPDの認証済みユーザーは、そのMVPDを使用して、事前認証、認証、ログアウトの各フェーズを再び完了できます。
9. MVPDとの統合を有効または無効にする方法 configuration-phase-faq9
この操作は、組織管理者の 1 人がAdobe PassTVE ダッシュボードを使用して、またはお客様に代わってAdobe Pass認証担当者が実行できます。
詳しくは、TVE ダッシュボード統合ユーザーガイドドキュメントを参照してください。
認証フェーズの FAQ authentication-phase-faqs-general
1.認証段階の目的は何ですか。 authentication-phase-faq1
認証フェーズの目的は、クライアントアプリケーションにユーザーの ID を検証し、ユーザーメタデータ情報を取得する機能を提供することです。
認証フェーズは、クライアントアプリケーションでコンテンツを再生する必要がある場合に、事前認証フェーズまたは認証フェーズの前提条件の手順として機能します。
2.認証フェーズは必須ですか？ authentication-phase-faq2
認証フェーズは必須です。クライアントアプリケーションでは、Adobe Pass Authentication 内に有効なプロファイルがない場合、ユーザーの認証を行う必要があります。
クライアントアプリケーションは、次のシナリオでは、このフェーズをスキップできます。
- ユーザーは既に認証済みで、プロファイルは引き続き有効です。
- ユーザーは、基本的またはプロモーションの TempPass 機能を通じて一時的なアクセスが提供されます。
クライアントアプリケーションのエラー処理では、 エラーコード（authenticated_profile_missing、authenticated_profile_expired、authenticated_profile_invalidated など）を処理する必要があります。これは、クライアントアプリケーションがユーザーの認証を必要とすることを示します。
3.認証セッションとは何で、どれくらい有効ですか。 authentication-phase-faq3
認証セッションとは、Glossary ドキュメントで定義されている用語です。
認証セッションには、セッション エンドポイントから取得できる、開始された認証プロセスに関する情報が格納されます。
認証セッションは、発行の時点で notAfter タイムスタンプによって指定された、限られた短い期間にわたって有効です。これは、ユーザーが認証プロセスを完了してからフローを再開する必要が生じるまでの時間を示します。
クライアントアプリケーションは、認証セッション応答を使用して、認証プロセスの進め方を知ることができます。 一時的なアクセスの提供、アクセスの低下、ユーザーが既に認証されている場合など、ユーザーの認証が不要な場合があることに注意してください。
詳しくは、次のドキュメントを参照してください。
4.認証コードとは何で、どれくらい有効ですか？ authentication-phase-faq4
認証コードとは、Glossary ドキュメントで定義されている用語です。
認証コードは、ユーザが認証プロセスを開始する際に生成される一意の値を格納し、プロセスが完了するまで、または認証セッションが期限切れになるまで、ユーザの認証セッションを一意に識別する。
認証コードは、notAfter タイムスタンプによって認証セッションを開始する時点で指定された、制限された短い期間にわたって有効です。これは、ユーザーが認証プロセスを完了してからフローを再開する必要が生じるまでの時間を示します。
クライアントアプリケーションは認証コードを使用して、ユーザーが正常に認証を完了したかどうかを確認し、通常はポーリングメカニズムを介してユーザーのプロファイル情報を取得できます。
また、クライアントアプリケーションは認証コードを使用して、ユーザーが認証セッションの有効期限が切れていないことを考慮して、同じデバイスまたは 2 番目のデバイス（画面）で認証プロセスを完了または再開できるようにします。
詳しくは、次のドキュメントを参照してください。
5. ユーザーが有効な認証コードを入力し、認証セッションがまだ期限切れになっていないことをクライアントアプリケーションが認識するにはどうすればよいですか？ authentication-phase-faq5
クライアントアプリケーションは、認証セッションの再開または認証コードに関連する認証セッション情報の取得を担当するセッションエンドポイントの 1 つにリクエストを送信することにより、セカンダリ（画面）アプリケーションにおいてユーザーによって入力された認証コードを検証できる。
指定された認証コードが正しく入力されなかった場合、または認証セッションが期限切れになった場合、クライアントアプリケーションは エラーを受け取ります。
詳しくは、 認証セッションの再開および 認証セッションの取得ドキュメントを参照してください。
6. ユーザーが既に認証されているかどうかをクライアントアプリケーションが認識するにはどうすればよいですか？ authentication-phase-faq6
クライアントアプリケーションは、ユーザーが既に認証されているかどうかを確認できる次のエンドポイントのいずれかをクエリし、プロファイル情報を返すことができます。
詳しくは、次のドキュメントを参照してください。
7. プロファイルとは何で、どれくらい有効ですか？ authentication-phase-faq7
プロファイルとは、Glossary ドキュメントで定義されている用語です。
プロファイルには、ユーザーの認証の有効性、メタデータ情報など、プロファイルエンドポイントから取得できる多くの情報が保存されます。
クライアントアプリケーションはプロファイルを使用して、ユーザーの認証ステータスの把握、ユーザーメタデータ情報へのアクセス、認証に使用する方法の検索、ID の提供に使用するエンティティの検索を行うことができます。
詳しくは、次のドキュメントを参照してください。
- プロファイルエンドポイント API
- 特定のMVPD API のプロファイルエンドポイント
- 特定（認証）コード API 用プロファイルエンドポイント
- プライマリアプリケーション内で実行される基本プロファイルフロー
- セカンダリアプリケーション内で実行される基本プロファイルフロー
プロファイルは、notAfter タイムスタンプでクエリされる際に指定された限られた期間にわたって有効です。これは、ユーザーが認証フェーズを再度通過する必要があるまでに有効な認証を受けた時間を示します。
この制限された期間は、認証（authN） TTL と呼ばれ、組織管理者の 1 人またはユーザーに代わってAdobe Pass認証担当者が、Adobe PassTVE ダッシュボードを通じて表示および変更できます。
詳しくは、TVE ダッシュボード統合ユーザーガイドドキュメントを参照してください。
8. クライアントアプリケーションは、ユーザーのプロファイル情報を永続的なストレージにキャッシュする必要がありますか？ authentication-phase-faq8
クライアントアプリケーションは、次の側面を考慮して、ユーザーのプロファイル情報の一部を永続的なストレージにキャッシュして、不要なリクエストを避け、ユーザーエクスペリエンスを向上させる必要があります。
| table 0-row-2 1-row-2 2-row-2 3-row-2 | |
|---|---|
| 属性 | ユーザーエクスペリエンス |
mvpd |
クライアントアプリケーションは、これを使用してユーザーが選択したテレビプロバイダーを追跡し、事前認証または認証フェーズ中にさらに使用できます。 現在のユーザープロファイルの有効期限が切れると、クライアントアプリケーションは記憶されているMVPDの選択内容を使用し、ユーザーに確認を求めることができます。 |
attributes |
クライアントアプリケーションはこれを使用して、様々な ユーザーメタデータキー（zip、maxRating など）に基づいてユーザーエクスペリエンスをパーソナライズできます。ユーザーメタデータは認証フローが完了すると使用できるようになります。したがって、 ユーザーメタデータ情報は既にプロファイル情報に含まれているため、クライアントアプリケーションは別のエンドポイントに対してクエリを実行して、情報を取得する必要はありません。 特定のメタデータ属性は、MVPDと特定のメタデータ属性に応じて、認証フロー中に更新される場合があります。 その結果、最新のユーザーメタデータを取得するために、クライアントアプリケーションがプロファイル API を再度クエリする必要が生じる場合があります。 |
notAfter |
クライアントアプリケーションはこれを使用して、ユーザープロファイルの有効期限を追跡できます。 クライアントアプリケーションのエラー処理では、 エラーコード（ authenticated_profile_missing、authenticated_profile_expired、authenticated_profile_invalidated など）を処理する必要があります。これは、クライアントアプリケーションでユーザーの認証が必要であることを示します。 |
9. クライアントアプリケーションは、再認証を必要とせずにユーザープロファイルを拡張できますか。 authentication-phase-faq9
いいえ。
ユーザープロファイルの有効期限は、MVPD で確立された認証 TTL によって決定されるので、ユーザーの操作なしにユーザープロファイルを有効期限を超えて拡張することはできません。
そのため、クライアントアプリケーションは、MVPD ログインページを再認証および操作して、システム上のプロファイルを更新するようにユーザーに求める必要があります。
ただし、HBA （ホーム・ベースの認証をサポートする MVPD の場合、ユーザーは認証情報を入力する必要はありません。
10.使用可能な各プロファイルエンドポイントのユースケースは何ですか？ authentication-phase-faq10
基本プロファイルエンドポイントは、ユーザーの認証ステータスの把握、ユーザーメタデータ情報へのアクセス、認証に使用される方法の検索、ID の提供に使用されるエンティティの検索をおこなえる機能をクライアントアプリケーションに提供するように設計されています。
各エンドポイントは、次のように特定のユースケースに適しています。
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| API | 説明 | ユースケース |
| プロファイルエンドポイント API | すべてのユーザープロファイルを取得します。 | クライアントアプリケーションを初めて開く このシナリオでは、クライアントアプリケーションには、選択したMVPD識別子が永続ストレージにキャッシュされていません。 その結果、使用可能なすべてのユーザープロファイルを取得するリクエストが 1 回送信されます。 |
| 特定のMVPD API のプロファイルエンドポイント | 特定のMVPDに関連付けられているユーザープロファイルを取得します。 | 前回の訪問で認証した後、クライアントアプリケーションに戻る。 この場合、クライアントアプリケーションには、ユーザーが以前選択したMVPD識別子が、永続的なストレージにキャッシュされている必要があります。 その結果、その特定のMVPDのユーザーのプロファイルを取得するリクエストが 1 回送信されます。 |
| 特定（認証）コード API 用プロファイルエンドポイント | 特定の認証コードに関連付けられているユーザープロファイルを取得します。 | ユーザーが認証プロセスを開始 このシナリオでは、クライアントアプリケーションは、ユーザーが正常に認証を完了したかどうかを判断し、ユーザーのプロファイル情報を取得する必要があります。 その結果、ポーリングメカニズムが開始され、認証コードに関連付けられたユーザーのプロファイルを取得します。 |
詳しくは、 プライマリアプリケーション内で実行される基本プロファイルフローおよび セカンダリアプリケーション内で実行される基本プロファイルフロードキュメントを参照してください。
プロファイル SSO エンドポイントは、様々な目的を果たします。パートナー認証応答を使用してユーザープロファイルを作成し、1 回の操作で取得する機能をクライアントアプリケーションに提供します。
| table 0-row-3 1-row-3 | ||
|---|---|---|
| API | 説明 | ユースケース |
| プロファイル SSO エンドポイント API | パートナー認証応答を使用してユーザープロファイルを作成および取得します。 | ユーザーが、認証にパートナーのシングルサインオンを使用することをアプリケーションに許可する このシナリオでは、クライアントアプリケーションはパートナー認証応答を受信した後にユーザープロファイルを作成し、1 回の操作で取得する必要があります。 |
以降のクエリでは、基本プロファイルエンドポイントを使用して、ユーザーの認証ステータスの判断、ユーザーメタデータ情報へのアクセス、認証に使用する方法の検索、ID の提供に使用するエンティティの検索を行う必要があります。
詳しくは、 パートナーフローを使用したシングルサインオンおよび Apple SSO クックブック（REST API V2）ドキュメントを参照してください。
11. ユーザーに複数のMVPD プロファイルがある場合、クライアントアプリケーションは何を行いますか？ authentication-phase-faq11
複数のプロファイルをサポートするかどうかは、クライアントアプリケーションのビジネス要件によって決まります。
ほとんどのユーザーは、1 つのプロファイルしか持ちません。 ただし、（以下で詳しく説明するように）複数のプロファイルが存在する場合、クライアントアプリケーションは、プロファイル選択に最適なユーザーエクスペリエンスを決定する責任を負います。
クライアントアプリケーションは、応答から最初のユーザープロファイルを選択するか、有効期間が最も長いプロファイルを選択するかのように、目的のMVPD プロファイルを選択するようにユーザーに求めるか、自動的に選択するかを選択できます。
REST API v2 は、次の要件に対応するために複数のプロファイルをサポートしています。
- 通常のMVPD プロファイルと、シングルサインオン（SSO）を介して取得したプロファイルのいずれかを選択する必要がある場合のユーザー。
- 通常のMVPDからログアウトしなくても、一時的なアクセスが提供されるユーザー。
- MVPD サブスクリプションを Direct-to-Consumer （DTC） サービスと組み合わせたユーザー。
- 複数のMVPD サブスクリプションを持つユーザー。
12. ユーザープロファイルが期限切れになるとどうなりますか？ authentication-phase-faq12
ユーザープロファイルの有効期限が切れると、プロファイルエンドポイントからの応答に含まれなくなります。
プロファイルエンドポイントが空のプロファイルマップ応答を返した場合、クライアントアプリケーションは新しい認証セッションを作成し、ユーザーに再認証を促す必要があります。
詳しくは、 認証セッション API の作成ドキュメントを参照してください。
13. ユーザープロファイルが無効になるのはいつですか？ authentication-phase-faq13
ユーザープロファイルが無効になるのは、次の場合です。
- プロファイルエンドポイント応答の
notAfterタイムスタンプで示されるように、認証 TTL の有効期限が切れるタイミング。 - クライアントアプリケーションが AP-Device-Identifier ヘッダー値を変更する場合。
- クライアントアプリケーションが Authorization ヘッダー値の取得に使用されるクライアント資格情報を更新する場合。
- クライアント アプリケーションが、クライアント資格情報の取得に使用するソフトウェア ステートメントを失効または更新したとき。
14. クライアントアプリケーションは、ポーリングメカニズムをいつ開始する必要がありますか？ authentication-phase-faq14
効率を確保し、不要なリクエストを避けるために、クライアントアプリケーションは次の条件下でポーリングメカニズムを開始する必要があります。
プライマリ（画面）アプリケーション内で実行される認証
プライマリ（ストリーミング）アプリケーションでは、ユーザーが最終的な宛先ページに到達すると、ブラウザーコンポーネントが、redirectUrl セッション エンドポイントリクエストのパラメーターに指定された URL を読み込んだ後に、ポーリングを開始する必要があります。
セカンダリ（画面）アプリケーション内で実行される認証
プライマリ（ストリーミング）アプリケーションでは、ユーザーが認証プロセスを開始するとすぐに、つまり、 セッションエンドポイントの応答を受信して認証コードをユーザーに表示した直後に、ポーリングを開始する必要があります。
15. クライアントアプリケーションは、いつポーリングメカニズムを停止する必要がありますか。 authentication-phase-faq15
効率を確保し、不要なリクエストを避けるために、クライアントアプリケーションは次の条件でポーリングメカニズムを停止する必要があります。
認証に成功
ユーザーのプロファイル情報は正常に取得され、ユーザーの認証ステータスが確認されます。 この時点で、ポーリングは不要になります。
認証セッションとコードの有効期限
notAfter セッション エンドポイント応答のタイムスタンプ （例：30 分）に示されているように、認証セッションとコードの有効期限が切れます。 この場合、ユーザーは認証プロセスを再起動する必要があり、以前の認証コードを使用したポーリングは直ちに停止する必要があります。
新しい認証コードが生成されました
ユーザーがプライマリ（画面）デバイスで新しい認証コードを要求すると、既存のセッションは無効になり、以前の認証コードを使用したポーリングを直ちに停止する必要があります。
16. クライアントアプリケーションは、呼び出しの間隔にどの程度ポーリングメカニズムを使用する必要がありますか？ authentication-phase-faq16
効率を確保し、不要なリクエストを避けるために、クライアントアプリケーションは次の条件下でポーリングメカニズムの頻度を設定する必要があります。
| table 0-row-2 1-row-2 | |
|---|---|
| プライマリ（画面）アプリケーション内で実行される認証 | セカンダリ（画面）アプリケーション内で実行される認証 |
| プライマリ（ストリーミング）アプリケーションは、3 ～ 5 秒以上ごとにポーリングする必要があります。 | プライマリ（ストリーミング）アプリケーションは、3 ～ 5 秒以上ごとにポーリングする必要があります。 |
17. クライアントアプリケーションが送信できるポーリング要求の最大数はいくつですか。 authentication-phase-faq17
クライアントアプリケーションは、Adobe Pass認証 スロットルメカニズムで定義された現在の制限に準拠する必要があります。
クライアントアプリケーションエラー処理では、クライアントアプリケーションが許可されているリクエストの最大数を超えたことを示す 429 Too Many Requests エラーコードを処理できる必要があります。
詳しくは、「スロットルメカニズム のドキュメントを参照しください。
18. クライアントアプリケーションは、ユーザーのメタデータ情報をどのように取得できますか。 authentication-phase-faq18
クライアントアプリケーションは、プロファイル情報の一部として ユーザーメタデータ情報を返すことができる次のエンドポイントのいずれかをクエリできます。
ユーザーメタデータは認証フローが完了すると使用できるようになります。したがって、 ユーザーメタデータ情報は既にプロファイル情報に含まれているため、クライアントアプリケーションで個別のエンドポイントをクエリして取得する必要はありません。
詳しくは、次のドキュメントを参照してください。
MVPDと特定のメタデータ属性に応じて、特定のメタデータ属性を認証フロー中に更新できます。 その結果、最新のユーザーメタデータを取得するには、クライアントアプリケーションが上記の API を再度クエリする必要が生じる場合があります。
19. クライアント・アプリケーションは、縮退アクセスをどのように管理する必要がありますか。 authentication-phase-faq19
最適化機能を使用すると、クライアントアプリケーションは、MVPDの認証サービスや承認サービスで問題が発生した場合でも、ユーザーのシームレスなストリーミングエクスペリエンスを維持できます。
要約すると、MVPDの一時的なサービス停止にもかかわらず、コンテンツへのアクセスが中断されないようにすることができます。
組織がプレミアム劣化機能を使用する予定であることを考慮すると、クライアントアプリケーションは、劣化したアクセスフローを処理する必要があります。これは、このようなシナリオで REST API v2 エンドポイントがどのように動作するかについて概要を説明しています。
詳しくは、「アクセス フローの低下 のドキュメントを参照しください。
20. クライアントアプリケーションは、一時的なアクセスをどのように管理する必要がありますか？ authentication-phase-faq20
TempPass 機能を使用すると、クライアントアプリケーションからユーザーへの一時的なアクセスを提供できます。
要約すると、指定した期間、コンテンツまたは事前定義済みの数のVOD タイトルへの時間限定アクセスを提供することで、ユーザーを引き付けることができます。
組織がプレミアム TempPass 機能を使用する予定であることを考慮すると、クライアントアプリケーションは、このようなシナリオで REST API v2 エンドポイントがどのように動作するかについて説明した、一時的なアクセスフローを処理する必要があります。
以前の API バージョンでは、一時的なアクセスを提供するために、クライアントアプリケーションは、通常のMVPDで認証されたユーザーをログアウトする必要がありました。
REST API v2 を使用すると、クライアントアプリケーションは、ストリームの認証時に通常のMVPDと TempPass MVPDをシームレスに切り替えることができ、ユーザーがログアウトする必要がなくなります。
詳しくは、 一時的なアクセスフロードキュメントを参照してください。
21. クライアントアプリケーションは、クロスデバイスのシングルサインオンアクセスをどのように管理する必要がありますか？ authentication-phase-faq21
クライアントアプリケーションがデバイス間で一貫した一意のユーザー ID を提供する場合、REST API v2 はクロスデバイスのシングルサインオンを有効にできます。
この識別子はサービストークンと呼ばれ、任意の外部 ID サービスの実装または統合を通じて、クライアントアプリケーションによって生成される必要があります。
詳しくは、 サービストークンフローを使用したシングルサインオンドキュメントを参照してください。
事前認証フェーズの FAQ preauthorization-phase-faqs-general
1.事前認証フェーズの目的は何ですか。 preauthorization-phase-faq1
事前認証フェーズの目的は、ユーザーがアクセスする権利を持つカタログからリソースのサブセットをクライアントアプリケーションに提示できるようにすることです。
事前認証フェーズでは、ユーザーが初めてクライアントアプリケーションを開いた場合や、新しいセクションに移動した場合のユーザーエクスペリエンスが向上します。
2.事前認証フェーズは必須ですか？ preauthorization-phase-faq2
事前認証フェーズは必須ではありません。クライアントアプリケーションは、ユーザーの使用権限に基づいて最初にリソースのカタログをフィルタリングせずに提示する場合は、このフェーズをスキップできます。
3.事前認証の決定とは？ preauthorization-phase-faq3
事前認証は、 用語集ドキュメントで定義されている用語ですが、決定用語は 用語集にも記載されています。
事前認証決定は、決定の事前認証エンドポイントから取得できる、MVPDの事前認証プロセスの問い合わせ結果に関する情報を格納します。
クライアントアプリケーションは、事前認証決定を使用して、ユーザーがアクセスできるリソースのサブセットを TV プロバイダー（情報）決定で提示できます。
詳しくは、次のドキュメントを参照してください。
4. クライアントアプリケーションは、永続的なストレージに事前認証決定をキャッシュする必要がありますか？ preauthorization-phase-faq4
クライアントアプリケーションは、永続的なストレージに事前認証の決定を保存する必要はありません。 ただし、ユーザーエクスペリエンスを向上させるために、許可決定をメモリにキャッシュすることをお勧めします。 これにより、既に事前認証されているリソースに対して、決定の事前認証エンドポイントへの不要な呼び出しが回避され、待ち時間が短縮され、パフォーマンスが向上します。
5. クライアントアプリケーションは、事前認証の決定が拒否された理由をどのように判断できますか？ preauthorization-phase-faq5
クライアントアプリケーションは、決定の事前承認エンドポイントからの応答に含まれる エラーコードとメッセージを調べることで、拒否された事前承認の決定の理由を判断できます。 これらの詳細により、事前認証リクエストが拒否された具体的な理由がinsightに提供され、アプリケーションでの必要な処理をユーザーエクスペリエンスやトリガーに伝えるのに役立ちます。
事前認証の決定を取得するために実装された再試行メカニズムが、事前認証の決定が拒否された場合に無限ループが発生しないことを確認します。
再試行を適切な数に制限し、ユーザーに明確なフィードバックを表示して、拒否を適切に処理することを検討してください。
6.事前認証決定にメディアトークンがないのはなぜですか？ preauthorization-phase-faq6
事前認証フェーズの目的と同様に、事前認証フェーズをリソースの再生に使用してはならないので、事前認証決定にメディアトークンがありません。
7.事前認証決定が既に存在する場合、認証フェーズはスキップできますか？ preauthorization-phase-faq7
いいえ。
事前認証決定が使用可能な場合でも、認証フェーズはスキップできません。 事前認証の決定は情報提供のみで、実際の再生権限は付与されません。 事前認証フェーズは、初期のガイダンスを提供することを目的としていますが、コンテンツを再生する前には引き続き認証フェーズが必要です。
8. リソースとは何ですか？また、どのような形式がサポートされていますか？ preauthorization-phase-faq8
リソースとは、Glossary ドキュメントで定義されている用語です。
リソースは、MVPD と合意された一意の識別子で、クライアントアプリケーションによってストリーミングされる可能性のあるコンテンツに関連付けられます。
リソースの一意の ID には、次の 2 つの形式があります。
- チャネル（ブランド）の一意の ID などの単純な文字列形式。
- タイトル、規制、保護者による制限のメタデータなどの追加情報を含むメディア RSS （MRSS）形式。
詳しくは、 保護されたリソースドキュメントを参照してください。
9. クライアントアプリケーションは、一度にいくつのリソースについて事前認証の決定を取得できますか？ preauthorization-phase-faq9
クライアントアプリケーションは、MVPD によって課せられた条件により、1 回の API リクエストで、通常は 5 回まで、限られた数のリソースに対して事前認証の決定を取得できます。
この最大数のリソースは、組織の管理者の 1 人がAdobe Pass TVE ダッシュボードを通じて、またはお客様に代わってAdobe Pass認証担当者が MVPD に同意した後に表示および変更できます。
詳しくは、TVE ダッシュボード統合ユーザーガイドドキュメントを参照してください。
承認フェーズに関するよくある質問 authorization-phase-faqs-general
1.承認フェーズの目的は何ですか？ authorization-phase-faq1
認証フェーズの目的は、ユーザーがMVPDで権限を検証した後でリクエストしたリソースをクライアントアプリケーションで再生できるようにすることです。
2.認証フェーズは必須ですか？ authorization-phase-faq2
認証フェーズは必須です。クライアントアプリケーションは、ユーザーがリクエストするリソースを再生する場合、このフェーズをスキップできません。ストリームをリリースする前に、ユーザーが権限を持っていることをMVPDで確認する必要があるからです。
3.認証の決定とは何ですか？また、有効期限はどのくらいですか？ authorization-phase-faq3
認証とは、 用語集のドキュメントで定義されている用語ですが、決定用語は 用語集にもあります。
認証決定は、決定の認証エンドポイントから取得できる、MVPD認証プロセスの問い合わせ結果に関する情報を格納します。
クライアントアプリケーションは、メディアトークンを含む認証決定を使用して、TV プロバイダー（権限を持つ）の決定によってユーザーがリソースストリームにアクセスできる場合に備えて、リソースストリームを再生できます。
詳しくは、次のドキュメントを参照してください。
認証決定は発行時に指定された限られた短い期間のみ有効で、MVPDに対する再度のクエリが必要になるまでの、Adobe Pass認証によってキャッシュされる時間を示します。
この制限付き期間は、認証（authZ） TTL と呼ばれ、組織管理者の 1 人またはAdobe Pass認証担当者が 客様に代わってAdobe PassTVE ダッシュボード）を通じて表示および変更できます。
詳しくは、TVE ダッシュボード統合ユーザーガイドドキュメントを参照してください。
4. クライアントアプリケーションは、認証決定を永続的なストレージにキャッシュする必要がありますか？ authorization-phase-faq4
クライアントアプリケーションは、認証決定を永続ストレージに保存する必要はありません。
5.認証決定が拒否された理由を、クライアントアプリケーションはどのように判断できますか。 authorization-phase-faq5
クライアントアプリケーションは、決定を承認エンドポイントからの応答に含まれる エラーコードとメッセージを調べることで、拒否された承認決定の理由を判断できます。 これらの詳細により、認証リクエストが拒否された具体的な理由がinsightに提供され、アプリケーションでの必要な処理をユーザーエクスペリエンスやトリガーに伝えるのに役立ちます。
認証決定を取得するために実装された再試行メカニズムが、認証決定が拒否された場合に無限ループが発生しないことを確認します。
再試行を適切な数に制限し、ユーザーに明確なフィードバックを表示して、拒否を適切に処理することを検討してください。
6. メディアトークンとは何で、どれくらい有効ですか？ authorization-phase-faq6
メディアトークンは、Glossary ドキュメントで定義されている用語です。
メディアトークンは、決定を承認エンドポイントから取得できる、クリアテキストで送信された署名済み文字列で構成されます。
詳しくは、 メディアトークンベリファイアドキュメントを参照してください。
メディアトークンは、問題発生時に指定された制限された短い期間のみ有効で、クライアントアプリケーションで検証および使用される前の時間制限を示します。
クライアントアプリケーションは、TV プロバイダー（権限を持つ）の決定によってユーザーがアクセスできる場合に、メディアトークンを使用してリソースストリームを再生できます。
詳しくは、次のドキュメントを参照してください。
7. クライアントアプリケーションは、リソースストリームを再生する前にメディストークンを検証する必要がありますか？ authorization-phase-faq7
はい。
クライアントアプリケーションは、リソースストリームの再生を開始する前に、メディアトークンを検証する必要があります。 この検証は、 メディアトークン検証子を使用して実行する必要があります。 返された serializedToken ージから token を検証することで、クライアントアプリケーションは、ストリームのリッピングなどの不正アクセスを防ぎ、適切に許可されたユーザーのみがコンテンツを再生できるようにします。
8. クライアントアプリケーションは、再生中に期限切れのメディアトークンを更新する必要がありますか？ authorization-phase-faq8
いいえ。
ストリームのアクティブな再生中に、クライアントアプリケーションが期限切れのメディアトークンを更新する必要はありません。 再生中にメディアトークンの有効期限が切れた場合、ストリームが中断されることなく続行されるようにしてください。 ただし、次回ユーザーがリソースを再生しようとすると、クライアントは新しい認証決定をリクエストし、新しいメディアトークンを取得する必要があります。
9.認証決定における各タイムスタンプ属性の目的は何ですか？ authorization-phase-faq9
認証決定には、認証自体と関連するメディアトークンの有効期間に関する重要なコンテキストを提供する、複数のタイムスタンプ属性が含まれます。 これらのタイムスタンプの目的は、認証決定に関連しているかメディアトークンに関連しているかによって異なります。
決定レベルのタイムスタンプ
これらのタイムスタンプは、承認決定全体の有効期間を示します。
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| 属性 | 説明 | 備考 |
notBefore |
承認決定が発行された時間（ミリ秒）。 | これにより、認証の有効期間の開始がマークされます。 |
notAfter |
承認決定の有効期限が切れる時間（ミリ秒単位）。 | 認証有効期間（TTL）は、再認証が必要になるまでの、認証が有効である期間を決定します。 この TTL は、MVPDの担当者とネゴシエートされます。 |
トークンレベルのタイムスタンプ
これらのタイムスタンプは、認証決定に関連付けられたメディアトークンの有効期間を表します。
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| 属性 | 説明 | 備考 |
notBefore |
メディアトークンが発行された時間（ミリ秒単位）。 | これは、トークンが再生に対して有効になるタイミングを示します。 |
notAfter |
メディアトークンの有効期限が切れる時間（ミリ秒単位）。 | メディアトークンは、誤用リスクを最小限に抑えるために故意に存続期間が短く（通常 7 分）、トークン生成サーバーとトークン検証サーバー間の潜在的なクロック差を考慮しています。 |
10. リソースとは何ですか？また、サポートされている形式は何ですか？ authorization-phase-faq10
リソースとは、Glossary ドキュメントで定義されている用語です。
リソースは、MVPD と合意された一意の識別子で、クライアントアプリケーションによってストリーミングされる可能性のあるコンテンツに関連付けられます。
リソースの一意の ID には、次の 2 つの形式があります。
- チャネル（ブランド）の一意の ID などの単純な文字列形式。
- タイトル、規制、保護者による制限のメタデータなどの追加情報を含むメディア RSS （MRSS）形式。
詳しくは、 保護されたリソースドキュメントを参照してください。
11. クライアントアプリケーションが一度に認証決定を取得できるリソースの数 authorization-phase-faq11
クライアントアプリケーションは、MVPD によって課せられる条件により、1 回の API リクエストで限られた数のリソースに対する承認決定を、通常は 1 つまで取得できます。
ログアウトフェーズに関するよくある質問 logout-phase-faqs-general
1. ログアウトフェーズの目的は何ですか？ logout-phase-faq1
ログアウトフェーズの目的は、クライアントアプリケーションが、ユーザーのリクエストに応じてAdobe Pass Authentication 内でユーザーの認証済みプロファイルを終了できるようにすることです。
2. ログアウトフェーズは必須ですか？ logout-phase-faq2
ログアウトフェーズは必須です。クライアントアプリケーションは、ログアウトする機能をユーザーに提供する必要があります。
ヘッダーの FAQ headers-faqs-general
1.認証ヘッダーの値を計算する方法 headers-faq1
| note important |
|---|
| IMPORTANT |
クライアントアプリケーションが REST API V1 から REST API V2 に移行する場合、クライアントアプリケーションは引き続き同じメソッドを使用して、以前と同じアクセストークン値を取得 Bearer きます。 |
Authorization リクエストヘッダーには、Adobe Passで保護された API にアクセスするためにクライアントアプリケーションで必要な Bearer アクセストークンが含まれています。
Authorization ヘッダー値は、登録段階でAdobe Pass Authentication から取得する必要があります。
詳しくは、次のドキュメントを参照してください。
2. AP-Device-Identifier ヘッダーの値を計算する方法 headers-faq2
| note important |
|---|
| IMPORTANT |
| クライアントアプリケーションが REST API V1 から REST API V2 に移行する場合、クライアントアプリケーションは引き続き同じ方法を使用して、以前と同じようにデバイス識別子の値を計算できます。 |
AP-Device-Identifier 要求ヘッダーには、クライアント アプリケーションによって作成されたストリーミング デバイスの識別子が含まれています。
AP-Device-Identifier ヘッダーのドキュメントには、値の計算方法に関する主なプラットフォームの例が記載されていますが、クライアントアプリケーションは、独自のビジネスロジックと要件に基づいて別の方法を使用するように選択できます。
3. X-Device-Info ヘッダーの値を計算する方法 headers-faq3
| note important |
|---|
| IMPORTANT |
| クライアントアプリケーションが REST API V1 から REST API V2 に移行する場合、クライアントアプリケーションは引き続き同じ方法を使用して、以前と同じようにデバイス情報の値を計算できます。 |
X-Device-Info 要求ヘッダーは、実際のストリーミング デバイスに関連するクライアント情報（デバイス、接続、およびアプリケーション）を格納し、MVPD が適用する可能性のあるプラットフォーム固有のルールを決定するために使用されます。
X-Device-Info ヘッダーのドキュメントには、値の計算方法に関する主なプラットフォームの例が記載されていますが、クライアントアプリケーションは、独自のビジネスロジックと要件に基づいて別の方法を使用するように選択できます。
X-Device-Info ヘッダーがない場合や、値が正しくない場合、リクエストは、unknown プラットフォームからのリクエストとして分類される場合があります。
その結果、リクエストが安全ではないものとして扱われ、認証 TTL の短縮など、より制限が厳しいルールの対象となる可能性があります。 さらに、ストリーミングデバイスの connectionIp や connectionPort などの一部のフィールドは、Spectrum の ホームベース認証などの機能に必須です。
デバイスの代わりにサーバーからリクエストが送信された場合でも、X-Device-Info ヘッダー値には、実際のストリーミングデバイス情報が反映されている必要があります。
その他の FAQ misc-faqs-general
1. REST API V2 のリクエストと応答を調べて、API をテストできますか。 misc-faq1
はい。
専用の Adobe Developer web サイトから REST API V2 を参照できます。 Adobe Developerの web サイトでは、次の場所への無制限のアクセスが可能です。
REST API V2 とやり取りするには、DCR API を介して取得した Bearer アクセストークンに Authorization ヘッダーを含める必要があります。
DCR API を使用するには、REST API V2 スコープを含むソフトウェアステートメントが必要です。 詳しくは、Dynamic Client Registration （DCR）の FAQ ドキュメントを参照してください。
2. OpenAPI をサポートする API 開発ツールを使用して、REST API V2 のリクエストと応答を調べることはできますか。 misc-faq2
はい。
DCR API および REST API V2} の OpenAPI 仕様ファイルは、{4Adobe Developer web サイトからダウンロードできます。
OpenAPI 仕様ファイルをダウンロードするには、「ダウンロード」ボタンをクリックして、次のファイルをローカルマシンに保存します。
その後、これらのファイルを好みの API 開発ツールに読み込み、REST API V2 のリクエストと応答を調べて、API をテストできます。
3. https://sp.auth-staging.adobe.com/apitest/api.htmlでホストされている既存の API テストツールを引き続き使用できますか？ misc-faq3
いいえ。
REST API V2 に移行するクライアントアプリケーションでは、https://developer.adobe.com/adobe-pass/でホストされる新しいテストツールを使用する必要があります。 Adobe Developerの web サイトでは、次の場所への無制限のアクセスが可能です。
REST API V2 とやり取りするには、DCR API を介して取得した Bearer アクセストークンに Authorization ヘッダーを含める必要があります。
DCR API を使用するには、REST API V2 スコープを含むソフトウェアステートメントが必要です。 詳しくは、Dynamic Client Registration （DCR）の FAQ ドキュメントを参照してください。
移行に関する FAQ migration-faqs
既存のアプリケーションを REST API V2 に移行する必要があるアプリケーションで作業している場合は、この節を続行してください。
一般的な移行に関する FAQ general-migration-faqs
1. REST API V2 に移行された新しいクライアントアプリケーションを、すべてのユーザーに一度にロールアウトする必要がありますか？ migration-faq1
いいえ。
クライアントアプリケーションは、REST API V2 を統合した新しいバージョンをすべてのユーザーに同時にロールアウトする必要はありません。
Adobe Pass認証では、2025 年末まで、REST API V1 またはSDKを統合する古いクライアントアプリケーションバージョンを引き続きサポートします。
2. REST API V2 に移行された新しいクライアントアプリケーションを、すべての API とフローにわたって一度にロールアウトする必要がありますか？ migration-faq2
はい。
クライアントアプリケーションは、REST API V2 を統合した新しいバージョンを、すべてのAdobe Pass認証 API およびフローに同時にロールアウトする必要があります。
「2 画面目の認証」フローの場合、クライアントアプリケーションは、「プライマリ」と「セカンダリ の両方のアプリケーションに対して REST API V2 を統合した新しいバージョンを同時にロルアウトす 必要がります。
Adobe Pass認証では、API とフローの間で REST API V2 と REST API V1/SDKの両方を統合する「ハイブリッド」実装をサポートしていません。
3. REST API V2 に移行された新しいクライアントアプリケーションに更新する際、ユーザー認証は保持されますか。 migration-faq3
いいえ。
REST API V1 またはSDKを統合する古いクライアントアプリケーションバージョンで取得したユーザー認証は保持されません。
したがって、ユーザーは、REST API V2 に移行された新しいクライアントアプリケーション内で再認証する必要があります。
4. REST API V2 では、拡張エラーコードはデフォルトで有効になっていますか。 migration-faq4
はい。
REST API V2 に移行するクライアントアプリケーションでは、デフォルトでこの機能のメリットが自動的に得られ、より詳細で正確なエラー情報が提供されます。
詳しくは、 拡張エラーコードドキュメントを参照してください。
5.既存の統合を REST API V2 に移行する際に、設定を変更する必要はありますか。 migration-faq5
いいえ。
REST API V2 に移行するクライアントアプリケーションでは、既存のMVPD統合の設定を変更する必要はありません。 また、既存の サービスプロバイダーおよび MVPD に対しても、引き続き同じ識別子を使用します。
また、MVPD エンドポイントと通信するためにAdobe Pass認証で使用されるプロトコルは変更されません。
REST API V1 から REST API V2 への移行 migration-rest-api-v1-to-rest-api-v2-faqs
REST API V1 から REST API V2 に移行する必要があるアプリケーションを操作している場合は、このサブセクションを続行します。
登録フェーズに関するよくある質問 registration-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1.登録フェーズに必要な高レベルの API 移行は何ですか。 registration-phase-v1-to-v2-faq1
REST API V1 から REST API V2 への移行では、登録フェーズに関して大きな変更はありません。
クライアントアプリケーションは、引き続き同じフローを使用して、 動的クライアント登録（DCR）プロセスを通じてAdobe Pass認証に登録し、アクセストークンを取得できます。
詳しくは、次のドキュメントを参照してください。
設定フェーズの FAQ configuration-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1.設定フェーズに必要な、大まかな API 移行は何ですか？ configuration-phase-v1-to-v2-faq1
REST API V1 から REST API V2 への移行では、大まかな変更が必要で、次の表に示します。
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | REST API V1 | REST API V2 | 所見 |
| アクティブな統合を持つ MVPD のリストの取得 | GET /api/v1/config/{serviceProvider} |
GET /api/v2/{serviceProvider}/configuration |
認証フェーズの FAQ authentication-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1.認証フェーズに必要な、高レベルの API 移行は何ですか。 authentication-phase-v1-to-v2-faq1
REST API V1 から REST API V2 への移行では、大まかな変更が必要で、次の表に示します。
事前認証フェーズの FAQ preauthorization-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1.事前認証フェーズに必要な高レベルの API 移行は何ですか。 preauthorization-phase-v1-to-v2-faq1
REST API V1 から REST API V2 への移行では、大まかな変更が必要で、次の表に示します。
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | REST API V1 | REST API V2 | 所見 |
| 事前承認されたリソースの取得（事前承認決定） | GET /api/v1/preauthorize （最初の画面） GET /api/v1/preauthorize （2 番目の画面） |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
詳しくは、次のドキュメントを参照してください。 |
承認フェーズに関するよくある質問 authorization-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1.認証フェーズに必要な高レベルの API 移行は何ですか。 authorization-phase-v1-to-v2-faq1
REST API V1 から REST API V2 への移行では、大まかな変更が必要で、次の表に示します。
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| 対象範囲 | REST API V1 | REST API V2 | 所見 |
| （MVPD）認証の開始 | GET /api/v1/authorize |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
クライアントアプリケーションは、この API の応答を一度に複数の目的に使用できます。
詳しくは、次のドキュメントを参照してください。 |
| 認証トークンの取得（認証決定） | GET /api/v1/tokens/authz |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
クライアントアプリケーションは、この API の応答を一度に複数の目的に使用できます。
詳しくは、次のドキュメントを参照してください。 |
| 短い認証トークンの取得（メディアトークン） | GET /api/v1/tokens/media |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
クライアントアプリケーションは、この API の応答を一度に複数の目的に使用できます。
詳しくは、次のドキュメントを参照してください。 |
ログアウトフェーズに関するよくある質問 logout-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. ログアウトフェーズに必要な、大まかな API 移行は何ですか。 logout-phase-v1-to-v2-faq1
REST API V1 から REST API V2 への移行では、大まかな変更が必要で、次の表に示します。
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | REST API V1 | REST API V2 | 所見 |
| ログアウトの開始 | GET /api/v1/logout |
GET /api/v2/{serviceProvider}/logout |
詳しくは、次のドキュメントを参照してください。 |
SDKから REST API V2 への移行 migration-sdk-to-rest-api-v2
SDKから REST API V2 に移行する必要があるアプリケーションを操作している場合は、このサブセクションの手順を続けます。
登録フェーズに関するよくある質問 registration-phase-faqs-migration-sdk-to-rest-api-v2
1.登録フェーズに必要な高レベルの API 移行は何ですか。 registration-phase-sdk-to-v2-faq1
SDK から REST API V2 への移行では、大まかな変更が必要で、それを次の表に示します。
AccessEnabler JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 動的クライアント登録（DCR）の完了 | コンストラクタへのソフトウェア文の提供 | POST /o/client/register GET /o/client/token |
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 動的クライアント登録（DCR）の完了 | コンストラクタへのソフトウェア文の提供 | POST /o/client/register GET /o/client/token |
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 動的クライアント登録（DCR）の完了 | コンストラクタへのソフトウェア文の提供 | POST /o/client/register GET /o/client/token |
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 動的クライアント登録（DCR）の完了 | コンストラクタへのソフトウェア文の提供 | POST /o/client/register GET /o/client/token |
詳しくは、次のドキュメントを参照してください。 |
設定フェーズの FAQ configuration-phase-faqs-migration-sdk-to-rest-api-v2
1.設定フェーズに必要な、大まかな API 移行は何ですか？ configuration-phase-sdk-to-v2-faq1
SDK から REST API V2 への移行では、大まかな変更が必要で、それを次の表に示します。
AccessEnabler JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| アクティブな統合を持つ MVPD のリストの取得 | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| アクティブな統合を持つ MVPD のリストの取得 | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
AccessEnabler Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| アクティブな統合を持つ MVPD のリストの取得 | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| アクティブな統合を持つ MVPD のリストの取得 | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
認証フェーズの FAQ authentication-phase-faqs-migration-sdk-to-rest-api-v2
1.認証フェーズに必要な、高レベルの API 移行は何ですか。 authentication-phase-sdk-to-v2-faq1
SDK から REST API V2 への移行では、大まかな変更が必要で、それを次の表に示します。
AccessEnabler JavaScript SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| （MVPD）認証の開始 | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code} |
詳しくは、次のドキュメントを参照してください。 |
| ユーザー認証ステータスの確認 | AccessEnabler.checkAuthentication | 次のいずれかを使用します。 GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
クライアントアプリケーションは、次の API の応答を複数の目的で一度に使用できます。
詳しくは、次のドキュメントを参照してください。 |
| ユーザーメタデータ情報の取得 | AccessEnabler.getMetadata | 次のいずれかを使用します。 GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
クライアントアプリケーションは、次の API の応答を複数の目的で一度に使用できます。
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler iOS SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| （MVPD）認証の開始 | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code} |
詳しくは、次のドキュメントを参照してください。 |
| ユーザー認証ステータスの確認 | AccessEnabler.checkAuthentication | 次のいずれかを使用します。 GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
クライアントアプリケーションは、次の API の応答を複数の目的で一度に使用できます。
詳しくは、次のドキュメントを参照してください。 |
| ユーザーメタデータ情報の取得 | AccessEnabler.getMetadata | 次のいずれかを使用します。 GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
クライアントアプリケーションは、次の API の応答を複数の目的で一度に使用できます。
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler tvOSSDK
AccessEnabler Android SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| （MVPD）認証の開始 | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/sessions GET /api/v2/authenticate/{serviceProvider}/{code} |
詳しくは、次のドキュメントを参照してください。 |
| ユーザー認証ステータスの確認 | AccessEnabler.checkAuthentication | 次のいずれかを使用します。 GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
クライアントアプリケーションは、次の API の応答を複数の目的で一度に使用できます。
詳しくは、次のドキュメントを参照してください。 |
| ユーザーメタデータ情報の取得 | AccessEnabler.getMetadata | 次のいずれかを使用します。 GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
クライアントアプリケーションは、次の API の応答を複数の目的で一度に使用できます。
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler FireOS SDK
事前認証フェーズの FAQ preauthorization-phase-faqs-migration-sdk-to-rest-api-v2
1.事前認証フェーズに必要な高レベルの API 移行は何ですか。 preauthorization-phase-sdk-to-v2-faq1
SDK から REST API V2 への移行では、大まかな変更が必要で、それを次の表に示します。
AccessEnabler JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 事前承認されたリソースの取得（事前承認決定） | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 事前承認されたリソースの取得（事前承認決定） | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 事前承認されたリソースの取得（事前承認決定） | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
詳しくは、次のドキュメントを参照してください。 |
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 事前承認されたリソースの取得（事前承認決定） | AccessEnabler.checkPreauthorizedResources | POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
詳しくは、次のドキュメントを参照してください。 |
承認フェーズに関するよくある質問 authorization-phase-faqs-migration-sdk-to-rest-api-v2
1.認証フェーズに必要な高レベルの API 移行は何ですか。 authorization-phase-sdk-to-v2-faq1
SDK から REST API V2 への移行では、大まかな変更が必要で、それを次の表に示します。
AccessEnabler JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 短い認証トークンの取得（メディアトークン） | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
クライアントアプリケーションは、この API の応答を一度に複数の目的に使用できます。
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 短い認証トークンの取得（メディアトークン） | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
クライアントアプリケーションは、この API の応答を一度に複数の目的に使用できます。
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 短い認証トークンの取得（メディアトークン） | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
クライアントアプリケーションは、この API の応答を一度に複数の目的に使用できます。
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| 短い認証トークンの取得（メディアトークン） | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider}/decisions/authorize/{mvpd} |
クライアントアプリケーションは、この API の応答を一度に複数の目的に使用できます。
詳しくは、次のドキュメントを参照してください。 |
ログアウトフェーズに関するよくある質問 logout-phase-faqs-migration-sdk-to-rest-api-v2
1. ログアウトフェーズに必要な、大まかな API 移行は何ですか。 logout-phase-sdk-to-v2-faq1
SDK から REST API V2 への移行では、大まかな変更が必要で、それを次の表に示します。
AccessEnabler JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| ログアウトの開始 | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| ログアウトの開始 | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| ログアウトの開始 | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
詳しくは、次のドキュメントを参照してください。 |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| 対象範囲 | SDK | REST API V2 | 所見 |
| ログアウトの開始 | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
詳しくは、次のドキュメントを参照してください。 |