オーソリティ

クリス・メッシーナがデザインした非公式ロゴ
最新バージョン	2.0
組織	インターネットエンジニアリングタスクフォース
Webサイト	Hardt, Dick (2012 年 10 月)。「OAuth 2.0 認証フレームワーク」。

OAuth（オープン認証^{[1] [2]の略）は、アクセス}委任のオープン標準であり、インターネットユーザーがウェブサイトやアプリケーションに他のウェブサイト上の自分の情報へのアクセスを許可する方法として一般的に使用されていますが、パスワードは提供されません。^{[3] [4]このメカニズムは、} Amazon、^[5] Google、Meta Platforms、Microsoft、Twitterなどの企業で、ユーザーが自分のアカウントに関する情報をサードパーティのアプリケーションやウェブサイトと共有できるようにするために使用されています。

一般的に、OAuth プロトコルは、リソース所有者がクライアント アプリケーションにサーバー リソースへの安全な委任アクセスを提供する方法を提供します。これは、リソース所有者が資格情報を提供せずにサーバー リソースへのサードパーティ アクセスを承認するプロセスを指定します。ハイパーテキスト転送プロトコル(HTTP) で動作するように特別に設計された OAuth では、基本的に、リソース所有者の承認を得て、承認サーバーがサードパーティ クライアントにアクセス トークンを発行できます。サードパーティは、アクセス トークンを使用して、リソース サーバーがホストする保護されたリソースにアクセスします。^[2]

OAuth は、Blaine Cook がTwitter OpenID実装を開発していた2006 年 11 月に始まりました。一方、Ma.gnolia は、OpenID を持つメンバーがダッシュボード ウィジェットにサービスへのアクセスを許可できるようにするソリューションを必要としていました。Magnolia の Cook、 Chris Messina、Larry Halff はDavid Recordonと会い、Twitter および Magnolia APIで OpenID を使用して認証を委任することについて話し合いました。彼らは、API アクセス委任のオープン スタンダードは存在しないという結論に達しました。^[6]

OAuthディスカッション グループは、2007 年 4 月に、実装者の小グループがオープン プロトコルの草案を作成するために作成されました。Google の DeWitt Clinton はOAuthプロジェクトについて知り、この取り組みを支援することに関心を示しました。2007 年 7 月、チームは最初の仕様を草案​​しました。Eran Hammer が参加し、より正式な仕様を作成するための多くの OAuth 貢献を調整しました。2007 年 12 月 4 日、OAuth Core 1.0 の最終草案がリリースされました。^[7]

2008 年 11 月にミネアポリスで開催された第 73 回インターネット エンジニアリング タスク フォース(IETF) 会議では、さらなる標準化作業のためにプロトコルを IETF に導入することについて議論するOAuth BoFが開催されました。このイベントには多くの参加者が集まり、IETF 内で OAuth ワーキング グループを正式に設立することに対する幅広い支持が得られました。

OAuth 1.0プロトコルは、2010年4月に情報提供のためのRequest for Comments （RFC 5849）として公開されました。2010年8月31日以降、すべてのサードパーティのTwitterアプリケーションはOAuthを使用することが義務付けられています。^[8]

OAuth 2.0フレームワークは、より広範なIETFコミュニティから集められた追加のユースケースと拡張性要件を考慮して公開されました。OAuth 1.0の導入経験に基づいて構築されていますが、OAuth 2.0はOAuth 1.0との下位互換性はありません。OAuth 2.0はRFC 6749として、ベアラートークンの使用法^{[説明が必要]}はRFC 6750として2012年10月に公開されました。両方の標準はコメント要求を追跡しています。^{[2] [9]}

OAuth 2.1認可フレームワークはドラフト段階にあり、RFC OAuth 2.0、OAuth 2.0 for Native Apps、Proof Key for Code Exchange、OAuth 2.0 for Browser-Based Apps、OAuth Security Best Current、Bearer Token Usageの機能を統合しています。^[10]

2009年4月23日、 1.0プロトコルにおけるセッション固定のセキュリティ欠陥が発表されました。これは、OAuth Core 1.0セクション6のOAuth認証フロー（「3レッグOAuth」とも呼ばれる）に影響します。^[11] この問題に対処するために、OAuth Coreプロトコルのバージョン1.0aが発行されました。^[12]

2013年1月、インターネット技術タスクフォースはOAuth 2.0の脅威モデルを公開した。^[13]概説された脅威の中には「オープンリダイレクタ」と呼ばれるものがあり、2014年初頭には、この亜種が「カバートリダイレクト」という名前で王静によって説明された。^{[14] [15] [16] [17]}

