.NET開発基盤部会」によって運営されています。2.0は認証で使用できるが、以下の問題がある。2.0について言及する。2.0は、認証ではなく認可のためのプロトコル(権限委譲プロトコル)。OwnerとClientを分離することができる。OwnerのCredentialsをClientに渡す必要が無くなる。Serverへのアクセスを認可できるようになる。†OpenIDを使ってTwitterやMa.gnoliaのAPIの認証委譲する方法を議論を開始。2007/4にOAuthのコミュニティが誕生。2007/7にOAuthの仕様の草案が完成。2008/11、第73回のIETF会合でOAuthの非公式会合も開かれ、さらなる標準化に向けてIETFにOAuthプロトコルを提案するかどうかを議論。1.0のセキュリティ問題が判明。1.0aで修正された。1.0とは後方互換性を持たない。次世代のOAuthプロトコルとして、2012年にRFCとして発行された。Application)モバイルやデスクトップアプリ(ガイドライン程度しか定義されていない)自立クライアント(Autonomous)既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。Connectを参考にする。トークンがJWTアサーション形式で暗号化・署名される。OwnerのCredentialsを入力してリソースにアクセスする。ServerにアクセスするClient。Serverのリソースにアクセスする。Serverを繋ぐ忙しいプログラムになった(だからクレームベース認証は難しい)。Server用の認証チケットの発行を行う。Tokenの発行を行う。Tokenを受けてリソースアクセスを提供する。Server(の認証画面)で認証する。Serverの認可エンドポイントで認可グラントを受け取る。Tokenを発行する。Resourceにアクセスする。以下、4つのグラント種別に対応するフローがある。Clientのサーバ側から使うフロー。認可エンドポイントの"画面"でリソース・アクセスを認可、Redirectエンドポイントで取得した仲介コードを取得する。Serverにアクセスする。ServerはClientを認証する。Agentに露見させずに処理可能。Tokenの露見防止には、Clientのエンドポイント・コンテンツの実装に依存する。通信RFCを読んだほうが良い。Clientのクライアント側から使うフロー(ただし、サーバ側のエンドポイントは必要)。Tokenを取得する。Tokenが露見する。Serverにアクセスする。ServerはClientを認証しない。認可エンドポイントとRedirectエンドポイント間のラウンドトリップが少なく、応答性に優れる。Agentに露見するセキュリティのトレードオフがある(10.3、10.16)。Tokenの拡散防止には、Clientのエンドポイント・コンテンツの実装に依存する。通信RFCを読んだほうが良い。以下のようにあるため、本グラント種別の利用は、特殊なケースに留める。他のフローが実行可能でない場合にのみ許可する必要があります。OwnerのCredentialsをClientに送る。OwnerのCredentialsを認可エンドポイントに送る。Serverにアクセスする。OwnerのCredentialsをClientに送ってしまう。Clientから使用する。OwnerとClientの間に高い信頼関係があること。Serverは、Clientを認証すること。以下のような、特殊なケースに留める。Codeグラント種別のフローを使用できないようなケース。ClientからClientのサーバ側エンドポイント以外に直接アクセスできないようなケース。通信RFCを読んだほうが良い。Clientは、ClientのCredentialsを認可エンドポイントに送る。Serverにアクセスする。Server間で調整済みの、Clientの保有するリソースにアクセスする場合に使用する。Clientから使用する。Serverは、Clientを認証すること。通信RFCを読んだほうが良い。†その他にも、以下のようなフローがある。†クライアント識別子を使用して、Clientを事前登録する。Codeや、Implicitグラント種別のRedirectエンドポイントclient_idに対応するRedirectエンドポイントのURL(絶対パスを)事前登録する。動的設定では部分一致をサポートするが、オープンリダイレクト脆弱性がある。保護されたリソースにアクセスするために使用されるCredential。ServerによってClientに対して発行されるランダムな文字列。アクセス範囲とアクセス期間を表す。Ownerによって許可される。Serverへの要求に対して、以下の様な形式で送信される。Token取得するために使用されるCredential。ServerによってClientに対して発行されるランダムな文字列。Tokenも含まれる。Serverに送信されることはない。利用する際、暗号鍵の所持を証明するよう要求されない。(MAC)キーを発行する。MACキーはHTTPリクエストの一部分を署名するのに利用される。ServerはこれによりClientを認証)クライアント識別子クライアント識別子(2つのセット)の情報は、URIで送信しない。client_id(1つだけの場合、URIに露見する)client_secret(URIに露見しない、させない)認証方法ベーシック認証などのパスワードベースのHTTP認証スキームHTTP認証スキームを使用できない場合にPOSTを使用する(非推奨)。†URLは仕様で規定されない。Ownerを認可するエンドポイント認証画面ではないので注意(認証結果を見て認可する)。Tokenを発行するエンドポイント。特徴HTTPSのGETを使用する。Codeや、Implicitグラント種別で使用する。Tokenを発行するエンドポイント。特徴HTTPSのPOSTを使用する。Implicitグラント種別を除く、他の全てのグラント種別で使用する。†Redirectエンドポイント概要エンドポイント・コンテンツを返す。特徴HTTPSのGETを使用する。Codeや、Implicitグラント種別で使用する。Codeでは、なるべくエンドポイント・コンテンツにトークンが露見しないようにする。Implicitグラントなど、トークンがコンテンツに露見してしまう場合、以下に従い拡散を防止する。partyのscriptを含めるべきでない。Client自身のscriptが初回に実行されるようにすること。URIからトークンを抽出し、露見しないように他へPOSTしBodyに含めるなどする。認可エンドポイントにGETで送付する。以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。Connectによって、追加された、response_type。†Clientの識別や認証のために、色々な所で使用されるパラメタ。認可エンドポイントclient_idとredirect_uriの対応をチェックする。Redirectエンドポイント次のTokenエンドポイントに渡す。TokenエンドポイントClientの認証を行なう。†client_idに対応するRedirectエンドポイントを指定するために指定するパラメタ。Implicitグラント種別で使用する。認可エンドポイントにGETを送付するときに、部分一致するオプション値として絶対パスで指定する。指定した際は、Tokenエンドポイントまで、引き継がれチェックに使用される。†TokenエンドポイントにPOSTを送付するときに指定するパラメタ。以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。認可エンドポイントにGETで送付する。Ownerに提示する。認可エンドポイントにGETで送付する。Tokenを取得した場合、Responseにscopeパラメタを付与する。Credentialsグラント種別TokenエンドポイントにPOSTで送付する。Tokenを取得した場合、Responseにscopeパラメタを付与する。Credentialsグラント種別TokenエンドポイントにPOSTで送付する。Tokenを取得した場合、Responseにscopeパラメタを付与する。†CSRFのセキュリティ対策に使用が推奨されるパラメタ。認可エンドポイントにGETを送付するときに指定する。Implicitグラント種別で使用する。以降のやり取りでも引き継がれて使用される(値は変更しないこと)。推測困難な文字列である必要がある。Codeグラント種別でのみ使用する。client_idだけ盗んで、特定のClientになり済ますことができる。これにより、攻撃用のClientを使用した攻撃が可能になる。†Redirectエンドポイントの変更により、攻撃者のClientに誘導できる。