OAuth 2.0 プロトコルを使用した認証
概要 overview
SAML は、US MVPDs および企業の一般的な認証に使用される主要なプロトコルですが、主な認証プロトコルとして 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 が 認証コードの付与 フロー。
フローをサポートしていることを確認した後、MVPD は以下の情報を提供する必要があります。
-
認証エンドポイント
- エンドポイントは認証コードを提供し、後で更新とアクセストークンと引き換えに使用します。
-
/token エンドポイント
- 更新トークンとアクセストークンが提供されます
- 更新トークンは安定している必要があります（新しいアクセストークンを要求するたびに変更しないでください）
- MVPD は、更新トークンごとに複数のアクティブなアクセストークンを許可する必要があります
- このエンドポイントは、アクセストークンの更新トークンも交換します
-
我々には必要だ ユーザープロファイルのエンドポイント
- このエンドポイントは、アカウントに対して一意である必要があり、個人を特定できる情報を含まない userID を提供します。
-
の /logout エンドポイント（オプション）
- Adobe Pass認証は、このエンドポイントにリダイレクトされ、MVPD にリダイレクトバック URI を提供します。このエンドポイントでは、MVPD は、クライアントマシン上の cookie を消去したり、ログアウト用に任意のロジックを適用したりできます
-
認証済みクライアント ( ユーザー認証ページをトリガーしないクライアントアプリ ) のサポートを持つことを強くお勧めします。
-
また、以下も必要です。
- clientID および クライアント秘密鍵 （統合設定用）
- 生きる時間 (TTL) 更新トークンとアクセストークンの値
- MVPD に Authorization コールバックと logout コールバック 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認証エンドポイントに認証要求を送信し、Adobe Pass認証エンドポイントは MVPD 認証エンドポイントにリダイレクトします。
-
MVPD 認証エンドポイントは、認証コードをAdobe Pass Authentication エンドポイントに送信します
-
Adobe Pass認証は、受け取った認証コードを使用して、MVPD のトークンエンドポイントから更新トークンとアクセストークンをリクエストします。
-
ユーザー情報がトークンに含まれていない場合、ユーザー情報とメタデータを取得する呼び出しをユーザープロファイルエンドポイントに送信できます
-
認証トークンは、プログラマーサイトを正常に参照できるエンドユーザーに渡されます
note note NOTE 更新トークンは、現在のアクセストークンが無効になったり有効期限が切れたりした後に、新しいアクセストークンを取得するために使用されます。
この制限は、OAuth 2.0 プロトコルの場合も更新トークンを含む AuthNToken の更新をサーバーが許可しないクライアントフローに起因します。
一般的な認証フローは、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 subject-id を含むローカルの AuthN トークンが既に存在するユーザーは、既に認証済みで、SAML 統合を通じてAdobeによって自動的にルーティングされます。
- 手順 3 のユーザーの場合、SAML で生成された AuthN トークンの期限が切れると、Adobeはそれらを新しいユーザーとして扱い、手順 2 のユーザーと同じように動作します。
- Adobeは、SAML 統合を安全に非アクティブ化できるタイミングを判断するために、使用状況パターンを確認します。