OAuth 2.0 は、正式な Web プロトコル分析を使用して分析されています。この分析により、複数の認可サーバーがあり、そのうちの 1 つが悪意を持って動作している場合、クライアントは使用する認可サーバーについて混乱し、悪意のある認可サーバーに秘密を転送する可能性があることが明らかになりました (AS ミックスアップ攻撃)。^[18]これにより、OAuth 2.0 の新しいセキュリティ標準を定義するための新しいベストカレントプラクティスインターネットドラフトが作成されました。 ^[19] AS ミックスアップ攻撃に対する修正が実施されていると仮定すると、OAuth 2.0 のセキュリティは、正式な分析を使用して強力な攻撃者モデルの下で証明されています。^[18]

多数のセキュリティ上の欠陥があるOAuth 2.0の実装が公開されました。^[20]

2017年4月と5月、 Gmailの約100万人のユーザー（2017年5月時点でユーザーの0.1%未満）がOAuthベースのフィッシング攻撃の標的となり、同僚、雇用主、友人を装ってGoogle Docsで文書を共有したいというメールを受信しました。^[21]メール内のリンクをクリックした人はサインインするように指示され、「Google Apps」と呼ばれる潜在的に悪意のあるサードパーティプログラムが自分の「メールアカウント、連絡先、オンラインドキュメント」にアクセスできるようになりました。^[21]「約1時間以内」に^[21]フィッシング攻撃はGoogleによって阻止され、「Google Apps」にメールへのアクセスを許可した人に対して、そのようなアクセスを取り消してパスワードを変更するようにアドバイスされました。

OAuth 2.1のドラフトでは、悪意のあるブラウザ拡張機能によるOAuth 2.0コードインジェクション攻撃を防ぐために、Webアプリケーションやその他の機密クライアントを含むあらゆる種類のOAuthクライアントに、ネイティブアプリ用のPKCE（RFC 7636）拡張機能の使用が推奨されています。^[10]

OAuthフレームワークは、さまざまなユースケースに合わせていくつかの付与タイプを指定します。最も一般的なOAuth付与タイプは次のとおりです。^[22]

• 認証コード
• PKCE
• クライアントの資格情報
• デバイスコード
• リフレッシュトークン

FacebookのGraph APIはOAuth 2.0のみをサポートしています。^[23] Googleは、すべてのAPIの推奨認証メカニズムとしてOAuth 2.0をサポートしています。^[24] Microsoftも、さまざまなAPIとAzure Active DirectoryサービスでOAuth 2.0をサポートしており、^[25]多くのMicrosoftおよびサードパーティのAPIを保護するために使用されています。

OAuth は、セキュリティ保護されたRSS / Atomフィードにアクセスするための認証メカニズムとして使用できます。認証を必要とする RSS/ATOM フィードへのアクセスは、常に問題となっていました。たとえば、セキュリティ保護されたGoogle サイトの RSS フィードには、 Google Reader を使用してアクセスすることはできませんでした。代わりに、3 レッグ OAuth を使用して、その RSS クライアントが Google サイトのフィードにアクセスできるように認証します。

OAuth は、 OpenID を補完しつつも OpenID とは異なるサービスです。OAuth は、認証のリファレンス アーキテクチャであり認可の標準ではないOATHとは無関係です。ただし、 OIDC は OAuth 2.0 上に構築された認証レイヤーであるため、 OAuth はOpenID Connect (OIDC) と直接関連しています。OAuth は認可ポリシー標準であるXACMLとも無関係です。OAuth は XACML と組み合わせて使用​​できます。その場合、OAuth は所有権の同意とアクセスの委任に使用され、XACML は認可ポリシーの定義に使用されます (例: マネージャーは自分の地域のドキュメントを表示できます)。

OAuthは認証プロトコルではなく認可プロトコルです。OAuthを認証方法として単独で使用することは、疑似認証と呼ばれることがあります。^[26]次の図は、認可にOpenID（認証プロトコルとして特別に設計）とOAuthを使用する場合の違いを示しています。

両方のプロセスにおける通信フローは似ています。

1. (図には示されていません) ユーザーはアプリケーションからリソースまたはサイトへのログインを要求します。
2. サイトはユーザーが認証されていないことを認識します。ID プロバイダーへのリクエストを作成し、それをエンコードして、リダイレクト URL の一部としてユーザーに送信します。
3. ユーザーのブラウザは、アプリケーションのリクエストを含むアイデンティティプロバイダのリダイレクトURLにリクエストを送信します。
4. 必要に応じて、アイデンティティプロバイダはユーザーを認証します（ユーザー名とパスワードを要求するなど）。
5. アイデンティティ プロバイダーは、ユーザーが十分に認証されていることを確認すると、アプリケーションの要求を処理し、応答を作成して、アプリケーションへのリダイレクト URL とともにユーザーに返します。
6. ユーザーのブラウザは、アイデンティティプロバイダの応答を含む、アプリケーションに戻るリダイレクトURLを要求します。
7. アプリケーションは ID プロバイダーの応答をデコードし、それに応じて処理を続行します。
8. (OAuth のみ) 応答には、アプリケーションがユーザーに代わって ID プロバイダーのサービスに直接アクセスするために使用できるアクセス トークンが含まれます。

