「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>クレームベース認証#k66961ce]] * 目次 [#qc1590f2] #contents *概要 [#ff7046a2] ここでは、基本的に、OAuth 2.0について言及する。 OAuth 2.0は、認証ではなく認可のためのプロトコル(権限委譲プロトコル)。 -Authorization Serverの設置により、Resource OwnerとClientを分離することができる。 -これにより、[[Resource OwnerのCredentials>#m0ca183e]]をClientに渡す必要が無くなる。 -Resource Ownerは、Authorization Serverによって、ClientのResource Serverへのアクセスを認可できるようになる。 *変遷 [#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ベースアプリケーション~ WWWブラウザ上のJavaScript ++ネイティブアプリ(Native Application)~ モバイルやデスクトップアプリ(ガイドライン程度しか定義されていない) ++自立クライアント(Autonomous)~ 既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。 -OAuth 2.0 の仕組みと認証方法 | murashun.jp~ https://murashun.jp/blog/20150920-01.html#chapter-3 -How is OAuth 2 different from OAuth 1? - Stack Overflow~ http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1 **OAuth 2.0とOpenID Connectの違い [#z37db375] -[[OpenID Connect]]を参考にする。~ トークンが[[JWT]]アサーション形式で暗号化・署名される。 -OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜 --OAuth 2.0 Authorization Code Flow~ ---http://www.slideshare.net/kura_lab/openid-connect-id/21 ---http://www.slideshare.net/kura_lab/openid-connect-id/27 --OpenID Connect Authorization Code Flow~ ---http://www.slideshare.net/kura_lab/openid-connect-id/28 ---http://www.slideshare.net/kura_lab/openid-connect-id/78 *詳細 [#r0608873] **登場人物 [#zb38b595] ***Resource Owner [#qe857228] -実体例:ユーザ(人間) -やること:~ [[Resource OwnerのCredentials>#m0ca183e]]を入力してリソースにアクセスする。 ***Client [#b4b4c0bd] -実体例: --Resource ServerにアクセスするClient。 --Program ---Webブラウザ ---スマホネイティブ ---Webアプリケーション ---, etc. -やること: --Authorization Serverの認可を受けてResources Serverのリソースにアクセスする。 --認可レイヤの設置により、認証・認可の役割が分割されたため、~ Resource Owner, Authorization Server, Resource Serverを繋ぐ~ 忙しいプログラムになった(だから[[クレームベース認証]]は難しい)。 ***Authorization Server [#a2ff14fb] -実体例:認証・認可のサーバー機能(Webアプリケーション) -やること: --Authorization Server用の認証チケットの発行を行う。 --Resource Server用の[[Access Token>#jb722a87]]の発行を行う。 ***Resource Server [#n1c92dc2] -実体例: --リソースアクセスを提供するサーバー機能(WebAPIなど) --Authorization Serverと別でも良い -やること:~ [[Access Token>#jb722a87]]を受けてリソースアクセスを提供する。 **プロトコル・フロー [#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] Resource Ownerは、Clientを経由して、Authorization Server(の認証画面)で認証する。 ***(B) Authorization Grant [#m6a4436a] 認証後、Clientは、Authorization Serverの[[認可エンドポイント>#s820b1ab]]で認可グラントを受け取る。 ***(C) Authorization Grant [#m041f58e] Clientは、Authorization Serverの[[Tokenエンドポイント>#s820b1ab]]に認可グラントを提示することで、[[Access Token>#jb722a87]]を要求する. ***(D) Access Token [#pcf3e60f] Authorization Serverは、Clientと 認可グラントが正当であれば、Clientに[[Access Token>#jb722a87]]を発行する。 ***(E) Access Token, (F) Protected Resource [#b1d7b608] Clientは、Resource Serverに[[Access Token>#jb722a87]]を提示してProtected Resourceにアクセスする。 **グラント種別毎のフロー [#c8a23ceb] 以下、4つのグラント種別に対応するフローがある。 ***Authorization Codeグラント種別 [#yfeb403d] -概要 --[[Confidential Client>#q08180e3]]のサーバ側から使うフロー。 ---認証画面で[[Resource Ownerの認証>#m0ca183e]]をした後、 ---[[認可エンドポイント>#s820b1ab]]の"画面"でリソース・アクセスを認可、 ---[[Redirectエンドポイント>#ja887509]]で取得した仲介コードを取得する。 ---[[Tokenエンドポイント>#s820b1ab]]で仲介コードを使用して[[Access Token>#jb722a87]]と[[Refresh Token>#r3e36f53]]を取得し、 ---最後に[[Access Token>#jb722a87]]を使用してResource Serverにアクセスする。 -特徴 --Authorization ServerはClientを認証する。 ---仲介コード(code)を使用することで、[[Access Token>#jb722a87]]をUser Agentに露見させずに処理可能。 ---[[Access Token>#jb722a87]]の露見防止には、Clientのエンドポイント・コンテンツの実装に依存する。 -通信~ [[RFC>#v698197b]]を読んだほうが良い。 --[[認可リクエスト>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] -概要 --[[Public Client>#q08180e3]]のクライアント側から使うフロー(ただし、サーバ側のエンドポイントは必要)。 ---認証画面で[[Resource Ownerの認証>#m0ca183e]]をした後、 ---[[認可エンドポイント>#s820b1ab]]でリソース・アクセスを認可、[[Access Token>#jb722a87]]を取得する。 ---(この間のRedirectで、[[Access Token>#jb722a87]]が露見する。) ---[[Redirectエンドポイント>#ja887509]]では、[[Access Token>#jb722a87]]を[[Public Client>#q08180e3]]に返す。 ---最後に[[Access Token>#jb722a87]]を使用してResource Serverにアクセスする。 -特徴 --Authorization ServerはClientを認証しない。 ---[[認可エンドポイント>#s820b1ab]]と[[Redirectエンドポイント>#ja887509]]間のラウンドトリップが少なく、応答性に優れる。 ---反面、仲介コード(code)を使用しないため、[[Access Token>#jb722a87]]が、~ User 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]])。 ---[[Access Token>#jb722a87]]の拡散防止には、Clientのエンドポイント・コンテンツの実装に依存する。 -通信~ [[RFC>#v698197b]]を読んだほうが良い。 --[[認可リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#implicit-authz-req]] ---[[アクセストークン・レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#implicit-authz-resp]] ***Resource Owner Password Credentialsグラント種別 [#zfff6f89] -概要 --[[ベース クライアント セキュリティ モデル]]みたいなもん。 --[[Resource OwnerのCredentials>#m0ca183e]]をClientに送る。 --Clientは、[[Resource OwnerのCredentials>#m0ca183e]]を[[認可エンドポイント>#s820b1ab]]に送る。 --Clientは[[Access Token>#jb722a87]]を取得してResource Serverにアクセスする。 -特徴 --[[Resource OwnerのCredentials>#m0ca183e]]をClientに送ってしまう。 --従って、Confidential Clientから使用する。 ---Resource OwnerとClientの間に高い信頼関係があること。 ---Authorization Serverは、Clientを認証すること。 --以下のようなケースで使用する。 ---OAuth2.0 への移行段階。 ---[[Authorization Codeグラント種別>#yfeb403d]]のフローを使用できないようなケース。~ 例えば、[[Public Client>#q08180e3]]からClientのサーバ側エンドポイント以外に直接アクセスできないようなケース。 -通信~ [[RFC>#v698197b]]を読んだほうが良い。 --[[認可リクエストとレスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor26]] --[[アクセストークン・リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#password-tok-req]] ---[[アクセストークン・レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor27]] ***Client Credentialsグラント種別 [#o9473080] -概要 --[[サーバ信頼セキュリティ モデル]]みたいなもん。 --Clientは、[[ClientのCredentials>#i7b73962]]を[[認可エンドポイント>#s820b1ab]]に送る。 --Clientは[[Access Token>#jb722a87]]を取得してResource Serverにアクセスする。 -特徴 --Clientと Authorization Server間で調整済みの、~ Clientの保有するリソースにアクセスする場合に使用する。 --従って、Confidential Clientから使用する。 ---Authorization Serverは、Clientを認証すること。 -通信~ [[RFC>#v698197b]]を読んだほうが良い。 --[[認可リクエストとレスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor28]] --[[アクセストークン・リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#client-req]] ---[[アクセストークン・レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor29]] **その他のフロー [#m22bdf12] その他にも、以下のようなフローがある。 ***[[OAuth PKCE>#h47e1abd]] [#l2df3618] ***[[JWT Bearer Token Flow>JWTとOAuth2.0#f5007063]] [#f8ae9c05] ***[[OAuth2.0 Proof of Possession>JWTとOAuth2.0#u8ebfddc]] [#q064bc2f] ***[[OAuth 2.0 Device Flow>#b53eb0b8]] [#wbd60449] **Clientについて [#aab02700] ***種類 [#q08180e3] -[[Client Credentials>#i7b73962]]の機密性保持能力による分類 --Confidential~ [[Client Credentials>#i7b73962]]の機密性を維持可能なClient ---アクセスの制限されたサーバー --Public~ [[Client Credentials>#i7b73962]]の機密性を維持不可能なClient ---WWWブラウザ ---ネイティブ・アプリケーション ---Resource Ownerのデバイスにインストールされたアプリケーション -Client Profile(クライアント属性)による分類 --Confidential ---Webアプリケーション --Public ---ネイティブ・アプリケーション ---User Agentベースアプリケーション(WWWブラウザ上のJavaScript) ***事前登録 [#keaaae10] -[[クライアント識別子>#i7b73962]]を使用して、Clientを事前登録する。 -Authorization Codeや、Implicitグラント種別の[[Redirectエンドポイント>#ja887509]] --client_idに対応する[[Redirectエンドポイント>#ja887509]]のURL(絶対パスを)事前登録する。 --動的設定では部分一致をサポートするが、オープンリダイレクト脆弱性がある。 **認可用のCredentials(Token) [#vc4e6813] ***Access Token [#jb722a87] [[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor8]]を読むと、 -保護されたリソースにアクセスするために使用されるCredential。 -Authorization ServerによってClientに対して発行されるランダムな文字列。 -アクセス範囲とアクセス期間を表す。 -発行はResource Ownerによって許可される。 -Authorization Serverの[[Tokenエンドポイント>#s820b1ab]]が発行し、 -Resource Serverへの要求に対して、以下の様な形式で送信される。 GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer XXXXXXXXXX ***Refresh Token [#r3e36f53] [[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor9]]を読むと、 -[[Access Token>#jb722a87]]の無効化・期限切れの際に新しい[[Access Token>#jb722a87]]取得するために使用されるCredential。 -Authorization ServerによってClientに対して発行されるランダムな文字列。 -[[Refresh Token>#r3e36f53]]の発行はオプションであり、[[Access Token>#jb722a87]]に[[Refresh Token>#r3e36f53]]も含まれる。 -[[Access Token>#jb722a87]]と異なり、Resource Serverに送信されることはない。 ***Accessトークンのタイプ [#i5f79713] -Bearer Token --署名無しトークン([[Access Token>#jb722a87]]は基本的にBearer Token) --トークンが誰に対して発行されたのかを確認せずに、~ 「トークンを持っていること」をベースに API 利用を許可する。 --∴ 利用する際、暗号鍵の所持を証明するよう要求されない。 --参考 ---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 - MAC Token --アクセストークンと共にMessage Authentication Code (MAC)キーを発行する。 --MACキーはHTTPリクエストの一部分を署名するのに利用される。 --参考 ---draft-ietf-oauth-v2-http-mac-01 - OAuth 2.0 Message Authentication Code (MAC) Tokens~ https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 **認証用のCredentials [#wdad8a4e] ***Resource Owner [#m0ca183e] Resource Ownerの認証用のCredentialsはOAuth 2.0 仕様の外~ (Authorization ServerはユーザID、パスワードなどを使用してResource Ownerを認証) ***Client [#i7b73962] Clientの認証用のCredentials~ (Authorization ServerはこれによりClientを認証) -クライアント識別子~ クライアント識別子(2つのセット)の情報は、URIで送信しない。 --client_id(1つだけの場合、URIに露見する) --client_secret(URIに露見しない、させない) -認証方法 --ベーシック認証などのパスワードベースのHTTP認証スキーム --HTTP認証スキームを使用できない場合にPOSTを使用する(非推奨)。 **エンドポイントの種類 [#h4dcb0c7] URLは仕様で規定されない。 ***Authorization Server上のエンドポイント [#s820b1ab] -認可エンドポイント --概要 ---Resource Ownerを認可するエンドポイント ---認証画面ではないので注意(認証結果を見て認可する)。 ---仲介コードや、[[Access Token>#jb722a87]]を発行するエンドポイント。 --特徴 ---HTTPSのGETを使用する。 ---Authorization Codeや、Implicitグラント種別で使用する。 -Tokenエンドポイント --概要~ [[Access Token>#jb722a87]]・[[Refresh Token>#r3e36f53]]を発行するエンドポイント。 --特徴 ---HTTPSのPOSTを使用する。 ---Implicitグラント種別を除く、他の全てのグラント種別で使用する。~ Implicitグラント種別では、[[認可エンドポイント>#s820b1ab]]で[[Access Token>#jb722a87]]を返す。 ***Client上のエンドポイント [#ja887509] Redirectエンドポイント -概要~ エンドポイント・コンテンツを返す。 -特徴 --HTTPSのGETを使用する。 --Authorization Codeや、Implicitグラント種別で使用する。 -注意点 --Authorization Codeでは、なるべくエンドポイント・コンテンツにトークンが露見しないようにする。 --Implicitグラントなど、トークンがコンテンツに露見してしまう場合、以下に従い拡散を防止する。 ---コンテンツには、3rd partyのscriptを含めるべきでない。 ---Client自身のscriptが初回に実行されるようにすること。 ---URIからトークンを抽出し、露見しないように他へPOSTしBodyに含めるなどする。 **パラメタの種類 [#xd504f07] ***response_typeパラメタ [#l1d2572d] [[認可エンドポイント>#s820b1ab]]にGETで送付する。~ 以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。 |項番|グラント種別|パラメタ値|意味|h |1|Authorization Code|code|仲介コードを要求| |2|Implicit|token|[[Access Token>#jb722a87]]を要求| -参考:[[OpenID Connect]]によって、[[追加された、response_type>#gd28c140]]。 ***client_id, client_secretパラメタ [#ha9ff05e] Clientの識別や認証のために、色々な所で使用されるパラメタ。 -[[コチラ>#i7b73962]]を参照。 -用途 --[[認可エンドポイント>#s820b1ab]] ---client_idとredirect_uriの対応をチェックする。 --[[Redirectエンドポイント>#ja887509]] ---次の[[Tokenエンドポイント>#s820b1ab]]に渡す。 --[[Tokenエンドポイント>#s820b1ab]] ---Clientの認証を行なう。 ***redirect_uriパラメタ [#t71d0e79] client_idに対応する[[Redirectエンドポイント>#ja887509]]を指定するために指定するパラメタ。 -[[Redirectエンドポイント>#ja887509]]を使用する、Authorization Code, Implicitグラント種別で使用する。 -[[認可エンドポイント>#s820b1ab]]にGETを送付するときに、部分一致するオプション値として絶対パスで指定する。 -指定した際は、[[Tokenエンドポイント>#s820b1ab]]まで、引き継がれチェックに使用される。 ***grant_typeパラメタ [#p23cde9e] [[Tokenエンドポイント>#s820b1ab]]にPOSTを送付するときに指定するパラメタ。~ 以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。 |項番|グラント種別|パラメタ値|h |1|Authorization Code|authorization_code| |2|Resource Owner Password Credentials|password| |3|Client Credentials|client_credentials| |4|上記1、2、3のグラント種別でRefreshトークンを使用する際|refresh_token| ***scopeパラメタ [#qd3e1385] -Authorization Codeグラント種別 --[[認可エンドポイント>#s820b1ab]]にGETで送付する。 --送信前に、画面で認可scopeをResource Ownerに提示する。 -Implicitグラント種別 --[[認可エンドポイント>#s820b1ab]]にGETで送付する。 --異なるscopeの[[Access Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。 -Resource Owner Password Credentialsグラント種別 --[[Tokenエンドポイント>#s820b1ab]]にPOSTで送付する。 --異なるscopeの[[Access Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。 -Client Credentialsグラント種別 --[[Tokenエンドポイント>#s820b1ab]]にPOSTで送付する。 --異なるscopeの[[Access Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。 ***stateパラメタ [#wbfa8d08] [[CSRF>#bd3a67e8]]のセキュリティ対策に使用が推奨されるパラメタ。 -概要 --[[認可エンドポイント>#s820b1ab]]にGETを送付するときに指定する。 --[[Redirectエンドポイント>#ja887509]]を使用する、Authorization Code, Implicitグラント種別で使用する。 --以降のやり取りでも引き継がれて使用される(値は変更しないこと)。 -要件 --推測困難な文字列である必要がある。(ワンタイム性は必須ではない) -参考 --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 ***Responseのパラメタ(code, access_token, refresh_token) [#idca7e43] |項番|パラメタ値|意味|h |1|code|access_tokenを取得するためのtokenで、Authorization Codeグラント種別でのみ使用する。| |2|access_token|[[コチラを参照>#jb722a87]]| |3|refresh_token|[[コチラを参照>#r3e36f53]]| *セキュリティ [#v33a7e19] セキュリティに関する考察 -今更聞けないOAuth2.0 - セキュリティ対策~ http://www.slideshare.net/ph1ph2sa25/oauth20-46144252/54 -OAuth 2.0の概要とセキュリティ~ http://www.slideshare.net/charlier-shoe/oauth-20-29540466 -第3回 Webセキュリティのおさらい~ その3 CSRF・オープンリダイレクト・クリックジャッキング:~ JavaScriptセキュリティの基礎知識|gihyo.jp … 技術評論社~ --http://gihyo.jp/dev/serial/01/javascript-security/0003?page=1 --http://gihyo.jp/dev/serial/01/javascript-security/0003?page=2 **全グラント種別共通 [#c3d7e21e] ***Clientなりすまし(偽装) [#m367d7c9] -Clientの登録・検証に不備があるAuthorization Serverを狙う。 -client_idだけ盗んで、特定のClientになり済ますことができる。 -これにより、攻撃用のClientを使用した攻撃が可能になる。 **Authorization Code, Implicitグラント種別共通 [#hffc5d58] ***Open Redirect [#ie053d22] Redirectエンドポイントの変更により、攻撃者のClientに誘導できる。 -原因~ Server 側の甘めの redirect_uri 検証処理に起因する。 -対策~ Server は、client_id + redirect_uri の事前登録必須 + 完全一致にする。 -参考 --OAuth 2.0 の脆弱性 (!?) "Covert Redirect" とは - OAuth.jp~ http://oauth.jp/blog/2014/05/07/covert-redirect/ **Authorization Codeグラント種別 [#f4d89342] ***CSRF [#bd3a67e8] -原因~ 潜在的な問題で、認可エンドポイントのResponseが盗まれた場合、~ 甲を乙のResourcesにアクセスさせ、[[Access Token>#jb722a87]]を取得できる。 -対策~ Client は、 --[[認可エンドポイント>#s820b1ab]]へ遷移する際にstateパラメタを付与する。 --Redirectエンドポイントで[[stateパラメタ>#wbfa8d08]]をチェックする。 **Implicitグラント種別 [#c9029c4e] ***Tokenの置き換え(不正利用) [#v113c9d3] 「OAuth 2.0 の implicit grant flow を認証に使うと、~ 車が通れる程どてかいセキュリティ・ホールが開く。」らしい。 この、セキュリティ・ホールとは、 -単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone~ https://www.sakimura.org/2012/02/1487/ ザックリ言って、 -攻撃者の構築したClient(A)は、[[Access Token>#jb722a87]]を収集する。 -攻撃者は、 [[Access Token>#jb722a87]]置き換え攻撃により、Client(B)経由でリソース・アクセスできる。 と言うモノらしい。 この内容の良くない所は、 -[[Access Token>#jb722a87]]置き換え攻撃の問題とその対応方法 -[[OAuth2.0を認証に使用する際の問題点とその対応方法>#add861ca]] が、ごちゃ混ぜになっていること。 **OAuth2.0を認証に使用する際の問題点とその対応方法 [#add861ca] ***OAuth 2.0は認証で使用できるが、以下の問題がある。 [#pd85d22e] 認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。~ OAuth 2.0の仕様を熟読してもOAuth2.0を認証に使用しても問題ないように見える。 以下のBlogを参照して、 -認可のためのプロトコルのOAuthが認証に使えることの説明 | ありえるえりあ~ http://dev.ariel-networks.com/wp/archives/258~ --「OAuthが権限委譲(認可伝達)プロトコルなのは事実です。~ ・・・権限委譲プロトコルのひとつの利用方法に過ぎないからです。」 --「権限委譲プロトコルOAuthで、事実上、認証伝達ができる。」 の部分を見ると、全権限の認可は≒認証で、~ OAuth 2.0による認証も、OAuth 2.0の一利用方法と捉えることができる。 従って、「OAuth 2.0は認証で使用できる。」と考える。~ ただし、「OAuth 2.0には以下の問題がある。」と考える。 -Openな仕掛けで、インターネット上の野良Client、Resource Ownerから攻撃され得る。 -また、Authorization Serverに脆弱性があった場合、攻撃対象になり得る。 -さらに、Clientの作り次第で、[[Access Token>#jb722a87]]が露見し得る。 このため、これらの問題がある状態で、OAuth 2.0を認証に使用すると、 >「Resource Serverで公開しているリソースへのアクセスを認可する。」 という限られた権限より、(システムにログインできるということは)大きい権限を委譲することになるので、~ この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。 ***OAuth 2.0を認証で使用する際の、対応方法 [#rc445a11] 従って、この問題は、 -r-weblife --OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について #idcon~ http://d.hatena.ne.jp/ritou/20120206/1328484575 --GoogleのOAuth 2.0実装におけるToken置換攻撃の防ぎ方~ http://d.hatena.ne.jp/ritou/20120702/1341235859 以下のように対策できる。 -Implicitを利用している場合、Authorization Codeを利用できないか確認する。~ Authorization Codeであれば、[[Access Token>#jb722a87]]の露見の可能性は低い(ただし、Clientの作り次第)。 -Authorization Serverは、(JWTなどを使用して、) --発行対象のClientを特定できるように[[Access Token>#jb722a87]]を発行する。 --また、[[Access Token>#jb722a87]]の内容を確認するAPI用意し、Clientで検証可能にする。 --上記の処理は、RFCに定義は無いので独自に実装する必要がある。 ---Clientの確認には、[[クライアント識別子>#i7b73962]]を利用する。 ---これにより、[[クライアント識別子>#i7b73962]]不一致で、トークン置き換え攻撃も防ぐことができる。 ***[[OAuthによる外部ログイン(認証)の研究]] [#c3029b90] その他、新しい仕様も策定されている。 -[[OpenID Connect]]のID Tokenを利用する。 -「Proof Key for Code Exchange by OAuth Public Clients」の「token code」を実装する。 -「OAuth 2.0 Multiple Response Type Encoding Practices」の「token code」を利用する。 -「OAuth2.0 Proof of Possession」というドラフトがリリースされている。 詳しくは、[[コチラ>OAuthによる外部ログイン(認証)の研究]]を参照。 **参考 [#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 ***応答タイプ (response_type)の追加 [#gd28c140] -「code, id_token, token の任意の組み合わせ」か、もしくは none、となった。~ (OpenID Connect により、この仕様がOAuthに追加された)。 -仕様 --Final: OAuth 2.0 Multiple Response Type Encoding Practices~ http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html -参考 --OpenID Connect 全フロー解説 - Qiita~ https://qiita.com/TakahikoKawasaki/items/4ee9b55db9f7ef352b47 ***応答モード (response_mode) [#j8d1a782] -Redirectエンドポイントへ渡る応答パラメタ群を入れる場所を~ 制御するためのパラメタとして、response_mode が追加された。~ (OpenID Connect により、この仕様がOAuthに追加された)。 --response_mode=query とするとクエリー部に応答パラメタ群が入る。 --response_mode=fragment とするとフラグメント部に応答パラメタ群が入る。 --response_mode=form_post とすると200 OK + HTTP POST を自動実行する HTMLに応答パラメタ群が入る。 -仕様 --Final: OAuth 2.0 Multiple Response Type Encoding Practices~ http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html --Final: OAuth 2.0 Form Post Response Mode~ http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html -参考 --OAuth & OpenID Connect 関連仕様まとめ - Qiita~ https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3 ***OAuth 2.0 の脅威モデルとセキュリティー考慮事項 (RFC 6819) [#t8e931a5] -OAuth 2.0 の実装にあたり、特にセキュリティーに関して考慮すべき事項の列挙 -RFC 6819 - OAuth 2.0 Threat Model and Security Considerations~ https://tools.ietf.org/html/rfc6819 ***トークン取り消し (RFC 7009) [#me8f72f8] -発行されたアクセストークンやリフレッシュトークンを取り消すための手段 -RFC 7009 - OAuth 2.0 Token Revocation~ https://tools.ietf.org/html/rfc7009 ***トークン情報取得 (RFC 7662) [#zd8a101d] -アクセストークンやリフレッシュトークンのメタデータを取得するための手段~ (Protected ResourceがClientから受け取ったTokenのメタデータをAuthZ Serverに要求する方法) -RFC 7662 - OAuth 2.0 Token Introspection~ https://tools.ietf.org/html/rfc7662 ***認可コード横取り攻撃への対抗策 (RFC 7636) [#h47e1abd] -認可コード横取り攻撃 (authorization code interception attack) への対策 -RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients~ https://tools.ietf.org/html/rfc7636 *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 ---| | +--------+ +---------------+ **その他 [#udc6c7e5] ***OAuth 2.0 Device Flow [#b53eb0b8] -draft-ietf-oauth-device-flow-07 - OAuth 2.0 Device Flow for Browserless and Input Constrained Devices~ https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07 +----------+ +----------------+ | |>---(A)-- Client Identifier --->| | | | | | | |<---(B)-- Verification Code, --<| | | | User Code, | | | | & Verification URI | | | Device | | | | Client | Client Identifier & | | | |>---(E)-- Verification Code --->| | | | polling... | | | |>---(E)-- Verification Code --->| | | | | Authorization | | |<---(F)-- Access Token --------<| Server | +----------+ (w/ Optional Refresh Token) | | v | | : | | (C) User Code & Verification URI | | : | | v | | +----------+ | | | End-user | | | | at |<---(D)-- User authenticates -->| | | Browser | | | +----------+ +----------------+ Figure 1: Device Flow. -(C) User Code & Verification URI には、 --QRコードやNFC --e-mailかSMS(Remote Phishingに注意) >が使用できる。 *参考 [#sd7d7875] -OAuth - Wikipedia~ https://ja.wikipedia.org/wiki/OAuth **OAuth 1.0 [#b6b38b34] -OAuth Core 1.0~ http://oauth.net/core/1.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] -[[The OAuth 2.0 Authorization Framework>#v698197b]] -今更聞けないOAuth2.0~ http://www.slideshare.net/ph1ph2sa25/oauth20-46144252 -OAuth 2.0 の仕組みと認証方法 | murashun.jp~ https://murashun.jp/blog/20150920-01.html -OAuth 2.0 の仕様を読むために - Qiita~ http://qiita.com/awakia/items/66975de18ba25f18a961 -デジタル・アイデンティティ技術最新動向 連載インデックス - @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 **[[Microsoft Azure Active Directory]] [#f331a146] ---- Tags: [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]