REST API の概要 rest-api-overview
Last update: Sat Jul 20 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
このページのコンテンツは情報提供のみを目的としています。 この API を使用するには、Adobeから現在のライセンスが必要です。 無許可の使用は許可されていません。
概要 over
Adobe Pass認証 REST API を使用すると、TV Everywhere （TVE）の認証および承認サービスに直接アクセスできます。 この API は、サーバー間または接続デバイス（ゲーム機、スマート TV、セットトップボックスなど）の 2 つの主要なアーキテクチャをサポートします。 web ブラウジング機能を持たないアプリケーション。
スロットルメカニズム
Adobe Pass認証 REST API は、 スロットルメカニズムによって制御されます。
サーバー間
サーバー間ソリューションには、TVE フロー用のAdobe Pass Authentication Services に接続するプログラマーサービスと統合されるプログラマークライアントアプリケーションが含まれます。 このアプローチは、TVE の実装の大部分をクライアントからサーバーに移行します。サーバーでは、単一の統合認証モジュールを構築および管理できます。 クライアントアプリケーションの残りの主な責任は、ユーザー認証のための web ビューの管理です。
接続デバイス
Connected Devices アプリは、REST API を介してAdobe Pass Authentication と直接通信し、設定、登録、認証ステータスチェックおよび認証フローを実行します。一方、認証フローには 2 つ目の画面（ブラウザー）アプリが必要です。 そのため、ネイティブ SDK は使用されません。
その他のアーキテクチャ
2 つの主要な REST API ベースアーキテクチャ、スマートデバイス用のサーバー間および直接クライアントソリューションに加えて、他のアーキテクチャもあります。 その中のプライマリとなるのが、SDK アーキテクチャです。このアーキテクチャでは、Adobe Pass認証がプログラマーに提供するアクセスイネーブラと呼ばれるクライアントコンポーネントを使用します。 アプリケーションは、Access Enabler API を使用して、起動、認証、認証、ログアウトを処理します。 プログラマーのアプリとAdobe Pass認証サーバー間のすべての通信は、アクセスイネーブラを介して行われます。 JavaScript、iOS、tvOS、Android、FireTV の各プラットフォームでは、異なる種類の Access Enabler を使用できます。
サーバー間ソリューションの外部では、ネイティブ SDK をサポートするクライアントプラットフォームで REST API を直接使用することは可能ですが、この方法はお勧めしません。
REST API の長所と短所 ProsAndCons
Adobe Pass認証 REST API は、web 閲覧機能や永続ストレージを持たないデバイス向けの TV Everywhere （TVE）ソリューションを提供するために作成されました。 REST API は、すべての認証および承認フローをサポートしますが、ネイティブの SDK コンポーネントがないため、 Adobe Pass Authentication が提供および管理する SDK には、REST API の場合はプログラマーが実装および管理する必要があるビジネスルールを実装する標準機能が付属しています。 以下のプログラマーの責任表では、プログラマーが対処する必要がある現在の REST API の制限事項について説明します。
サーバー間とクライアントベースの長所と短所
サーバー間アーキテクチャは、認証および承認に関連するロジックのほとんどを 1 つの論理ユニットまたは実装に統合する方法を提供します。 このアプローチには長所と短所があります。 メリットは次のとおりです。
- 認証および承認ビジネスロジックの単一の実装。
- そのプラットフォームのネイティブツールを使用して、サポート対象の各プラットフォームにそのロジックを実装する必要がなくなります。
- 関連するすべての要件（アプリストアの更新など）でクライアントを更新せずに機能を更新する機能。
- より簡単に authN および authZ のカスタム機能の拡張（D2C の追加など）。
- 関連トラフィックを直接管理して、制御、品質、監視を向上させます。
ここでも、プログラマーの責任に短所がリストされていますが、次の点が含まれます。
- Platform SSO のないプラットフォームの場合、クライアントごとに SSO を実装する必要があります。
- プログラマは、必要に応じて MVPD 固有のロジックを実装する必要があります。
- REST API を使用するすべてのプラットフォームは、認証 TTL などのプロパティを管理する単一の設定を共有します。
接続デバイス
SDK が使用できないので、ほとんどの接続デバイスでは、REST API を何らかの方法で使用する必要があります。 接続されたデバイスは、REST API を直接使用するか、REST API を使用するサーバー間ソリューションと統合します。
プログラマーの責任 programmer-responsibilities
以下は、サーバー間アプリケーションと接続デバイス アプリケーションの両方に適用されます。
機能
機能の取り扱いに関する責任
現在のクライアントレス API の制限事項とネイティブ SDK との違いについて
Platform ごとに適用される設定
Adobe
すべてのプラットフォーム（iOSやAndroidなどのモバイルデバイスを含む）で REST API を使用する場合の
主な制限 の 1 つは、TVE ダッシュボード設定ツールの REST API に対応する設定がすべてのデバイスに適用される（REST API 上に実装されたネイティブアプリケーションを実行するiOS デバイスがある場合でも）ことです。 この制限は
MVPD で合意された TTL およびプラットフォーム設定がプラットフォームごとに異なる場合は 壊れる可能性があります。
1
シングルサインオン
プログラマー
REST API を使用すると、SSO は Platform SSO をサポートするプラットフォーム（Apple、Roku、Amazonなど）でのみ利用できます。REST API を使用する場合、他のプラットフォームに対して SSO を保証することはできません。 SDK は、クロスサイト/アプリ方式でデータをキャッシュします。 つまり、ユーザーはサイト/アプリに 1 回ログインし、ユーザーの操作を必要とせずに、参加するサイトに既にログインしています。
2
シングル ログアウト
プログラマー
ネイティブの SDK SSO シナリオでは、参加している 1 つのアプリケーションからログアウトすると、どこからでもユーザーがログアウトされます。 現在の REST API では SLO をサポートしていません。あるアプリケーションからログアウトすると、その特定のアプリケーションでのみユーザーがログアウトされます。
キャッシュ
プログラマー
REST API 実装では、ビジネスで合意されたデータ項目に対して独自のキャッシュメカニズムを実装する必要があります。 SDK は、様々なビジネスルールを考慮に入れながら、様々なデータ項目を自動的にキャッシュしています。 例えば、ユーザーメタデータは認証トークンと同じ TTL を使用してキャッシュされますが、一部の項目はプログラムによってキャッシュから除外できます（preflight）。
詳細なエラーレポートのメカニズム
プログラマー
REST API は、主にアプリケーションエラーをレポートするために HTTP エラーコードに依存しますが、SDK には、アプリケーション開発者が何が起こっているのかをより深く理解するのに役立つ詳細なエラーレポートメカニズムがあります。
アプリケーションエラーの回復（エラー時の再試行、ループ検出など）
プログラマー
REST API 実装は、独自のアプリケーション回復システムを構築する必要があります。一方、SDK 上の実装は、SDK のエラー回復システムからメリットを得ます。一時的なネットワークエラーからの回復。特定のネットワークコールを、「ループ」を防ぐために、インプレースロジックで再試行します。
要求者ごとの認証
プログラマー
一部の MVPD は、ビジネス上の理由または技術的な課題により、サイトやアプリごとに認証を必要とします。 SDK は、TVE ダッシュボードの設定に基づいて、これを自動的に適用します。 REST API の実装者は、ビジネス契約に違反したり、アプリケーションごとに認証データをスコープ設定する MVPD の認証を完了したりするために、自分自身でこれを実装する必要があります。
パッシブ認証
プログラマー
一部の MVPD では「パッシブ」認証をサポートしています。この認証では、ユーザーは認証情報を入力する必要がなく、ユーザーの認証は自動的に試行されます。 これは、「リクエスターごとの認証」も要件とする MVPD で特に役立ちます。 このような場合、SDK で有効になる UX はシームレスで、ユーザーはアプリケーションで 1 回だけ認証され、SDK はエコシステム内の他のアプリケーションに対して「パッシブ」認証を実行します。 ユーザーは追加の受動呼び出しを見ることはありません。MVPD は、アプリケーションごとに別々の認証セッションを持つことを目標に達している間、単に既に認証されます。
デバイスの暗黙的かつ均一な検出
プログラマー
SDK は、デバイスタイプを自動的に検出し、その情報を標準的な方法で送信します。 REST API の実装は、実装者に応じて異なる情報を送信する傾向があるため、サイト間のビジネスルールや統計が歪曲/破壊される可能性があります。 プログラマーは、各アプリで正しいデバイス情報を送信したことを確認する必要があります。 サーバーからサーバーへの実装の場合、追加の手順を実行しない限り、REST API はエンドユーザーの IP アドレスを正しく識別しません。 IP アドレスは、不正防止や HBA などの特定のユースケースで重要です。
改ざん防止 TempPass
プログラマー
TempPass の適用は、安定したデバイス ID に基づいています。 SDK は、ハードウェア情報/フィンガープリント技術を使用してデバイスを識別しますが、このメカニズムは公開されておらず、したがって、より安全で衝突がありません。 REST API を実装する場合、プログラマーは、デバイスの識別/フィンガープリント用に独自のアルゴリズムを実装する必要があります。
デバイスバインディング
プログラマー
SDK を介してアプリケーションを使用するデバイスで生成されたトークンは移植性に欠けるため、悪意のあるユーザーがトークンを共有したり、他のユーザーにアクセスを提供したりすることが困難になります。 これは、「改ざん防止 TempPass」と同じデバイス ID メカニズムに基づいています。 REST API の場合、トークンはクラウドに残ります。つまり、同じ呼び出しを行う同じ deviceID を持つ 2 つのデバイスが、同じ応答/アクセスを取得します。 プログラマーは、デバイス ID を生成/割り当てるための、堅牢で安全かつ衝突のないメカニズムを持っていることを確認する必要があります。
予測可能で認定された一連の機能
プログラマー
各 SDK の既存の機能セットは、一貫性があり、予測可能で、完全に認定およびテストされています。 一部のビジネス要件は SDK を介して適用されるため、プログラマーが REST API を使用している間に契約を侵害するリスクが高くなります。 REST API はより柔軟性が高い場合がありますが、Adobeでは、SDK 実装で TVE Dashboard のビジネス上の意思決定と設定が適用されることを保証しています。 クライアントレスの場合、各プログラマーは、特定の時点でアプリケーションをスイートする独自のビジネスルールのサブセットを実装します。
-
新しい One API イニシアチブの一環として、この制限を修正し、デバイスの識別に基づいてプラットフォームごとにルールを適用できるようにすることを計画しています。
-
Adobeは、REST API で使用できる Platform SSO を実装するために、引き続きすべての主要なプラットフォームと連携します。 One API イニシアチブでは、ネイティブ SDK を使用して実装されたアプリと REST API を使用して実装されたアプリの間で SSO サポートを提供します。