[#ff7046a2]認可のためのプロトコル。-AuthorizationServerの設置により、ResourceOwnerとClientを分離することができる。-これにより、[[ResourceOwnerのCredentials>#m0ca183e]]をClientに渡す必要が無くなる。-ResourceOwnerは、AuthorizationServerによって、ClientのResourceServerへのアクセスを認可できるようになる。[#zb38b595]|項番|名称|実体例|やること|h|1|ResourceOwner|ユーザ(人間)|[[ResourceOwnerのCredentials>#m0ca183e]]を入力してリソースにアクセスする。Token>#jb722a87]]の発行を行うWebアプリケーション。Token>#jb722a87]]を受けてリソースアクセスを提供するWebアプリケーション。[#b5726bb0]ResourceOwnerは、Clientを経由して、AuthorizationServer(の認証画面)で認証する。[#m6a4436a]認証後、Clientは、AuthorizationServerの[[認可エンドポイント>#s820b1ab]]で認可グラントを受け取る。Token>#jb722a87]]を発行する。Resourceにアクセスする。[#c8a23ceb]以下、4つのグラント種別に対応するフローがある。[#yfeb403d]-概要--Webブラウザを使用したWebアプリケーションのサーバ側から使うフロー。Token>#jb722a87]]を使用してResourceServerにアクセスする。-特徴--AuthorizationServerはClientを認証する。Clientに最適化される。Token>#jb722a87]]をUserAgentに露見させずに処理可能。Token>#jb722a87]]の露見防止には、Clientのエンドポイント・コンテンツの実装に依存する。-通信~[[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html]]を読んだほうが良い。[#m5c2d510]-概要--Webブラウザを使用したWebアプリケーションのUserAgent(JavaScript)から使うフロー。Token>#jb722a87]]を取得する。Token>#jb722a87]]が露見する。Token>#jb722a87]]をUserAgentに返す。Token>#jb722a87]]を使用してResourceServerにアクセスする。-特徴--AuthorizationServerはClientを認証しない。Clientに最適化される。---[[認可エンドポイント>#s820b1ab]]と[[Redirectエンドポイント>#ja887509]]間のラウンドトリップが少なく、応答性に優れる。Token>#jb722a87]]が、~UserAgentに露見するセキュリティのトレードオフがある([[10.3>http://openid-foundation-japan.github.io/rfc6749.ja.html#AccessTokenSecurity]]、[[10.16>http://openid-foundation-japan.github.io/rfc6749.ja.html#ImplicitImpersonation]])。Token>#jb722a87]]の拡散防止には、Clientのエンドポイント・コンテンツの実装に依存する。-通信~[[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html]]を読んだほうが良い。モデル]]みたいなもん。--[[ResourceOwnerのCredentials>#m0ca183e]]をClientに送る。--Clientは、[[ResourceOwnerのCredentials>#m0ca183e]]を[[認可エンドポイント>#s820b1ab]]に送る。Token>#jb722a87]]を取得してResourceServerにアクセスする。-特徴--[[ResourceOwnerのCredentials>#m0ca183e]]をClientに送ってしまう。Clientから使用する。---ResourceOwnerとClientの間に高い信頼関係があること。---AuthorizationServerは、Clientを認証すること。--以下のケースで使用する。Codeグラント種別>#yfeb403d]]のフローを使用できないようなケース。~例えばUserAgentからClient以外のエンドポイントに直接アクセスできないようなケース。移行段階などで使用する。-通信~[[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html]]を読んだほうが良い。モデル]]みたいなもん。--Clientは、[[ClientのCredentials>#i7b73962]]を[[認可エンドポイント>#s820b1ab]]に送る。Token>#jb722a87]]を取得してResourceServerにアクセスする。AuthorizationServer間で調整済みの、~Clientの保有するリソースにアクセスする場合に使用する。Clientから使用する。---AuthorizationServerは、Clientを認証すること。-通信~[[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html]]を読んだほうが良い。[#keaaae10]-[[クライアント識別子>#i7b73962]]を使用して、Clientを事前登録する。Codeや、Implicitグラント種別のRedirectエンドポイント--client_idに対応するRedirectエンドポイントのURL(絶対パスを)事前登録する。--動的設定では部分一致をサポートするが、オープンリダイレクト脆弱性がある。[#jb722a87][[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor8]]を読むと、-保護されたリソースにアクセスするために使用されるCredential。-AuthorizationServerによってClientに対して発行されるランダムな文字列。-アクセス範囲とアクセス期間を表す。-発行はResourceOwnerによって許可される。-AuthorizationServerが発行し、ResourcesServerが利用。Token>#jb722a87]]取得するために使用されるCredential。-AuthorizationServerによってClientに対して発行されるランダムな文字列。Token>#r3e36f53]]も含まれる。Token>#r3e36f53]]と異なり、ResourcesServerに送信されることはない。利用する際、暗号鍵の所持を証明するよう要求されない。[#i7b73962]Clientの認証用のCredentials(AuthorizationServerはこれらを使用してClientを認証)-ベーシック認証などのパスワードベースのHTTP認証スキーム-クライアント識別子--パスワードベースのHTTP認証スキームを使用できない場合に使用する(非推奨)。--クライアント識別子(2つのセット)の情報は、POSTのBodyで送信し、URIで送信しない。[#h4dcb0c7]URLは仕様で規定されない。[#s820b1ab]-認可エンドポイント--概要---ResourceOwnerを認可するエンドポイント---認証画面ではないので注意(認証結果を見て認可する)。Token>#jb722a87]]を発行するエンドポイント。--特徴---HTTPSのGETを使用する。Codeや、Implicitグラント種別で使用する。Token>#r3e36f53]]を発行するエンドポイント。--特徴---HTTPSのPOSTを使用する。---Implicitグラント種別を除く、他の全てのグラント種別で使用する。Token>#jb722a87]]を返す。[#ja887509]Redirectエンドポイント-概要~エンドポイント・コンテンツを返す。-特徴--HTTPSのGETを使用する。Codeや、Implicitグラント種別で使用する。Codeでは、なるべくエンドポイント・コンテンツにトークンが露見しないようにする。--Implicitグラントなど、トークンがコンテンツに露見してしまう場合、以下に従い拡散を防止する。partyのscriptを含めるべきでない。---Client自身のscriptが初回に実行されるようにすること。---URIからトークンを抽出し、露見しないように他へPOSTしBodyに含めるなどする。[#l1d2572d]認可エンドポイントにGETを送付するときに以下のように指定するパラメタ。Codeグラント種別で使用する(仲介コードを要求)。Token>#jb722a87]]を要求)。[#ha9ff05e]Clientの識別や認証のために、色々な所で使用されるパラメタ。-[[コチラ>#i7b73962]]を参照。[#t71d0e79]client_idに対応するRedirectエンドポイントを指定するために指定するパラメタ。-認可エンドポイントにGETを送付するときに指定する。Implicitグラント種別で使用する。-絶対パスで指定する(部分一致が可能だが)。-以降のやり取りでも引き継がれて使用される。Redirect)>#ycb0a43b]]のセキュリティ対策に使用が推奨されるパラメタ。-概要--認可エンドポイントにGETを送付するときに指定する。Implicitグラント種別で使用する。--以降のやり取りでも引き継がれて使用される(値は変更しないこと)。-要件--推測困難な文字列である必要がある。[#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などのプロトコルを使って連携する場合のフロー。Connect]]を参考にする。Token>#i5f79713]]ではなく、各種トークンやクレームが暗号化・署名される。--Token:エンコード&署名される。--Claim:暗号化される。