OAuth2.0とは

OAuth2.0 は OAuth プロトコルの継続ですが、OAuth 1.0 との上位互換性はありません。OAuth2.0 は、リソース所有者と HTTP サービス プロバイダー間の組織化を通じて、クライアント開発者の簡素化に重点を置いています。承認された対話は機能します。ユーザーに代わって、またはサードパーティのアプリケーションがユーザーに代わってアクセスできるようにします。

OAuth2.0 は OAuth プロトコルの継続ですが、OAuth 1.0 との上位互換性はありません (つまり、OAuth1.0 は完全に廃止されます)。 OAuth 2.0 は、クライアント開発者にとっての簡素化に重点を置いています。ユーザーに代わってリソース所有者と HTTP プロバイダーの間の承認された対話を構築するか、サードパーティのアプリケーションがユーザーに代わってアクセスできるようにするかのいずれかです。また、Web アプリケーション、デスクトップ アプリケーション、携帯電話、リビング ルーム デバイスに専用の認証プロセスも提供します。 2012 年 10 月に、OAuth 2.0 プロトコルが RFC 6749 として正式にリリースされました。

前書き:

OAuth 1.0 はすでに IETF (国際インターネット技術特別委員会) に登録されており、RFC5849 という番号が付けられています。

これは、OAuth が正式に承認されたことを示しています。インターネット標準プロトコルになります。

OAuth 2.0 はすでに議論され、草案が作成されています。 OAuth2.0 は、次世代の「ユーザー認証と認可」標準となる可能性があります。 Baidu Open Platform や Tencent Open Platform などのほとんどのオープン プラットフォームは、サポートとして OAuth 2.0 プロトコルを使用しています。

OAuth (オープン認証) は、ユーザーが名前や名前を入力することなく、Web サイトに保存されているユーザーのプライベート リソース (写真、ビデオ、連絡先リストなど) にサードパーティのアプリケーションがアクセスできるようにするオープン スタンダードです。パスワードはサードパーティのアプリケーションに提供されます。

OAuth

ユーザーは、ユーザー名とパスワードの代わりにトークンを提供して、特定のサービス プロバイダーに保存されているデータにアクセスできるようになります。各トークンは、特定の Web サイト (ビデオ編集 Web サイトなど) が特定の期間内 (たとえば、次の 2 時間以内) に特定のリソース (たとえば、特定のアルバム内のビデオのみ) にアクセスすることを許可します。このように、OAuth を使用すると、ユーザーは、アクセス許可やデータの内容全体を共有することなく、サードパーティの Web サイトが別のサービス プロバイダーに保存されている情報にアクセスすることを承認できます。

OAuth は OpenID を補完するものですが、まったく異なるサービスです。

OAuth 2.0

は OAuth プロトコルの次のバージョンですが、OAuth 1.0 との下位互換性はありません。 OAuth 2.0 は、クライアント開発者の簡素化に重点を置きながら、Web アプリケーション、デスクトップ アプリケーション、モバイル、リビング ルームのデバイスに特化した認証フローを提供します。 2012 年 10 月に、OAuth 2.0 プロトコルが RFC 6749 [1] として正式にリリースされました。

Facebook の新しい Graph API は OAuth 2.0 のみをサポートします。Google も 2011 年 3 月に Google API の OAuth 2.0 サポートを発表しました。

認証および認可プロセス:

認証および認可プロセスに関与する 3 者:

1. サービス プロバイダー、ユーザー サービス プロバイダー写真、ビデオ、連絡先リストなどの保護されたリソースを保存します。

2. ユーザー、サービス プロバイダーに保存されている保護されたリソースの所有者。

3. クライアント、サービス プロバイダーのリソース (通常は写真印刷サービスを提供する Web サイトなどの Web サイト) にアクセスするサードパーティ アプリケーション。認証プロセスの前に、クライアントはサービス プロバイダーにクライアント ID を申請する必要があります。

OAuth を使用して認証と認可を行うプロセスは次のとおりです。

ユーザーは、サービス プロバイダーに保存されているリソースを操作したいと考えています。

ユーザーがログインし、クライアントがサービス プロバイダーに一時トークンを要求します。

サービス プロバイダーは、クライアントの ID を確認した後、一時的なトークンを付与します。

クライアントは一時トークンを取得した後、ユーザーをサービス プロバイダーの承認ページに誘導してユーザー承認を要求します。このプロセスでは、一時トークンとクライアントのコールバック接続がサービス プロバイダーに送信されます。

ユーザーはサービス プロバイダーの Web ページにユーザー名とパスワードを入力し、クライアントが要求されたリソースにアクセスすることを承認します。

認証に成功すると、サービス プロバイダーはユーザーをクライアントの Web ページに戻るように案内します。

