10:28:28)追加された行はこの色です。削除された行はこの色です。.NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。2.0について言及する。2.0は、認証ではなく認可のためのプロトコル(権限委譲プロトコル)。OwnerとClientを分離することができる。Owner>#qe857228]]と[[Client>#b4b4c0bd]]を分離することができる。OwnerのCredentials>#m0ca183e]]をClientに渡す必要が無くなる。OwnerのCredentials>#m0ca183e]]を[[Client>#b4b4c0bd]]に渡す必要が無くなる。Serverへのアクセスを認可できるようになる。Server>#n1c92dc2]]へのアクセスを認可できるようになる。[#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]]を参考にする。~トークンが[[JWT]]アサーション形式で暗号化・署名される。OwnerのCredentials>#m0ca183e]]を入力してリソースにアクセスする。ServerにアクセスするClient。Serverのリソースにアクセスする。Serverを繋ぐ~忙しいプログラムになった(だから[[クレームベース認証]]は難しい)。Server用の認証チケットの発行を行う。Token>#jb722a87]]の発行を行う。Token>#jb722a87]]を受けてリソースアクセスを提供する。Server(の認証画面)で認証する。Serverの[[認可エンドポイント>#s820b1ab]]で認可グラントを受け取る。Token>#jb722a87]]を発行する。Resourceにアクセスする。[#c8a23ceb]以下、4つのグラント種別に対応するフローがある。Client>#q08180e3]]のサーバ側から使うフロー。Ownerの認証>#m0ca183e]]をした後、---[[認可エンドポイント>#s820b1ab]]の"画面"でリソース・アクセスを認可、---[[Redirectエンドポイント>#ja887509]]で取得した仲介コードを取得する。Serverにアクセスする。ServerはClientを認証する。Agentに露見させずに処理可能。Token>#jb722a87]]の露見防止には、Clientのエンドポイント・コンテンツの実装に依存する。-通信~[[RFC>#v698197b]]を読んだほうが良い。Client>#q08180e3]]のクライアント側から使うフロー(ただし、サーバ側のエンドポイントは必要)。Token>#jb722a87]]を取得する。Token>#jb722a87]]が露見する。Client>#q08180e3]]に返す。Serverにアクセスする。ServerはClientを認証しない。---[[認可エンドポイント>#s820b1ab]]と[[Redirectエンドポイント>#ja887509]]間のラウンドトリップが少なく、応答性に優れる。Agentに露見するセキュリティのトレードオフがある([[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>#v698197b]]を読んだほうが良い。モデル]]みたいなもんだが、~以下のようにあるため、本グラント種別の利用は、特殊なケースに留める。>「この認可タイプを使用可能にするときには特に注意を払い、~他のフローが実行可能でない場合にのみ許可する必要があります。OwnerのCredentials>#m0ca183e]]をClientに送る。OwnerのCredentials>#m0ca183e]]を[[認可エンドポイント>#s820b1ab]]に送る。Serverにアクセスする。OwnerのCredentials>#m0ca183e]]をClientに送ってしまう。Clientから使用する。OwnerとClientの間に高い信頼関係があること。Serverは、Clientを認証すること。--以下のような、特殊なケースに留める。Codeグラント種別>#yfeb403d]]のフローを使用できないようなケース。Client>#q08180e3]]からClientのサーバ側エンドポイント以外に直接アクセスできないようなケース。-通信~[[RFC>#v698197b]]を読んだほうが良い。モデル]]みたいなもん。--Clientは、[[ClientのCredentials>#i7b73962]]を[[認可エンドポイント>#s820b1ab]]に送る。Serverにアクセスする。Server間で調整済みの、~Clientの保有するリソースにアクセスする場合に使用する。Clientから使用する。Serverは、Clientを認証すること。-通信~[[RFC>#v698197b]]を読んだほうが良い。[#keaaae10]-[[クライアント識別子>#i7b73962]]を使用して、Clientを事前登録する。Codeや、Implicitグラント種別の[[Redirectエンドポイント>#ja887509]]--client_idに対応する[[Redirectエンドポイント>#ja887509]]のURL(絶対パスを)事前登録する。--動的設定では部分一致をサポートするが、オープンリダイレクト脆弱性がある。[#jb722a87][[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor8]]を読むと、-保護されたリソースにアクセスするために使用されるCredential。ServerによってClientに対して発行されるランダムな文字列。-アクセス範囲とアクセス期間を表す。Ownerによって許可される。Serverへの要求に対して、以下の様な形式で送信される。Token>#jb722a87]]取得するために使用されるCredential。ServerによってClientに対して発行されるランダムな文字列。Token>#r3e36f53]]も含まれる。Serverに送信されることはない。利用する際、暗号鍵の所持を証明するよう要求されない。(MAC)キーを発行する。--MACキーはHTTPリクエストの一部分を署名するのに利用される。ServerはこれによりClientを認証)-クライアント識別子~クライアント識別子(2つのセット)の情報は、URIで送信しない。--client_id(1つだけの場合、URIに露見する)--client_secret(URIに露見しない、させない)-認証方法--ベーシック認証などのパスワードベースのHTTP認証スキーム--HTTP認証スキームを使用できない場合にPOSTを使用する(非推奨)。[#h4dcb0c7]URLは仕様で規定されない。Ownerを認可するエンドポイント---認証画面ではないので注意(認証結果を見て認可する)。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][[認可エンドポイント>#s820b1ab]]にGETで送付する。~以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。Connect]]によって、[[追加された、response_type>#gd28c140]]。[#ha9ff05e]Clientの識別や認証のために、色々な所で使用されるパラメタ。-[[コチラ>#i7b73962]]を参照。-用途--[[認可エンドポイント>#s820b1ab]]---client_idとredirect_uriの対応をチェックする。--[[Redirectエンドポイント>#ja887509]]---次の[[Tokenエンドポイント>#s820b1ab]]に渡す。--[[Tokenエンドポイント>#s820b1ab]]---Clientの認証を行なう。[#t71d0e79]client_idに対応する[[Redirectエンドポイント>#ja887509]]を指定するために指定するパラメタ。Implicitグラント種別で使用する。-[[認可エンドポイント>#s820b1ab]]にGETを送付するときに、部分一致するオプション値として絶対パスで指定する。-指定した際は、[[Tokenエンドポイント>#s820b1ab]]まで、引き継がれチェックに使用される。[#p23cde9e][[Tokenエンドポイント>#s820b1ab]]にPOSTを送付するときに指定するパラメタ。~以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。Codeグラント種別--[[認可エンドポイント>#s820b1ab]]にGETで送付する。Ownerに提示する。-Implicitグラント種別--[[認可エンドポイント>#s820b1ab]]にGETで送付する。Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。Credentialsグラント種別--[[Tokenエンドポイント>#s820b1ab]]にPOSTで送付する。Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。Credentialsグラント種別--[[Tokenエンドポイント>#s820b1ab]]にPOSTで送付する。Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。[#wbfa8d08][[CSRF>#bd3a67e8]]のセキュリティ対策に使用が推奨されるパラメタ。-概要--[[認可エンドポイント>#s820b1ab]]にGETを送付するときに指定する。Implicitグラント種別で使用する。--以降のやり取りでも引き継がれて使用される(値は変更しないこと)。-要件--推測困難な文字列である必要がある。Codeグラント種別でのみ使用する。[#m22bdf12]その他にも、以下のようなフローがある。-client_idだけ盗んで、特定のClientになり済ますことができる。-これにより、攻撃用のClientを使用した攻撃が可能になる。[#ie053d22]Redirectエンドポイントの変更により、攻撃者のClientに誘導できる。