(レガシー) REST APIの概要 rest-api-overview

NOTE
このページのコンテンツは、情報提供のみを目的として提供されています。 このAPIを使用するには、Adobeの現在のライセンスが必要です。 無断使用は認められません。
IMPORTANT
製品のお知らせ ページに集計されている最新のAdobe Pass認証製品のお知らせと廃止予定について、常に情報を得てください。

概要 over

Adobe Pass Authentication REST APIでは、TV Everywhere (TVE)の認証および認証サービスに直接アクセスできます。 このAPIは、サーバー間または接続デバイス(ゲームコンソール、スマートテレビ、セットトップボックスなど)の2つの主要なアーキテクチャをサポートしています。 web ブラウジング機能を備えていないアプリケーション。

スロットル機構

Adobe Pass Authentication REST APIは、​ スロットル メカニズム ​によって管理されます。

サーバー間

サーバー間ソリューションには、TVE フロー用のAdobe Pass認証サービスと接続するプログラマーサービスと統合するプログラマークライアントアプリケーションが含まれます。 このアプローチは、TVE実装のほとんどをクライアントから、単一の統合された認証モジュールを構築および維持できるサーバーに移行します。 クライアントアプリケーションの主な残りの責任は、ユーザー認証用のweb ビューの管理です。

接続デバイス

Connected Devices アプリは、REST APIを介してAdobe Pass Authenticationと直接通信し、設定、登録、認証ステータスの確認、認証フローを実行します。認証フローには、2番目の画面(ブラウザー)アプリが必要です。 そのため、ネイティブ SDKは使用されません。

その他のアーキテクチャ

2つの主要なREST API ベースのアーキテクチャ、サーバー間およびスマートデバイス用のダイレクトクライアントソリューションに加えて、他にもアーキテクチャがあります。 その中でもプライマリとなるのが、SDK アーキテクチャです。このアーキテクチャでは、Adobe Pass Authenticationがプログラマーに提供するAccess Enablerと呼ばれるクライアントコンポーネントを使用します。 このアプリはAccess Enabler APIを使用して、起動、認証、認証、ログアウトを処理します。 プログラマーのアプリとAdobe Pass認証サーバーとの間のすべての通信は、Access Enablerを通じて行われます。 Access Enablerには、JavaScript、iOS、tvOS、Android、FireTVの各プラットフォームで異なる機能が用意されています。

サーバー間ソリューション以外のネイティブ SDKをサポートするクライアントプラットフォームでREST APIを直接使用することは可能ですが、この方法は推奨されません。

REST APIの長所と短所 ProsAndCons

Adobe Pass Authentication REST APIは、web閲覧機能や永続的なストレージを備えていないデバイス向けにTV Everywhere (TVE)ソリューションを提供するために作成されました。 REST APIは、すべての認証フローと認証フローをサポートしますが、ネイティブのSDK コンポーネントがないため、 Adobe Pass Authenticationが提供および管理するSDKには、プログラマがREST APIを実装および保守する必要があるビジネスルールを実装する、すぐに使用できる機能が搭載されています。 以下のプログラマーの責任の表では、プログラマーが対処する必要がある現在のREST APIの制限について説明します。

サーバー間SDKとクライアントベースの長所と短所

サーバー間アーキテクチャは、認証と認証に関連するロジックのほとんどを単一の論理ユニットまたは実装に統合する方法を提供します。 この手法には長所と短所があります。 長所は次のとおりです。

  • 認証および認証ビジネスロジックの単一の実装。
  • サポートされている各プラットフォームに、そのプラットフォームのネイティブツールを使用してロジックを実装する必要はありません。
  • 関連するあらゆる要件(アプリストアのアップデートなど)をクライアントに知らせることなく、機能を更新できます。
  • より簡単に​認証および認証のカスタム機能を拡張およびカスタマイズできます(D2Cの追加など)。
  • 関連トラフィックを直接管理し、より高度な制御、品質、監視を実現。

繰り返しますが、短所はプログラマーの責任に記載されていますが、次のものが含まれます。

  • SSOは、Platform SSOを使用しないプラットフォームの各クライアントに対して実装する必要があります。
  • プログラマは、必要に応じてMVPD固有のロジックを実装する必要があります。
  • REST APIを使用するすべてのプラットフォームは、認証TTLなどのプロパティを管理する単一の設定を共有します。

