（レガシー） REST API クックブック（クライアントからサーバー） rest-api-cookbook-client-to-server

Last update: Thu Nov 06 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

トピック：
認証

NOTE

このページのコンテンツは情報提供のみを目的としています。この API を使用するには、Adobeの最新ライセンスが必要です。無許可の使用は許可されていません。

IMPORTANT

製品のお知らせページに集約された最新のAdobe Pass認証製品のお知らせや廃止予定タイムラインについて、常に情報を提供するようにします。

概要 overview

このドキュメントでは、プログラマーのエンジニアリングチームが、REST API サービスを使用して「スマートデバイス」（ゲームコンソール、スマート TV アプリ、セットトップボックスなど）をAdobe Pass認証と統合する手順を順を追って説明します。このクライアントからサーバーへのアプローチは、クライアント SDKではなく REST API を使用するので、一意の SDK を数多く開発することは不可能な、様々なプラットフォームの幅広いサポートが可能になります。クライアントレスソリューションの仕組みに関する技術的な概要については、クライアントレス技術概要を参照してください。

このアプローチでは、必要なフローを完了するために 2 つのコンポーネント（ストリーミングアプリと AuthN アプリ）が必要です。ストリーミングアプリでの起動、登録、承認、ビューメディアフローと、AuthN アプリでの認証フローです。

スロットルメカニズム

Adobe Pass認証 REST API は、スロットルメカニズムによって制御されます。

コンポーネント components

動作しているクライアントからサーバーへのソリューションには、次のコンポーネントが関係しています。

タイプ

コンポーネント

説明

ストリーミングデバイス

ストリーミングアプリ

ユーザーのストリーミングデバイス上に存在し、認証済みビデオを再生するプログラマーアプリケーション。

[ オプション] AuthN モジュール

streaming Device にユーザーエージェント（Web ブラウザー）がある場合、MVPD IdP 上でユーザーの認証は AuthN モジュールが行います。

[ オプション] AuthN デバイス

AuthN アプリ

ストリーミングデバイスにユーザーエージェント（Web ブラウザー）がない場合、AuthN アプリケーションは、Web ブラウザーを使用して別のユーザーのデバイスからアクセスする、プログラマー向けの Web アプリケーションです。

Adobe インフラストラクチャ

Adobe Pass サービス

MVPD IdP および AuthZ サービスと統合され、認証と承認の決定を行うサービス。

MVPD インフラストラクチャ

MVPD IdP

ユーザーの ID を検証するために、資格情報ベースの認証サービスを提供するMVPD エンドポイント。

MVPD AuthZ サービス

ユーザーの購読、保護者による制限などに基づいて認証の決定を行うMVPD エンドポイント。

フロー flows

動的クライアント登録（DCR）

Adobe Passは、DCR を使用して、プログラマーアプリケーションまたはサーバーとAdobe Pass サービスの間のクライアント通信を保護します。 DCR フローは独立しており、Dynamic Client Registration Overview ドキュメントで説明されています。

ストリーミング（スマートデバイス）アプリフロー

起動フロー

アプリが起動し、最初の UI が読み込まれます。
デバイス ID を取得または生成します。
Check-authentication 呼び出しを発行して、デバイスがすでに認証されているかどうかを確認します。例：<SP_FQDN>/api/v1/checkauthn [device ID]
checkauthn 呼び出しが成功した場合は、手順 2 以降の認証フローに進みます。失敗した場合、登録フローを開始します。

登録フロー

ユーザーが 2nd screen ログインアプリへのアクセスに使用する登録コードと URL を取得し、ユーザーに提示します。

a. ハッシュ化されたデバイス ID と「登録 URL」を渡して、Adobe Registration Code Service に POST リクエストを送信します。例：<REGGIE_FQDN>/reggie/v1/[requestorId]/regcode [device ID]

b.返された登録コードと URL をユーザーに提示します。

c. Web 対応デバイスに切り替えるようにユーザーに指示し、URL に移動して、登録コードを入力します。

認証フロー

ユーザーは 2 番目の画面アプリから戻り、デバイスの「続行」ボタンを押します。または、ポーリングメカニズムを実装して認証ステータスを確認することもできますが、Adobe Pass認証では、ポーリングよりも「続行」ボタンを使用することをお勧めします。例：<SP_FQDN>/api/v1/tokens/authn
GET リクエストをAdobe Pass Authentication Authorization サービスに送信して、認証を開始します。例：<SP_FQDN>/api/v1/authorize [device ID, Requestor ID, Resource ID]

応答が成功を示している場合：ユーザーに有効な AuthN トークンがあり、ユーザーがリクエストされたメディアを視聴する権限がある（このユーザーには有効な AuthZ トークンがあります）。
応答が失敗を示している場合：スローされた例外を調べて、そのタイプ（AuthN、AuthZ など）を特定します。
- AuthN エラーの場合は、登録フローを再開します。
- AuthZ エラーの場合、ユーザーは要求されたメディアを監視する権限を持っていません。ユーザーに何らかのエラーメッセージが表示されるはずです。
- その他のエラー（接続エラー、ネットワークエラーなど）が発生した場合は、適切なエラーメッセージをユーザーに表示します。

メディアフローを表示

メディアの選択肢を提示する。ユーザーが表示するメディアを選択します。
メディアは保護されていますか？

a. アプリがメディアが保護されているかどうかを確認します。

b. メディアが保護されている場合、アプリは認証を開始します
（AuthZ）上記のフロー

c. メディアが保護されていない場合は、メディアを再生する
ユーザー。
メディアを再生します。