10:28:28)追加された行はこの色です。削除された行はこの色です。.NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。2.0について言及する。2.0は、認証ではなく認可のためのプロトコル(権限委譲プロトコル)。Owner>#qe857228]]と[[Client>#b4b4c0bd]]を分離することができる。OwnerのCredentials>#m0ca183e]]を[[Client>#b4b4c0bd]]に渡す必要が無くなる。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などのプロトコルを使って連携する場合のフロー。[#s805c8ce]-Tokenが[[JWT]]アサーション形式で暗号化・署名される。Flowが追加されている。Connect#l565139a]]-コレ以外にも、多数のオプションが追加されている。OwnerのCredentials>#m0ca183e]]を入力してリソースにアクセスする。ServerにアクセスするClient。Serverのリソースにアクセスする。Serverを繋ぐ~忙しいプログラムになった(だから[[OAuth]]はClient側でも難しい)。Server用の認証チケットの発行を行う。Token>#jb722a87]]の発行を行う。Token>#jb722a87]]を受けてリソースアクセスを提供する。Server(の認証画面)で認証する。Serverの[[認可エンドポイント>#s820b1ab]]で認可グラントを受け取る。Token>#jb722a87]]を発行する。Resourceにアクセスする。[#p9f64095][[ココのスライド>#s6e988c9]]が参考になる。[#c8a23ceb]以下、4つのグラント種別に対応するフローがある。[#yfeb403d]-概要--[[Confidentialクライアント>#q08180e3]]のサーバ側から使うフロー。Ownerの認証>#m0ca183e]]をした後、---[[認可エンドポイント>#s820b1ab]]の"画面"でリソース・アクセスを認可、---[[Redirectエンドポイント>#ja887509]]で取得した仲介コードを取得する。Serverにアクセスする。ServerはClientを認証する。Agentに露見させずに処理可能。Token>#jb722a87]]の露見防止には、Clientのエンドポイント・コンテンツの実装に依存する。-通信~[[RFC>#v698197b]]を読んだほうが良い。[#m5c2d510]-概要--[[Publicクライアント>#q08180e3]]のクライアント側から使うフロー(ただし、サーバ側のエンドポイントは必要)。Token>#jb722a87]]を取得する。Token>#jb722a87]]が露見する。Token>#jb722a87]]を[[Publicクライアント>#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に送ってしまう。--従って、[[Confidentialクライアント>#q08180e3]]から使用する。OwnerとClientの間に高い信頼関係があること。Serverは、Clientを認証すること。--以下のような、特殊なケースに留める。Codeグラント種別>#yfeb403d]]のフローを使用できないようなケース。~例えば、[[Publicクライアント>#q08180e3]]からClientのサーバ側エンドポイント以外に直接アクセスできないようなケース。-通信~[[RFC>#v698197b]]を読んだほうが良い。モデル]]みたいなもん。--Clientは、[[ClientのCredentials>#i7b73962]]を[[認可エンドポイント>#s820b1ab]]に送る。Serverにアクセスする。Server間で調整済みの、~Clientの保有するリソースにアクセスする場合に使用する。--従って、[[Confidentialクライアント>#q08180e3]]から使用する。Serverは、Clientを認証すること。-通信~[[RFC>#v698197b]]を読んだほうが良い。[#keaaae10]-[[クライアント識別子>#i7b73962]]を使用して、Clientを事前登録する。Code>#yfeb403d]]や、[[Implicitグラント種別>#m5c2d510]]の[[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に送信されることはない。