OAuth 2.0 プロトコルを使用した認証
概要 overview
SAML は、依然として米国の MVPD および企業一般による認証に使用される主なプロトコルですが、主な認証プロトコルとして OAuth 2.0 に移行する傾向が明確にあります。 OAuth 2.0 プロトコル（https://tools.ietf.org/html/rfc6749）は、主にコンシューマーサイト用に開発され、Facebook、Google、Twitter などのインターネットジャイアントによってすぐに採用されました。
OAuth 2.0 は大成功を収めており、これをサポートするために企業はインフラストラクチャをゆっくりとアップグレードする必要がありました。
OAuth 2.0 に移行するメリット adv-oauth2
大まかに言えば、OAuth 2.0 プロトコルは SAML プロトコルと同じ機能を提供しますが、いくつかの重要な違いがあります。
その 1 つは、リフレッシュトークンフローを、バックグラウンドで認証を更新する方法として使用できる点です。 これにより、IdP （この場合は MVPD）は、セキュリティ上の問題が原因でユーザーが頻繁にログインする必要がなくなるため、優れたユーザーエクスペリエンスを提供しながら、制御を維持できます。
また、サービスプロバイダーがトークンを使用して他の API にアクセスし、追加情報を取得できるようになったので、このプロトコルは公開されるデータの点でもより柔軟性が高くなっています。 これにより、TVE のユースケースでは「おしゃべり」プロトコルになりますが、複雑なワークフローに必要な柔軟性が得られます。
OAuth 2.0 への切り替えの要件 oauth-req
OAuth 2.0 での認証をサポートするには、MVPDが次の前提条件を満たしている必要があります。
まず第一に、MVPDが 認証コード付与 フローをサポートしていることを確認する必要があります。
フローがサポートされていることを確認した後、MVPDは次の情報を提供する必要があります。
-
認証エンドポイント
- エンドポイントは認証コードを提供し、これは後で更新トークンとアクセストークンと交換に使用されます
-
/token エンドポイント
- これにより、更新トークンとアクセストークンが提供されます
- 更新トークンは安定している必要があります（新しいアクセストークンをリクエストするたびに変更することはできません）
- MVPDでは、更新トークンごとに複数のアクティブなアクセストークンを許可する必要があります
- このエンドポイントは、アクセストークンの更新トークンも交換します
-
ユーザープロファイルには エンドポイント が必要です
- このエンドポイントは、ユーザー ID を提供します。この ID は、アカウントに対して一意である必要があり、個人を特定できる情報を含めることはできません
-
/ログアウト エンドポイント（オプション）
- Adobe Pass認証は、このエンドポイントにリダイレクトし、MVPDにリダイレクトバック URI を指定します。このエンドポイントでは、MVPDは、クライアントマシンの Cookie をクリアするか、ログアウトに必要なロジックを適用できます
-
承認済みクライアント（ユーザー認証ページをトリガーしないクライアントアプリ）をサポートすることを強くお勧めします
-
また、次も必要です。
- 統合設定用の clientID および client secret
- 更新トークンとアクセストークンの 有効期間 （TTL）値
- MVPDに認証コールバックとログアウトコールバック URI を指定できます。 また、必要に応じて、ファイアウォール設定で許可リストに登録する IP のリストを MVPD に提供することもできます。
認証フロー authn-flow
認証フローでは、Adobe Pass認証は、設定で選択されたプロトコルでMVPDと通信します。 次の図に、OAuth 2.0 フローを示します。
図 1: OAuth 2.0 認証フロー
認証のリクエストと応答 authn-req-response
一言で言えば、OAuth 2.0 プロトコルをサポートする MVPD の認証フローは次の手順に従います。
-
エンドユーザーがプログラマーのサイトに移動し、MVPDの資格情報を使用してログインします
-
プログラマー側でインストールされ、HTTP リクエストの形式でMVPD Authentication エンドポイントに認証リクエストを送信する AccessEnabler。このリクエストは、Adobe Pass Authentication エンドポイントがAdobe Pass Authorization エンドポイントにリダイレクトするものです。
-
MVPD認証エンドポイントは、認証コードをAdobe Pass認証エンドポイントに送信します
-
Adobe Pass認証は、受信した認証コードを使用して、MVPD認証トークンエンドポイントからの更新トークンとアクセストークンをリクエストします。
-
ユーザー情報とメタデータを取得する呼び出しは、ユーザー情報がトークンに含まれていない場合は、ユーザープロファイルエンドポイントに送信できます
-
認証トークンは、正常にプログラマーサイトを閲覧できるエンドユーザーに渡されます
note note NOTE 更新トークンは、現在のアクセストークンが無効になった後、または期限切れになった後に、新しいアクセストークンを取得するために使用されます。
この制限は、サーバーが AuthNToken を更新できないクライアントフローに起因します。このフローには、OAuth 2.0 プロトコルの場合、更新トークンも含まれています。
一般的な認証フローは、AuthNToken に保存されたリフレッシュトークンとアクセストークンを交換し、その後、最初に認証されたユーザーの名前で認証呼び出しを実行するために使用されます。 認証サーバー（MVPD）が更新トークンを変更し、古いトークンを無効にした場合、有効な AuthNToken を更新できません。 このため、MVPD は OAuth 2.0 統合を設定できるように、安定した更新トークンをサポートする必要があります。
SAML から OAuth 2.0 への移行 saml-auth2-migr
SAML から OAuth 2.0 への統合の移行は、AdobeおよびMVPDによって実行されます。 プログラマー側の技術的な変更は必要ありませんが、プログラマーはMVPDのログインページでブランド提携を確認/テストする必要があります。 MVPDの観点から見ると、Oauth 2.0 の要件でリクエストされるエンドポイントとその他の情報が必要です。
SSO を保持 するために、SAML を介して既に認証トークンを取得しているユーザーは引き続き認証済みと見なされ、そのリクエストは古い SAML 統合を介してルーティングされます。
技術的な観点から：
- Adobeは、SAML 統合を削除せずに、プログラマーとMVPDの間で OAuth 2.0 統合を有効にします。
- イネーブルメント後、すべての新規ユーザーは、OAuth 2.0 フローを使用します。
- SAML サブジェクト ID を含むローカル AuthN トークンを既に持つ認証済みのユーザーは、SAML 統合を通じてAdobeによって自動的にルーティングされます。
- 手順 3 のユーザーの場合、SAML 生成 AuthN トークンの有効期限が切れると、Adobeはそれらを新規ユーザーとして扱い、手順 2 のユーザーのように動作します。
- Adobeでは、SAML 統合を安全に非アクティブ化できる瞬間を判断するために、使用パターンを確認します。