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 が Authorization Code Grant フローをサポートしていることを確認する必要があります。
MVPD がフローをサポートしていることを確認したら、次の情報を提供する必要があります。
-
認証エンドポイント
- エンドポイントは認証コードを提供し、これは後で更新トークンとアクセストークンと交換に使用されます
-
/token エンドポイント
- これにより、更新トークンとアクセストークンが提供されます
- 更新トークンは安定している必要があります（新しいアクセストークンをリクエストするたびに変更することはできません）
- mvpd は、更新トークンごとに複数のアクティブなアクセストークンを許可する必要があります。
- このエンドポイントは、アクセストークンの更新トークンも交換します
-
ユーザープロファイルには エンドポイント が必要です
- このエンドポイントは、ユーザー ID を提供します。この ID は、アカウントに対して一意である必要があり、個人を特定できる情報を含めることはできません
-
/ログアウト エンドポイント（オプション）
- Adobe Pass認証は、このエンドポイントにリダイレクトし、MVPD にリダイレクトバック URI を指定します。このエンドポイントでは、MVPD は、クライアントマシンの Cookie をクリアするか、ログアウトに必要なロジックを適用できます
-
承認済みクライアント（ユーザー認証ページをトリガーしないクライアントアプリ）をサポートすることを強くお勧めします
-
また、次も必要です。
- 統合設定用の clientID および client secret
- 更新トークンとアクセストークンの 有効期間 （TTL）値
- MVPD に認証コールバックとログアウトコールバック URI を提供できます。 また、必要に応じて、ファイアウォール設定で許可リストに登録する IP のリストを MVPD に提供することもできます。
認証フロー authn-flow
認証フローでは、Adobe Pass Authentication は、設定で選択されたプロトコルで MVPD と通信します。 次の図に、OAuth 2.0 フローを示します。
図 1: OAuth 2.0 認証フロー
認証のリクエストと応答 authn-req-response
一言で言えば、OAuth 2.0 プロトコルをサポートする MVPD の認証フローは次の手順に従います。
-
エンドユーザーがプログラマーのサイトに移動し、MVPD 資格情報でログインすることを選択します
-
AccessEnabler は、プログラマ側でインストールされ、HTTP リクエスト形式の認証リクエストをAdobe Pass Authentication エンドポイントに送信します。このリクエストは、Adobe Pass Authentication エンドポイントから MVPD Authorization エンドポイントにリダイレクトされます。
-
MVPD 認証エンドポイントは、認証コードをAdobe Pass認証エンドポイントに送信します
-
Adobe Pass Authentication は、受信した認証コードを使用して、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 のユーザーのように動作します。
- SAML 統合を安全に非アクティブ化できる瞬間を判断するために、Adobeは使用パターンを確認します。