重要な違いは、OpenID認証の使用例では、アイデンティティ プロバイダーからの応答がアイデンティティのアサーションであるのに対し、OAuth承認の使用例では、アイデンティティ プロバイダーはAPIプロバイダーでもあり、アイデンティティ プロバイダーからの応答は、ユーザーに代わってアプリケーションにアイデンティティ プロバイダーの API の一部への継続的なアクセスを許可するアクセス トークンであることです。アクセス トークンは、アプリケーションがアイデンティティ プロバイダーへのリクエストに含めることができる一種の「バレット キー」として機能し、ユーザーからそれらの API にアクセスする許可を得ていることを証明します。

アイデンティティプロバイダは通常（常にではありませんが）、OAuthアクセストークンを付与するプロセスの一環としてユーザーを認証するため、成功したOAuthアクセストークン要求自体を認証方法と見なすのは魅力的です。しかし、OAuthはこのユースケースを念頭に置いて設計されたものではないため、このような仮定をすると重大なセキュリティ上の欠陥につながる可能性があります。^[27]

XACML は、ポリシーベース、属性ベースのアクセス制御認可フレームワークです。次の機能を提供します。

• アクセス制御アーキテクチャ。
• OAuth 経由で処理/定義された同意を使用できるポリシーを含む、幅広いアクセス制御ポリシーを表現するためのポリシー言語。
• 認可リクエストを送受信するためのリクエスト/レスポンス スキーム。

XACML と OAuth を組み合わせることで、より包括的な認証アプローチを実現できます。OAuth では、アクセス制御ポリシーを定義するためのポリシー言語は提供されません。ポリシー言語として XACML を使用できます。

OAuth が委任アクセス (ユーザーである私が Twitter に Facebook のウォールへのアクセスを許可する) とアイデンティティ中心の認可に重点を置いているのに対し、XACML は属性ベースのアプローチを採用しており、ユーザー、アクション、リソース、コンテキスト (誰が、何を、どこで、いつ、どのように) の属性を考慮できます。XACML では、次のようなポリシーを定義することができます。

• 管理者は自分の部門の文書を閲覧できる
• マネージャーは下書きモードで所有するドキュメントを編集できます

XACML は、OAuth よりもきめ細かなアクセス制御を提供します。OAuth の粒度は、ターゲット サービスによって公開される粗い機能 (スコープ) に制限されています。そのため、OAuth と XACML を組み合わせて、OAuth が委任アクセスのユース ケースと同意管理を提供し、XACML がアプリケーション、プロセス、およびデータで機能する承認ポリシーを提供するのが理にかなっている場合がよくあります。

最後に、XACML は複数のスタック ( API、Web SSO、ESB、自社開発アプリ、データベースなど) にわたって透過的に動作できます。OAuth は HTTP ベースのアプリにのみ焦点を当てています。

エラン・ハマーは、OAuth 2.0プロジェクトの主執筆者を辞任し、IETFワーキンググループから脱退し、2012年7月に仕様から名前を削除した。ハマーは、ウェブ文化とエンタープライズ文化の対立を脱退の理由として挙げ、IETFは「エンタープライズユースケースがすべて」であり「単純なことはできない」コミュニティであると述べた。「現在提供されているのは、認可プロトコルの青写真であり、それがエンタープライズのやり方である」と彼は述べ、「コンサルティングサービスと統合ソリューションを販売するためのまったく新しいフロンティア」を提供している。^[28] OAuth 2.0とOAuth 1.0を比較して、ハマーはOAuth 2.0が「より複雑になり、相互運用性が低く、有用性が低く、不完全になり、そして最も重要なことに、安全性が低くなった」と指摘している。彼は、2.0のアーキテクチャ変更により、クライアントからバインドされていないトークンが削除され、プロトコルレベルですべての署名と暗号化が削除され、期限切れのトークン（トークンを取り消すことができないため）が追加され、認可の処理が複雑になったと説明している。仕様では多くの項目が未指定または無制限のまま残されているが、これは「このワーキンググループの性質上、どんな問題も小さすぎて行き詰まったり、各実装で決定できないままにしておくことはできない」ためである。^[28]

デビッド・レコードンも後に、理由は不明だが仕様から自分の名前を削除した。^[要出典] ディック・ハートが編集者の役割を引き継ぎ、フレームワークは2012年10月に公開された。^[2]

電子メールクライアント「Pegasus Mail」の作者であるDavid Harris氏は、OAuth 2.0は「まったくの無茶苦茶」だと批判しており、開発者は各サービス（Gmail、Microsoft Mailサービスなど）に固有のカスタムモジュールを作成し、それらに個別に登録する必要があるとしている。^[29]

• OAuth プロバイダーのリスト
• データのポータビリティ
• インディオース
• Mozilla ペルソナ
• セキュリティアサーションマークアップ言語
• ユーザー管理アクセス

• Hardt, Dick (2012 年 10 月)。「OAuth 2.0 認証フレームワーク」。インターネット エンジニアリング タスク フォース。