[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]
-[[戻る>クレームベース認証#k66961ce]]
* 目次 [#qc1590f2]
#contents
*概要 [#ff7046a2]
**登場人物 [#zb38b595]
|項番|名称|実体例|やること|h
|１|ResourceOwner|ユーザ（人間）|認証情報を入力してリソースにアクセスする。|
|２|Client|Program(Webブラウザ, Webアプリケーション, etc.)|１、３、４を繋ぐ忙しいプログラム（だから[[クレームベース認証]]は難しい）|
|３|AuthorizationServer|Webアプリケーションの認証機能|認証チェットとアクセストークンの発行を行う。|
|４|ResourceServer|Webアプリケーション, AuthorizationServerと別でも良い|アクセストークンを受けてリソースアクセスを提供する。|
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
**フロー [#c8a23ceb]
以下４つのフローがある。
***Authorization Codeグラント種別 [#yfeb403d]
-概要
--WebアプリケーションのWebブラウザから使うフロー。
--[[ResourceOwnerの認証>#m0ca183e]]後に、[[Redirectエンドポイント>#ja887509]]経由で・・・。
-特徴
--アクセス・トークンとリフレッシュ・トークンを取得
--コンフィデンシャル・クライアントに最適化
***Implicitグラント種別 [#m5c2d510]
-概要
--JavaScriptなどから使うフロー。
--[[ResourceOwnerの認証>#m0ca183e]]後に、[[Redirectエンドポイント>#ja887509]]経由でBearer Tokenを取得。
-特徴
--・・・
-通信~
RFCを読んだほうが良い。
--[[認可リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#code-authz-req]]
---[[認可レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#code-authz-resp]]
--[[アクセストークン・リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#token-req]]
---[[アクセストークン・レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor25]]
***Resource Owner Password Credentialsグラント種別 [#zfff6f89]
-概要
--[[ベース クライアント セキュリティ モデル]]みたいなもん。
--[[Resource OwnerのCredentials>#m0ca183e]]を送ってBearer Tokenを取得。
-特徴
--・・・
***Client Credentialsグラント種別 [#o9473080]
-概要
--[[サーバ信頼セキュリティ モデル]]みたいなもん。
--[[ClientのCredentials>#i7b73962]]を送ってBearer Tokenを取得。
-特徴
--・・・
**認証 [#wdad8a4e]
***ResourceOwner [#m0ca183e]
仕様の外（ユーザID、パスワードなどを使用してResourceOwnerを認証）
***Client [#i7b73962]
-ベーシック認証
-クライアント識別子（client_idとclient_secret）
**エンドポイント [#h4dcb0c7]
***AuthorizationServer上 [#s820b1ab]
-認可エンドポイント
--ResourceOwnerを認証するエンドポイント。
--Authorization Code, Implicitグラント種別で使用する。
-トークン・エンドポイント
--アクセストークンを発行するエンドポイント。
--Implicitグラント種別を除く、他の全てのグラント種別で使用する。
---Implicitグラント種別では、Redirectエンドポイントでアクセストークンを返す。
--URLは仕様で規定されない。HTTPSのPOSTを使用する。
***クライアント上 [#ja887509]
-Redirectエンドポイント
--コンテンツには、3rd partyのscriptを含めるべきでない。
--クライアント自身のscriptが初回に実行されるようにすること。
--URIからクレデンシャルを抽出し、露見しないように他へPOSTするなどすること。
*変遷 [#k3aeda5b]
**OAuth 1.0 [#eb4fd2ef]
-OpenIDを使ってTwitterやMa.gnoliaのAPIの認証委譲する方法を議論を開始。
-2007/4にOAuthのコミュニティが誕生。
-2007/7にOAuthの仕様の草案が完成。
-2007/10/3に、より正式な仕様であるOAuth Core 1.0 の最終草案がリリース。
-2008/11、第73回のIETF会合でOAuthの非公式会合も開かれ、~
さらなる標準化に向けてIETFにOAuthプロトコルを提案するかどうかを議論。
-2009/4/23、OAuth 1.0のセキュリティ問題が判明。この問題は、OAuth 1.0aで修正された。
**OAuth 2.0 [#h8e684ba]
-OAuth 1.0とは後方互換性を持たない。
-次世代のOAuthプロトコルとして、2012年にRFCとして発行された。
**OAuth 1.0とOAuth 2.0の違い [#s44d10cb]
-OAuth 2.0でWebサービスの利用方法はどう変わるか（2-3）- ＠IT~
http://www.atmarkit.co.jp/fsmart/articles/oauth2/02.html
+HTTPSを必須にし、署名をなくし、トークン取得も簡略化
+アクセストークンのみでリソース取得が可能に
+Webアプリも含め、4つのクライアントプロファイルを仕様化
++Webサーバ（Web Server）~
Webアプリケーション
++ユーザーエージェント（User-Agent） ~
JavaScript
++ネイティブアプリ（Native Application）~
モバイルやデスクトップアプリ（ガイドライン程度しか定義されていない）
++自立クライアント（Autonomous）~
既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。
**Bearer Token Usage [#c954189a]
-OAuth 2.0のbearer tokenの最新仕様を調べたらあまり変わってなかった - r-weblife~
http://d.hatena.ne.jp/ritou/20110402/1301679908
--The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語）~
http://openid-foundation-japan.github.io/rfc6750.ja.html
*The OAuth 2.0 Authorization Framework [#v698197b]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
https://tools.ietf.org/html/rfc6749
-OAuth 2.0 Core & Bearer Spec (RFC 6749 & RFC 6750) 翻訳公開！ - OAuth.jp~
http://oauth.jp/blog/2013/01/23/oauth-20-core-bearer-spec-rfc-rfc-6749-rfc-67/
--The OAuth 2.0 Authorization Framework~
http://openid-foundation-japan.github.io/rfc6749.ja.html
--The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語）~
http://openid-foundation-japan.github.io/rfc6750.ja.html
**(RFC 6749) OAuth 2.0のフロー定義 [#kd90c6bf]
OAuth 2.0仕様には4つのフローが定義されている。~
これらのフローのタイプを「グラント種別」と呼ばれる。
-IPA ISEC セキュア・プログラミング講座：~
Webアプリケーション編 第8章 マッシュアップ：サーバサイドマッシュアップ~
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html
以下の様な「グラント種別」がある模様。
***Authorization Codeグラント種別 [#y8bf613e]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
4.1. Authorization Code Grant~
https://tools.ietf.org/html/rfc6749#section-4.1
--Authorization Code Flow
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent.
***Implicitグラント種別 [#h347a7c6]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
4.2. Implicit Grant~
https://tools.ietf.org/html/rfc6749#section-4.2
--Implicit Grant Flow
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
Note: The lines illustrating steps (A) and (B) are broken into two parts as they pass through the user-agent.
***Resource Owner Password Credentialsグラント種別 [#i2483bc0]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
4.3. Resource Owner Password Credentials Grant~
https://tools.ietf.org/html/rfc6749#section-4.3
--Resource Owner Password Credentials Flow
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
-参考
--memo: Force.com : REST API 開発 ユーザ名パスワード OAuth 認証~
http://vaindespair.blogspot.jp/2013/01/blog-post_5252.html
---Understanding the Username-Password OAuth Authentication Flow~
Force.com REST API Developer Guide | Salesforce Developers~
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_username_password_oauth_flow.htm
***Client Credentialsグラント種別 [#ka6e3a8f]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
4.3. Resource Owner Password Credentials Grant~
https://tools.ietf.org/html/rfc6749#section-4.4
--Client Credentials Grant
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
**RFC 6750 - Bearer Token Usage [#d65223fc]
-RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage~
https://tools.ietf.org/html/rfc6750
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
*セキュリティ [#v33a7e19]
セキュリティに関する考察
-OAuth 2.0の概要とセキュリティ~
http://www.slideshare.net/charlier-shoe/oauth-20-29540466
**Authorization Codeグラント種別 [#f4d89342]
***Open Redirector [#ycb0a43b]
-第3回 Webセキュリティのおさらい~
その3 CSRF・オープンリダイレクト・クリックジャッキング：~
JavaScriptセキュリティの基礎知識｜gihyo.jp … 技術評論社~
http://gihyo.jp/dev/serial/01/javascript-security/0003?page=2
-対策
--Server は、redirect_uri は事前登録必須 + 完全一致にする。
***Covert Redirect [#gc1850ca]
既知の問題点を組み合わせた攻撃手法。
以下の2つが組み合わさって成立する。
-Server 側の甘めの redirect_uri 検証
-Client 側が内包する open redirector
-OAuth 2.0 の脆弱性 (!?) "Covert Redirect" とは - OAuth.jp~
http://oauth.jp/blog/2014/05/07/covert-redirect/
--[[前述の対策を行う。>#ycb0a43b]]
--Client は、state パラメータをチェックする。
state パラメタとは、
-OAuth 2.0のstateとredirect_uriとOpenID ConnectのnonceとID Tokenについて - r-weblife~
http://d.hatena.ne.jp/ritou/20121008/1349695124
--CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例 - 徳丸浩の日記(2011-01-27)~
http://www.tokumaru.org/d/20110127.html
ザックリ言って、
-推奨される
-CSRF対策の
-推測困難な文字列
--（ワンタイム性は必須ではない）
と言うモノらしい。
**Implicitグラント種別 [#c9029c4e]
「OAuth 2.0 の implicit grant flow を認証に使うと、車が通れる程どてかいセキュリティ・ホールが開く。」らしい。
この、セキュリティ・ホールとは、
-単なる OAuth 2.0 を認証に使うと、~
車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone~
https://www.sakimura.org/2012/02/1487/
ザックリ言って、
-攻撃者の構築したRP(A)は、access_tokenを収集する。
-攻撃者は、 access_token 置換え攻撃により、~
RP(B)にログイン（若しくはRP(B)経由でリソース・アクセス）できる。
と言うモノらしい。
この問題に対しては、
-OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について #idcon - r-weblife~
http://d.hatena.ne.jp/ritou/20120206/1328484575
--Idcon11 implicit demo~
http://www.slideshare.net/ritou/idcon11-implicit-demo
以下のように対策できる。
-Implicit Flowを利用している場合、Authorization Code Flowを利用できないか確認する。
-認可サーバーがアクセストークンが発行された対象のクライアントを確認できるAPIを提供する。~
これにより、アクセストークン置き換え攻撃を検知できる（RFCに定義はないので独自実装する）。
-OpenID ConnectのID Tokenを利用する。
**Resource Owner Password Credentialsグラント種別 [#jf8e8e73]
HTTPSはホスト名の部分だけ情報として渡し、~
以後のパスやクエリストリング情報は暗号化される。
従ってGETでも一応安全だが、
-アクセスログに残る
-ブラウザの履歴に残る
-リファラーに残る
という問題がある。
従って、このグラント種別では、
-基本的に、Browserから実行させてはいけない。
-また、Webサーバで、W3Cログ等を出力させないようにする。
などが必要になると考える。
IISならW3Cログの出力をカスタマイズできる。
-参考
--HTTPSとQueryString
---security - Secure Oauth 2.0 Resource Owner Password Credentials Grant Type - Stack Overflow~
http://stackoverflow.com/questions/39129331/secure-oauth-2-0-resource-owner-password-credentials-grant-type
---httpsでqueryStringは安全か | Rutakeの技術メモ~
http://cloudfront.rutake.com/techmemo/2011/01/26/https%E3%81%A7querystring%E3%81%AF%E5%AE%89%E5%85%A8%E3%81%8B/
--QueryStringのログ出力
---logging - Does IIS7 log request query string by default? - Stack Overflow~
http://stackoverflow.com/questions/19918561/does-iis7-log-request-query-string-by-default
---Does IIS log query strings in a https request? : The Official Microsoft IIS Forums~
https://forums.iis.net/t/1178176.aspx
**参考 [#bc772000]
***OAuth 2.0 and the Road to Hell [#y1f5c2c5]
-OAuth 1.0 のほうが OAuth 2.0 より安全なの？ - Qiita~
http://qiita.com/TakahikoKawasaki/items/3600b28af7b63671b968
--「OAuth 2.0 は OAuth 1.0 よりも安全ではない」とは言えない。
--OAuth 1.0 でクライアントアプリケーションを作る方こそ安全ではない。
--OAuth 1.0 ではなく OAuth 2.0 を採用するのが良い。
***Inspecting access tokens [#sace68e4]
-OAuth2.0の備忘録的まとめ - Ari-Press~
http://www.ari-hiro.com/blog/2012/12/30/oauth2-summary
--Manually Build a Login Flow - Facebook Login~
https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.4
*参考 [#sd7d7875]
**OAuth 1.0 [#b6b38b34]
-OAuth Core 1.0~
http://oauth.net/core/1.0/
-OAuth - Wikipedia~
https://ja.wikipedia.org/wiki/OAuth#OAuth_2.0
-ゼロから学ぶOAuth：特集｜gihyo.jp … 技術評論社~
http://gihyo.jp/dev/feature/01/oauth
--第1回 OAuthとは？―OAuthの概念とOAuthでできること~
http://gihyo.jp/dev/feature/01/oauth/0001
--第2回 OAuth Consumerの実装（入門 : OAuth Access Tokenの取得と利用）~
http://gihyo.jp/dev/feature/01/oauth/0002
--第3回 OAuth Consumerの実装（応用 : smart.fm APIおよびGoogle Data APIsの利用）~
http://gihyo.jp/dev/feature/01/oauth/0003
--第4回 OAuth Service Providerの実装~
http://gihyo.jp/dev/feature/01/oauth/0004
**OAuth 2.0 [#q09835d5]
-デジタル・アイデンティティ技術最新動向 連載インデックス - ＠IT~
http://www.atmarkit.co.jp/fsecurity/index/index_digid.html
--デジタル・アイデンティティ技術最新動向（1）：「OAuth」の基本動作を知る - ＠IT
---http://www.atmarkit.co.jp/ait/articles/1208/27/news129.html
---http://www.atmarkit.co.jp/ait/articles/1208/27/news129_2.html
-OAuth 2.0でWebサービスの利用方法はどう変わるか - ＠IT
--http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html
--http://www.atmarkit.co.jp/fsmart/articles/oauth2/02.html
--http://www.atmarkit.co.jp/fsmart/articles/oauth2/03.html
-色々な OAuth のフローと doorkeeper gem での実装 - Qiita~
http://qiita.com/tyamagu2/items/5aafff7f6ae0a9ec94aa
-OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜~
OAuth 2.0 Authorization Code Flow~
http://www.slideshare.net/kura_lab/openid-connect-id/21
-OAuth 2.0 の Response Type 全パターン - OAuth.jp~
http://oauth.jp/blog/2015/01/06/oauth2-multiple-response-type/
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
