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 プロトコルと同じ機能を提供しますが、大きな違いがあります。

そのひとつは、更新トークンフローをバックグラウンドで認証を更新する方法として使用できることです。 これにより、IdP （この場合はMVPD）が制御を維持しながら、セキュリティ上の懸念により、ユーザーが頻繁にログインする必要がなくなるため、優れたユーザーエクスペリエンスを提供できます。

また、このプロトコルは、サービスプロバイダーがトークンを使用して他のAPIにアクセスし、追加情報を取得できるように、公開されたデータに関してより柔軟な機能を提供します。 これにより、TVEのユースケースに対応する「チャッティアー」プロトコルが実現しますが、複雑なワークフローに必要な柔軟性を備えています。

OAuth 2.0への切り替えの要件 oauth-req

OAuth 2.0での認証をサポートするには、MVPDが次の前提条件を満たす必要があります。

まず、MVPDが認証コード付与 フローをサポートしていることを確認する必要があります。

フローをサポートしていることを確認した後、MVPDは次の情報を提供する必要があります。

認証フロー authn-flow

認証フローでは、Adobe Pass Authenticationは、設定で選択したプロトコルでMVPDと通信します。 OAuth 2.0 フローは、次の図に示されています。

図1: OAuth 2.0認証フロー

認証リクエストと応答 authn-req-response

簡単に言えば、OAuth 2.0 プロトコルをサポートするMVPDの認証フローは次の手順に従います。

この制限は、サーバーがAuthNTokenを更新することを許可しないクライアントフローに起因します。この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統合を介してルーティングされます。

技術的な観点：