クライアントは、一時トークンに基づいてサービス プロバイダーからアクセス トークンを取得します。

サービス プロバイダーは、一時トークンとユーザーの承認に基づいてクライアント アクセス トークンを付与します。

クライアントは、取得したアクセス トークンを使用して、サービス プロバイダーに保存されている保護されたリソースにアクセスします。

歴史の簡単なレビュー

OAuth 1.0 は 2007 年 12 月末にリリースされ、すぐに業界標準になりました。

2008 年 6 月に、OAuth 1.0 リビジョン A がリリースされました。これは、主にセキュリティの脆弱性を修正する、わずかに変更されたリビジョンです。

2010 年 4 月、OAuth 1.0 がプロトコル番号 RFC 5849 として IETF でついにリリースされました。

OAuth 2.0 のドラフトは、2011 年 5 月初旬に IETF でリリースされました。

OAuth は、ユーザーがパスワードを共有せずに Web リソースへのアクセスをサードパーティに許可できるようにするセキュリティ プロトコルです。

OAuth は、ユーザーがサードパーティにアクセスを許可できるようにするセキュリティ関連のプロトコルです。パスワードを共有せずに Web リソースにアクセスするアプリケーションは、パスワードをサードパーティ アプリケーションに公開せずにユーザーの Web リソースにアクセスします。

OAuth 2.0 はまったく新しいプロトコルであり、以前のバージョンとの下位互換性はありませんが、OAuth 2.0 は以前のバージョンの OAuth と同じ全体的なアーキテクチャを保持しています。

このドラフトは OAuth2.0 のニーズと目標に基づいており、1 年間にわたる議論を経ています。議論の参加者には、Yahoo!、Facebook、Salesforce、Microsoft など、業界のさまざまな有名企業が参加しました。 、Twitter、ドイツテレコム、Intuit、Mozilla、Google。

OAuth 2.0 の新機能:

6 つの新しいプロセス

ユーザー エージェント フロー – クライアントはユーザー エージェント (通常は Web ブラウザーなど) 内で実行されます。

Web サーバー フロー – クライアントは Web サーバー プログラムの一部であり、http リクエストを通じてアクセスします。これは、OAuth 1.0 によって提供されるプロセスの簡略化されたバージョンです。

デバイス フロー – クライアントが制限されたデバイスで操作を実行するのに適していますが、エンド ユーザーは別のコンピュータまたはデバイスのブラウザに独自にアクセスします

ユーザー名とパスワードのフロー – このプロセスの使用例は次のとおりです。ユーザーは、クライアントが ID 資格情報を処理することを信頼しているが、クライアントが自分のユーザー名とパスワードを保存することを望まない場合、このプロセスは、ユーザーがクライアントに対して高度な信頼を持っている場合にのみ適用されます。

クライアント認証情報フロー – クライアントは、その ID 認証情報を使用してアクセス トークンを取得します。このフローは、2-legged OAuth シナリオをサポートします。

アサーション フロー – クライアントは、SAML アサーションなどのアサーションをアクセス トークンと交換します。

上記の複数のプロセスを使用して、OAuth のネイティブ アプリケーション サポートを実現できます (プログラムはデスクトップ オペレーティング システムまたはモバイル デバイスで実行されます)

アプリケーション サポート (アプリケーションはデスクトップまたはモバイル デバイスで実行されます) ) ) は、上記のフローの多くを使用して実装できます。

トラストホルダー トークン

OAuth 2.0 は、暗号化を必要としない認証方法を提供します。この方法は、既存の Cookie 検証アーキテクチャに基づいています。トークン自体はシークレットとして、HTTPS 経由で送信され、HMAC とトークン シークレットを介して暗号化して送信する方法が置き換えられます。これにより、元のリクエスト メソッドや署名に従うことなく、cURL を使用して API 呼び出しやその他の単純なスクリプト ツールを開始できるようになります。

署名の簡素化:

署名サポートの場合、署名メカニズムが大幅に簡略化され、パラメーターの特別な解析、エンコード、並べ替えは必要ありません。 1 つのシークレットを使用して、元の 2 つのシークレットを置き換えます。

短期トークンと長期 ID 資格情報

元の OAuth は、非常に長い有効期間 (通常は 1 年間の有効期間または有効期限なし) のトークンを発行します。OAuth 2.0 では、サーバーは有効性の短いアクセス トークンと有効期間の長いリフレッシュ トークンを発行します。これにより、クライアントはユーザーが再度取得する必要がなく、新しいアクセス トークンを取得できるようになり、アクセス トークンの有効期間も制限されます。

役割の分離

OAuth 2.0 は 2 つの役割に分割されます:

認可サーバーはユーザーの認可の取得とトークンの発行を担当します。

リソースは API 呼び出しの処理を担当します。

以上がOAuth2.0とはの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。