接続デバイス

SDKが使用できないため、ほとんどの接続デバイスでは、REST APIを何らかの方法で使用する必要があります。 接続デバイスは、REST APIを直接使用するか、REST APIを使用するサーバー間ソリューションと統合します。

プログラマーの責任 programmer-responsibilities

以下は、サーバー間アプリケーションとコネクテッドデバイスアプリケーションの両方に適用されます。

機能
機能を処理する責任
現在のクライアントレス APIの制限とネイティブ SDKとの違いに関する説明
プラットフォームごとに適用される設定設定
Adobe
すべてのプラットフォーム(iOSやAndroidなどのモバイルデバイスを含む)全体でREST APIを使用する際の1つの​ 大きな制限 ​は、TVE Dashboard設定ツールのREST APIに対応する設定が、すべてのデバイス(REST APIに実装されたネイティブアプリケーションを実行するiOS デバイスがある場合でも)に適用されることです。 この制限​ は、合意されたTTLとMVPDとの合意されたプラットフォーム設定を ​解除できます(各プラットフォームごとに異なる場合)。 1
シングルサインオン
プログラマー
SSOは、REST APIを使用すると、Platform SSOをサポートするプラットフォーム(Apple、Roku、Amazonなど)でのみ使用できますが、REST APIを使用する場合、他のプラットフォームではSSOを保証できません。 SDKは、クロスサイト/アプリ方法でデータをキャッシュします。 つまり、ユーザーはサイト/アプリで1回ログインし、ユーザーの操作を必要とせずに、参加サイトですでにログインしています。 2
シングルログアウト
プログラマー
ネイティブのSDK SSO シナリオでは、1つの参加アプリケーションからログアウトすると、ユーザーはどこからでもログアウトします。 現在のREST APIでは、SLOはサポートされていません。1つのアプリケーションからログアウトすると、その特定のアプリケーションに対してのみユーザーがログアウトされます。
キャッシュ
プログラマー
REST APIの実装は、ビジネスで合意されたデータ項目に対して独自のキャッシュメカニズムを実装する必要があります。 SDKは、さまざまなビジネスルールを考慮しながら、さまざまなデータ項目を自動的にキャッシュします。 例えば、ユーザーメタデータは認証トークンと同じTTLでキャッシュされますが、一部の項目はプログラムによってキャッシュから除外できます(プリフライト)。
詳細なエラー報告メカニズム
プログラマー
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の場合、トークンはクラウド内に残ります。つまり、同じデバイス IDを持つ2つのデバイスが同じ呼び出しを行うことで、同じ応答/アクセスが得られます。 プログラマーは、デバイス IDを生成/割り当てるための堅牢で安全なコリジョンフリーのメカニズムを持っていることを確認する必要があります。
予測可能で認証済みの機能セットにより
プログラマー
各SDKの既存の機能セットは、一貫性があり、予測可能であり、完全に認定およびテストされています。 一部のビジネス要件はSDKを介して適用されるため、REST APIを使用している間にプログラマーが契約に違反するリスクがあります。 REST APIの方が柔軟性が高い場合もありますが、Adobeでは、SDKの実装がビジネス上の意思決定とTVE ダッシュボードの設定を確実に適用します。 クライアントレスの場合、各プログラマーは、特定の時点でアプリケーションに対応するビジネスルールの独自のサブセットを実装します。
  1. 新しいOne API イニシアチブの一環として、この制限を修正し、デバイス識別に基づいてプラットフォームごとにルールを適用できるようにする予定です。

  2. Adobeは、引き続きすべての主要なプラットフォームと連携して、REST APIで使用できるPlatform SSOを実装します。 アドビのOne API イニシアチブは、ネイティブ SDKを使用して実装されたアプリと、REST APIを使用して実装されたアプリとの間で、SSO サポートを提供します。

最小必要デバイス構成 min_reqs

Adobe Pass Authentication REST APIを使用するには、デバイスがAdobe Pass Authentication Platform / Device / Tools Requirements ドキュメント ​のREST API セクションに記載されている最小技術要件を満たすか、それを超える必要があります。

recommendation-more-help
pass-help-authentication