Loading article…
OAuth（オープン認証の略）[ 1 ] [ 2 ]は、アクセス委任のためのオープンスタンダードであり、インターネットユーザーがウェブサイトやアプリケーションにパスワードを教えることなく、他のウェブサイト上の情報へのアクセスを許可する方法として一般的に使用されています。[ 3 ] [ 4 ]このメカニズムは、 Amazon [ 5 ]、Google、Meta Platforms、Microsoft、Twitterなどの企業によって、ユーザーがアカウントに関する情報をサードパーティのアプリケーションやウェブサイトと共有できるようにするために使用されています。
一般的に、OAuth プロトコルは、リソース所有者がクライアント アプリケーションにサーバー リソースへの安全な委任アクセスを提供する方法を提供します。これは、リソース所有者が認証情報を提供することなく、サードパーティによるサーバー リソースへのアクセスを承認するプロセスを規定しています。特にHypertext Transfer Protocol (HTTP) と連携するように設計された OAuth は、基本的に、リソース所有者の承認を得て、認証サーバーがサードパーティ クライアントにアクセス トークンを発行することを可能にします。サードパーティは、そのアクセス トークンを使用して、リソース サーバーによってホストされている保護されたリソースにアクセスします。 [ 2 ]
OAuthは、 Blaine CookがTwitter向けに OpenIDの実装を開発していた2006年11月に始まりました。一方、Ma.gnoliaは、OpenIDを持つメンバーがMac OS X Dashboardウィジェットにサービスへのアクセスを許可できるようにするソリューションを必要としていました。Cook、 Chris Messina、MagnoliaのLarry Halffは、David Recordonと会って、TwitterとMagnoliaのAPIでOpenIDを使用して認証を委任することについて話し合いました。彼らは、APIアクセス委任のためのオープンスタンダードは存在しないという結論に至りました。[ 6 ]
OAuthディスカッション グループは、オープン プロトコルのドラフト提案を作成するために、少数の実装者グループのために 2007 年 4 月に設立されました。Google の DeWitt Clinton はOAuthプロジェクトを知り、この取り組みを支援することに興味を示しました。2007 年 7 月、チームは最初の仕様をドラフトしました。Eran Hammer が参加し、より正式な仕様を作成するための多くの OAuth 貢献を調整しました。2007 年 10 月 3 日、OAuth Core 1.0 の最終ドラフトがリリースされました。[ 6 ]
2008年11月にミネアポリスで開催された第73回インターネット技術タスクフォース（IETF）会議において、OAuthプロトコルをIETFに導入し、さらなる標準化作業を進めるためのOAuthに関する会合（ BoF）が開催された。この会合には多くの参加者が集まり、IETF内にOAuthワーキンググループを正式に設立することに対して幅広い支持が得られた。
OAuth 1.0 プロトコルは、情報提供のためのリクエスト・フォー・コメントであるRFC 5849として2010 年 4 月に公開されました。2010 年 8 月 31 日以降、すべてのサードパーティの Twitter アプリケーションは OAuth を使用することが義務付けられています。[ 7 ]
OAuth 2.0 フレームワークは、IETF コミュニティ全体から収集された追加のユース ケースと拡張性の要件を考慮して公開されました。OAuth 1.0 の展開経験に基づいて構築されていますが、OAuth 2.0 は OAuth 1.0 との下位互換性はありません。OAuth 2.0 はRFC 6749として、Bearer Token Usage 仕様はRFC 6750として、2012 年 10 月に公開されました。どちらの標準も Requests for Comments を追跡しています。[ 2 ] [ 8 ]
2024年11月現在、OAuth 2.1認証フレームワークのドラフトは開発中です。これは、RFC OAuth 2.0、ネイティブアプリ向けOAuth 2.0、コード交換用プルーフキー、ブラウザベースアプリ向けOAuth 2.0、OAuthセキュリティベストカレント、ベアラートークン使用法の機能を統合したものです。[ 9 ]
2009年4月23日、 1.0プロトコルのセッション固定セキュリティの欠陥が発表されました。これは、OAuth Core 1.0セクション6のOAuth認証フロー（「3レッグOAuth」とも呼ばれる）に影響します。[ 10 ] この問題を解決するために、OAuth Coreプロトコルのバージョン1.0aが発行されました。[ 11 ]
2013 年 1 月に、インターネット技術タスク フォースは OAuth 2.0 の脅威モデルを公開しました。[ 12 ]概説されている脅威の中には「オープン リダイレクター」と呼ばれるものがあり、2014 年初頭に、その亜種が Wang Jing によって「コバート リダイレクト」という名前で説明されました。[ 13 ] [ 14 ] [ 15 ] [ 16 ]
OAuth 2.0 は、形式的な Web プロトコル分析を使用して分析されています。この分析により、複数の認証サーバーがあり、そのうちの 1 つが悪意を持って動作している場合、クライアントは使用すべき認証サーバーについて混乱し、秘密情報を悪意のある認証サーバーに転送する可能性があることが明らかになりました (AS Mix-Up 攻撃)。[ 17 ]このことから、OAuth 2.0 の新しいセキュリティ標準を定義することを目的とした、新しいベスト 現行の実践インターネット ドラフトが作成されました。 [ 18 ] AS Mix-Up 攻撃に対する修正が実施されていると仮定すると、OAuth 2.0 のセキュリティは、形式分析を使用して強力な攻撃者モデルの下で証明されています。[ 17 ]
多数のセキュリティ上の欠陥があるOAuth 2.0の実装が1つ明らかになった。[ 19 ]
2017 年 4 月と 5 月には、約 100 万人のGmailユーザー(2017 年 5 月時点のユーザーの 0.1% 未満) が OAuth ベースのフィッシング攻撃の標的となり、同僚、雇用主、または友人から Google Docs でドキュメントを共有したいというメールを受け取りました。[ 20 ]メール内のリンクをクリックしたユーザーは、サインインして、「Google Apps」と呼ばれる潜在的に悪意のあるサードパーティ プログラムが「メール アカウント、連絡先、オンライン ドキュメント」にアクセスすることを許可するように指示されました。[ 20 ]「約 1 時間」以内に[ 20 ] 、フィッシング攻撃は Google によって阻止され、Google は「Google Apps」にメールへのアクセスを許可したユーザーに、そのアクセスを取り消してパスワードを変更するように勧告しました。
OAuth 2.1 のドラフトでは、悪意のあるブラウザ拡張機能が OAuth 2.0 コードインジェクション攻撃を実行するのを防ぐために、Web アプリケーションやその他の機密クライアントを含むあらゆる種類の OAuth クライアントに対して、ネイティブ アプリ用のPKCE ( RFC 7636 ) 拡張機能の使用が推奨されています。 [ 9 ]
OAuthフレームワークは、さまざまなユースケースに対応するためにいくつかのグラントタイプを規定しています。最も一般的なOAuthグラントタイプには、次のものがあります。[ 21 ]
FacebookのGraph API はOAuth 2.0 のみをサポートしています。[ 22 ] Google は、すべてのAPIの推奨認証メカニズムとして OAuth 2.0 をサポートしています。[ 23 ] Microsoft もさまざまな API と Azure Active Directory サービスで OAuth 2.0 をサポートしています。[ 24 ]これは、多くの Microsoft API とサードパーティ API を保護するために使用されます。
OAuthは、セキュリティで保護されたRSS / Atomフィードへのアクセスを認証するメカニズムとして使用できます。認証が必要なRSS/ATOMフィードへのアクセスは、これまで常に課題となっていました。例えば、セキュリティで保護されたGoogleサイトのRSSフィードには、 Google Readerを使用してアクセスすることはできませんでした。代わりに、3者間OAuthを使用して、そのRSSクライアントがGoogleサイトのフィードにアクセスできるように認証する必要がありました。
LibreOffice OAuth2OOo拡張機能などのOAuth2プロトコルのフリーソフトウェアクライアント実装を使用すると、リモートリソース（Google APIやMicrosoft Graph API、OAuth 2.0経由など）にアクセスできるだけでなく、 LibreOffice Basic言語からもアクセスできるようになります。これにより、LibreOfficeマクロでOAuth 2.0プロトコルをサポートするHTTPリクエストを簡単に記述して使用できるようになります。
OAuthはOpenIDを補完するサービスであり、OpenIDとは異なるものです。OAuthは認証のリファレンスアーキテクチャであるOATHとは無関係であり、認可の標準ではありません。しかし、OAuthはOpenID Connect（OIDC）と直接関連しています。OIDCはOAuth 2.0の上に構築された認証レイヤーだからです。OAuthは認可ポリシーの標準であるXACMLとも無関係です。OAuthはXACMLと組み合わせて使用でき、所有権の同意とアクセス権限の委任にOAuthを使用し、認可ポリシー（例：管理者は自分の地域のドキュメントを閲覧できる）を定義するためにXACMLを使用します。
OAuthは認証プロトコルではなく認可プロトコルです。OAuthを認証方法として単独で使用することは、擬似認証と呼ばれることがあります。[ 25 ]次の図は、OpenID（認証プロトコルとして特別に設計されたもの）とOAuthを認可に使用する場合の違いを強調しています。
両プロセスにおけるコミュニケーションの流れは類似している。
決定的な違いは、OpenID認証の場合、IDプロバイダからの応答はIDの表明であるのに対し、OAuth認可の場合、IDプロバイダはAPIプロバイダでもあり、IDプロバイダからの応答は、ユーザーに代わってアプリケーションがIDプロバイダのAPIの一部に継続的にアクセスすることを許可するアクセストークンであるという点です。アクセストークンは、アプリケーションがIDプロバイダへのリクエストに含めることができる一種の「バレットキー」として機能し、ユーザーからAPIへのアクセス許可を得ていることを証明します。
IDプロバイダーは通常（常にではないが）、OAuthアクセストークンを付与するプロセスの一部としてユーザーを認証するため、OAuthアクセストークン要求の成功自体を認証方法とみなしたくなる。しかし、OAuthはこのユースケースを念頭に置いて設計されたものではないため、この仮定は重大なセキュリティ上の欠陥につながる可能性がある。[ 26 ]
XACMLは、ポリシーベースかつ属性ベースのアクセス制御認可フレームワークです。以下の機能を提供します。
XACMLとOAuthを組み合わせることで、より包括的な認証方法を実現できます。OAuthにはアクセス制御ポリシーを定義するためのポリシー言語がありませんが、XACMLはそのポリシー言語として利用できます。
OAuthは委任アクセス（ユーザーである私がTwitterに私のFacebookウォールへのアクセスを許可する）とアイデンティティ中心の認可に焦点を当てていますが、XACMLはユーザー、アクション、リソース、コンテキスト（誰が、何を、どこで、いつ、どのように）の属性を考慮できる属性ベースのアプローチを採用しています。XACMLでは、次のようなポリシーを定義することが可能です。
XACMLは、OAuthよりもきめ細かなアクセス制御を提供します。OAuthの粒度は、対象サービスによって公開される大まかな機能（スコープ）に限定されます。そのため、OAuthとXACMLを組み合わせるのが理にかなっている場合が多く、OAuthは委任アクセスと同意管理を提供し、XACMLはアプリケーション、プロセス、データに対して機能する認可ポリシーを提供します。
最後に、XACMLは複数のスタック（ API、Web SSO、ESB、自社開発アプリケーション、データベースなど）間で透過的に動作します。一方、OAuthはHTTPベースのアプリケーションに特化しています。
エラン・ハマーは、2012年7月にOAuth 2.0プロジェクトの主任著者を辞任し、IETFワーキンググループから脱退し、仕様から自分の名前を削除した。ハマーは、辞任の理由としてウェブ文化と企業文化の衝突を挙げ、IETFは「企業ユースケースばかり」で「単純なことはできない」コミュニティだと指摘した。「現在提供されているのは認可プロトコルの設計図であり、これは企業流のやり方だ」とハマーは述べ、「コンサルティングサービスや統合ソリューションを販売するためのまったく新しいフロンティア」を提供していると付け加えた。[ 27 ] OAuth 2.0とOAuth 1.0を比較して、ハマーは「より複雑になり、相互運用性が低下し、有用性が低下し、不完全になり、そして最も重要なことに、セキュリティが低下した」と指摘している。彼は、2.0のアーキテクチャ変更により、クライアントからのトークンがバインドされなくなり、プロトコルレベルですべての署名と暗号化が削除され、有効期限付きトークンが追加され（トークンを取り消すことができなかったため）、認可の処理が複雑になったと説明している。仕様書には多くの項目が未指定または無制限のまま残されているが、それは「このワーキンググループの性質上、どんな小さな問題でも、それに固執したり、各実装が決定できるように未解決のままにしておくことはできない」ためである。[ 27 ]
デビッド・レコーダンも後に、理由は不明ながら仕様書から自分の名前を削除した。ディック・ハルトが編集者の役割を引き継ぎ、フレームワークは2012年10月に公開された。[ 2 ]
メールクライアントPegasus Mailの作者であるDavid Harris氏は、OAuth 2.0を「全くの混乱状態」と批判し、開発者は各サービス（Gmail、Microsoft Mailサービスなど）に特化したカスタムモジュールを作成し、それぞれに個別に登録する必要があると述べている。[ 28 ]