[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]] -[[戻る>クレームベース認証#k66961ce]] * 目次 [#qc1590f2] #contents *概要 [#ff7046a2] **登場人物 [#zb38b595] |項番|名称|実体例|やること|h |1|ResourceOwner|ユーザ(人間)|[[ResourceOwnerのCredentials>#m0ca183e]]を入力してリソースにアクセスする。| |2|Client|Program(Webブラウザ, Webアプリケーション, etc.)|1、3、4を繋ぐ忙しいプログラム(だから[[クレームベース認証]]は難しい)| |3|AuthorizationServer|認証・認可のサーバー機能|認証チケットと[[Access Token>#jb722a87]]の発行を行うWebアプリケーション。| |4|ResourceServer|リソースアクセスを提供するサーバー機能、 AuthorizationServerと別でも良い|[[Access Token>#jb722a87]]を受けてリソースアクセスを提供するWebアプリケーション。| **プロトコル・フロー [#g723492b] +--------+ +---------------+ | |--(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 ---| | +--------+ +---------------+ ***(A) Authorization Request [#b5726bb0] ResourceOwnerは、Clientを経由して、AuthorizationServer(の認証画面)で認証する。 ***(B) Authorization Grant [#m6a4436a] 認証後、Clientは、AuthorizationServerの[[認可エンドポイント>#s820b1ab]]で認可グラントを受け取る。 ***(C) Authorization Grant [#m041f58e] Clientは、AuthorizationServerの[[Tokenエンドポイント>#s820b1ab]]に認可グラントを提示することで、[[Access Token>#jb722a87]]を要求する. ***(D) Access Token [#pcf3e60f] AuthorizationServerは、Clientと 認可グラントが正当であれば、Clientに[[Access Token>#jb722a87]]を発行する。 ***(E) Access Token, (F) Protected Resource [#b1d7b608] Clientは、ResourceServerに[[Access Token>#jb722a87]]を提示してProtected Resourceにアクセスする。 **フロー [#c8a23ceb] 以下4つのフローがある。 ***Authorization Codeグラント種別 [#yfeb403d] -概要 --WebアプリケーションのWebブラウザから使うフロー。 ---認証画面で[[ResourceOwnerの認証>#m0ca183e]]をした後、 ---[[認可エンドポイント>#s820b1ab]]の"画面"でリソース・アクセスを認可、 ---[[Redirectエンドポイント>#ja887509]]で[[Access Token>#jb722a87]]と[[Refresh Token>#r3e36f53]]を取得し、 ---最後に・・・、 -特徴 --[[ResourceOwnerのCredentials>#m0ca183e]]はClientに共有されない。 --Confidential Clientに最適化される。 -通信~ 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]] ***Implicitグラント種別 [#m5c2d510] -概要 --JavaScriptなどから使うフロー。 ---認証画面で[[ResourceOwnerの認証>#m0ca183e]]をした後、 ---[[認可エンドポイント>#s820b1ab]]でリソース・アクセスを認可、 ---[[Redirectエンドポイント>#ja887509]]で[[Bearer Token>#i5f79713]]を取得し、 ---最後に[[Bearer Token>#i5f79713]]を使用してリソースサーバーへアクセスする。 -特徴 --AuthorizationServerはClientを認証しない。 --JavaScript、スマホネイティブなどのPublic Clientに最適化される。 --認可コードといった仲介のCredentialを使用しないため応答性に優れる。 --反面、[[Bearer Token>#i5f79713]]が露見するセキュリティのトレードオフがある([[10.3>http://openid-foundation-japan.github.io/rfc6749.ja.html#AccessTokenSecurity]]、[[10.16>http://openid-foundation-japan.github.io/rfc6749.ja.html#ImplicitImpersonation]])。 ***Resource Owner Password Credentialsグラント種別 [#zfff6f89] -概要 --[[ベース クライアント セキュリティ モデル]]みたいなもん。 --[[Resource OwnerのCredentials>#m0ca183e]]を送って[[Bearer Token>#i5f79713]]を取得。 -特徴 --ResourceOwnerとClientの間に高い信頼関係があること。 --[[Authorization Codeグラント種別>#yfeb403d]]のフローを使用できないようなケースで使用する。 ***Client Credentialsグラント種別 [#o9473080] -概要 --[[サーバ信頼セキュリティ モデル]]みたいなもん。 --[[ClientのCredentials>#i7b73962]]を送って[[Bearer Token>#i5f79713]]を取得。 -特徴 --Clientのリソースである場合に使用する。 --若しくは、Clientと AuthorizationServer間で調整済みのリソースである場合に使用する。 **Clientについて [#aab02700] ***種類 [#q08180e3] -[[Client Credentials>#i7b73962]]の機密性保持能力 --Confidential~ [[Client Credentials>#i7b73962]]の機密性を維持可能なClient ---アクセスの制限されたサーバー --Public~ [[Client Credentials>#i7b73962]]の機密性を維持不可能なClient ---WWWブラウザ ---ネイティブ・アプリケーション ---ResourceOwnerのデバイスにインストールされたアプリケーション -Client Profile --Webアプリケーション(Confidential) --WWWブラウザなどのUserAgentベースアプリケーション(Public) --ネイティブアプリケーション(Public) ***登録 [#keaaae10] client_idを使用して、Clientを登録する。 **トークン(認可用のCredentials) [#vc4e6813] ***Access Token [#jb722a87] [[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor8]]を読むと、 -保護されたリソースにアクセスするために使用されるCredential。 -AuthorizationServerによってClientに対して発行されるランダムな文字列。 -アクセス範囲とアクセス期間を表す。 -発行はResourceOwnerによって許可される。 -AuthorizationServerが発行し、ResourcesServerが利用。 ***Refresh Token [#r3e36f53] [[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor9]]を読むと、 -[[Access Token>#jb722a87]]の無効化・期限切れの際に新しい[[Access Token>#jb722a87]]取得するために使用されるCredential。 -AuthorizationServerによってClientに対して発行されるランダムな文字列。 -[[Refresh Token>#r3e36f53]]の発行はオプションであり、[[Access Token>#jb722a87]]に[[Refresh Token>#r3e36f53]]も含まれる。 -[[Refresh Token>#r3e36f53]]と異なり、ResourcesServerに送信されることはない。 ***Bearer Token [#i5f79713] **認証用のCredentials [#wdad8a4e] ***ResourceOwner [#m0ca183e] 仕様の外(ユーザID、パスワードなどを使用してResourceOwnerを認証) ***Client [#i7b73962] -ベーシック認証 -クライアント識別子 --client_id(露見する) --client_secret(露見しない、させない) **エンドポイント [#h4dcb0c7] ***AuthorizationServer上 [#s820b1ab] -認可エンドポイント --ResourceOwnerを認可するエンドポイント(認証画面ではないので注意)。 --Authorization Code, Implicitグラント種別で使用する。 -Tokenエンドポイント --[[Access Token>#jb722a87]]を発行するエンドポイント。 --Implicitグラント種別を除く、他の全てのグラント種別で使用する。 ---Implicitグラント種別では、Redirectエンドポイントで[[Access Token>#jb722a87]]を返す。 --URLは仕様で規定されない。HTTPSのPOSTを使用する。 ***Client上 [#ja887509] -Redirectエンドポイント --コンテンツには、3rd partyのscriptを含めるべきでない。 --Client自身のscriptが初回に実行されるようにすること。 --URIからCredentialを抽出し、露見しないように他へ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を必須にし、署名をなくし、トークン取得も簡略化 +[[Access Token>#jb722a87]]のみでリソース取得が可能に +Webアプリも含め、4つのClient Profileを仕様化 ++Webサーバ(Web Server)~ Webアプリケーション ++ユーザーエージェント(User-Agent) ~ JavaScript ++ネイティブアプリ(Native Application)~ モバイルやデスクトップアプリ(ガイドライン程度しか定義されていない) ++自立クライアント(Autonomous)~ 既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。 **[[Bearer Token>#i5f79713]] 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 *セキュリティ [#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を利用できないか確認する。 -AuthorizationServerが[[Access Token>#jb722a87]]が発行された対象のClientを確認できるAPIを提供する。~ これにより、[[Access Token>#jb722a87]]置き換え攻撃を検知できる(RFCに定義はないので独自実装する)。 -OpenID ConnectのID Tokenを利用する。 **参考 [#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 でClientを作る方こそ安全ではない。 --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 *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>#i5f79713]] 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 ---| | +--------+ +---------------+ *参考 [#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/