[#zb38b595]|項番|名称|実体例|やること|h|1|ResourceOwner|ユーザ(人間)|認証情報を入力してリソースにアクセスする。etc.)|1、3、4を繋ぐ忙しいプログラム(だから[[クレームベース認証]]は難しい)||3|AuthorizationServer|Webアプリケーションの認証機能|認証チェットとアクセストークンの発行を行う。AuthorizationServerと別でも良い|アクセストークンを受けてリソースアクセスを提供する。[#c8a23ceb]以下4つのフローがある。[#yfeb403d]-概要--WebアプリケーションのWebブラウザから使うフロー。--[[ResourceOwnerの認証>#m0ca183e]]後に、[[Redirectエンドポイント>#ja887509]]経由で・・・。[#m5c2d510]-概要--JavaScriptなどから使うフロー。-特徴--・・・-通信~RFCを読んだほうが良い。モデル]]みたいなもん。モデル]]みたいなもん。[#s820b1ab]-認可エンドポイント--ResourceOwnerを認証するエンドポイント。Implicitグラント種別で使用する。-トークン・エンドポイント--アクセストークンを発行するエンドポイント。--Implicitグラント種別を除く、他の全てのグラント種別で使用する。---Implicitグラント種別では、Redirectエンドポイントでアクセストークンを返す。--URLは仕様で規定されない。HTTPSのPOSTを使用する。partyのscriptを含めるべきでない。--クライアント自身のscriptが初回に実行されるようにすること。--URIからクレデンシャルを抽出し、露見しないように他へPOSTするなどすること。[#eb4fd2ef]-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などのプロトコルを使って連携する場合のフロー。2.0仕様には4つのフローが定義されている。~これらのフローのタイプを「グラント種別」と呼ばれる。マッシュアップ:サーバサイドマッシュアップ~https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html以下の様な「グラント種別」がある模様。[#gc1850ca]既知の問題点を組み合わせた攻撃手法。以下の2つが組み合わさって成立する。OAuth.jp~http://oauth.jp/blog/2014/05/07/covert-redirect/--[[前述の対策を行う。パラメータをチェックする。徳丸浩の日記(2011-01-27)~http://www.tokumaru.org/d/20110127.htmlザックリ言って、-推奨される-CSRF対策の-推測困難な文字列--(ワンタイム性は必須ではない)と言うモノらしい。認証に使うと、車が通れる程どてかいセキュリティ・ホールが開く。Zone~https://www.sakimura.org/2012/02/1487/ザックリ言って、-攻撃者の構築したRP(A)は、access_tokenを収集する。置換え攻撃により、~RP(B)にログイン(若しくはRP(B)経由でリソース・アクセス)できる。demo~http://www.slideshare.net/ritou/idcon11-implicit-demo以下のように対策できる。Flowを利用できないか確認する。-認可サーバーがアクセストークンが発行された対象のクライアントを確認できるAPIを提供する。~これにより、アクセストークン置き換え攻撃を検知できる(RFCに定義はないので独自実装する)。Tokenを利用する。[#jf8e8e73]HTTPSはホスト名の部分だけ情報として渡し、~以後のパスやクエリストリング情報は暗号化される。従ってGETでも一応安全だが、-アクセスログに残る-ブラウザの履歴に残る-リファラーに残るという問題がある。従って、このグラント種別では、-基本的に、Browserから実行させてはいけない。-また、Webサーバで、W3Cログ等を出力させないようにする。IISならW3Cログの出力をカスタマイズできる。安全ではない」とは言えない。クライアントアプリケーションを作る方こそ安全ではない。