- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 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>#a2ff14fb]]の設置により、[[Resource Owner>#qe857228]]と[[Client>#b4b4c0bd]]を分離することができる。
-これにより、[[Resource OwnerのCredentials>#m0ca183e]]を[[Client>#b4b4c0bd]]に渡す必要が無くなる。
-[[Resource Owner>#qe857228]]は、[[Authorization Server>#a2ff14fb]]によって、[[Client>#b4b4c0bd]]の[[Resource Server>#n1c92dc2]]へのアクセスを認可できるようになる。
*変遷 [#k3aeda5b]
**OAuth 1.0 [#eb4fd2ef]
-OpenIDを使ってTwitterやMa.gnoliaのAPIの認証委譲する方法を議論を開始。
-2007/4~
OAuthのコミュニティが誕生。
-2007/7~
OAuthの仕様の草案が完成。
-2007/10~
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]
***概要 [#hcedd1fd]
+HTTPSを必須にし、署名をなくし、トークン取得も簡略化
+[[Access Token>#jb722a87]]のみでリソース取得が可能に
+Webアプリも含め、4つのClient Profileを仕様化
++Webサーバ（Web Server）~
Webアプリケーション
++User Agentベースアプリケーション~
WWWブラウザ上のJavaScript
++ネイティブアプリ（Native Application）~
モバイルやデスクトップアプリ（ガイドライン程度しか定義されていない）
++自立クライアント（Autonomous）~
既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。
***参考 [#e6a50b1d]
-OAuth 2.0でWebサービスの利用方法はどう変わるか（2-3）- ＠IT~
http://www.atmarkit.co.jp/fsmart/articles/oauth2/02.html
-OAuth 2.0 の仕組みと認証方法 | murashun.jp~
https://murashun.jp/blog/20150920-01.html#chapter-3
-初心者のためのOAuth — OAuthの基本のキ | Rriver~
https://parashuto.com/rriver/development/learning-oauth-basics
-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]
***概要 [#s805c8ce]
-トークンが[[JWT]]アサーション形式で暗号化・署名される。
-新しく、Hybrid Flowが追加されている。
--Authorization Codeグラント種別 ---> Authorization Code Flow
--Implicitグラント種別 ---> Implicit Flow
--上記の組合せたようなグラント種別 ---> Hybrid Flow
-コレ以外にも、多数のオプションが追加されている。
***参考 [#s6e988c9]
-[[OpenID Connect]]
-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]]
**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 - OAuth 2.0 Message Authentication Code (MAC) Tokens~
https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac
**認証用の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に含めるなどする。
**Requestパラメタ [#xd504f07]
***response_typeパラメタ [#l1d2572d]
[[認可エンドポイント>#s820b1ab]]にGETで送付する。~
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。
|項番|グラント種別|パラメタ値|意味|h
|１|Authorization Code|code|仲介コードを要求|
|２|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
|１|Authorization Code|authorization_code|
|２|Resource Owner Password Credentials|password|
|３|Client Credentials|client_credentials|
|４|上記１、２、３のグラント種別で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パラメタ [#idca7e43]
code, access_token, refresh_token
|項番|パラメタ値|意味|h
|１|code|access_tokenを取得するためのtokenで、Authorization Codeグラント種別でのみ使用する。|
|２|access_token|[[コチラを参照>#jb722a87]]|
|３|refresh_token|[[コチラを参照>#r3e36f53]]|
*その他のフロー [#m22bdf12]
その他にも、以下のようなフローがある。
**JWTを使用したフロー [#b8923748]
***[[JWT bearer token authorizationグラント種別>JWTとOAuth2.0#f5007063]] [#f8ae9c05]
***[[JWT Secured Authorization Request (JAR)>JWTとOAuth2.0#bdaa0ed5]] [#f8d5cc83]
***[[OAuth2.0 Proof of Possession>JWTとOAuth2.0#u8ebfddc]] [#q064bc2f]
**スマホ向けフロー [#e9975c50]
**[[スマホ向けフロー>UserAgentでOAuth2のTokenを取得するベスト・プラクティス#m0aacf50]] [#e9975c50]
***[[OAuth 2.0 for Native Apps>#q93a1734]] [#l2df3618]
***[[OAuth PKCE>#h47e1abd]] [#l2df3618]
***[[スマホ向けベストプラクティス (RFC 8252 ... OAuth 2.0 for Native Apps)>OAuth 2.0 for Native Apps]] [#q93a1734]
***[[認可コード横取り攻撃への対抗策 (RFC 7636 ... OAuth PKCE)>OAuth PKCE]] [#h47e1abd]
**その他のデバイス向けフロー [#re33c628]
***[[OAuth 2.0 Device Flow>#b53eb0b8]] [#wbd60449]
*新しい仕様 [#c3029b90]
その他、新しい仕様も策定されている。
**OAuth 2.0 拡張で追加された仕様 [#f7c32a8e]
***[[トークン取り消し (RFC 7009 ... OAuth Token Revocation)>OAuth 2.0 Token Revocation]] [#me8f72f8]
***[[トークン情報取得 (RFC 7662 ... OAuth Token Introspection)>OAuth 2.0 Token Introspection]] [#zd8a101d]
**[[OpenID Connect]]で追加された仕様 [#m0985cde]
***[[応答タイプ (response_type)の追加>OAuth 2.0 Multiple Response Type Encoding Practices]] [#gd28c140]
***[[応答モード (response_mode)の新設>OAuth 2.0 Form Post Response Mode]] [#j8d1a782]
***[[claimsリクエスト・パラメタ>OpenID Connect#e26320e4]] [#m41fbfa5]
***[[認証コンテキストクラス>OpenID Connect#ja81c8fa]] [#t1a6b311]
***[[リクエスト・オブジェクト>OpenID Connect#m6d72953]] [#uab73e23]
**[[Financial API (FAPI)]]で追加された仕様 [#s0c8773b]
*セキュリティ [#v33a7e19]
セキュリティに関する考察と、考慮点。
**認証に使用する [#add861ca]
***問題点 [#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で公開しているリソースへのアクセスを認可する。」
という限られた権限より、（システムにログインできるということは）大きい権限を委譲することになるので、~
この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。
***対応方法 [#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に変更する。
--Implicitを利用している場合、Authorization Codeを利用できないか確認する。
--Authorization Codeであれば、[[Access Token>#jb722a87]]の露見の可能性は低い（ただし、Clientの作り次第）。
-OAuth2を拡張して、
--[[Bearer TokenをJWTアサーションに変更する。>JWTとOAuth2.0#y9c24d21]]
--以下の、[[新しい仕様>#c3029b90]]をサポートする。
--[[OAuth 2.0 拡張で追加された仕様>#f7c32a8e]]をサポートする。
--[[OpenID Connect]]をサポートする。
**スマホアプリで使用する [#l7a0d034]
-OAuth for Native Apps | GREE Engineers' Blog~
http://labs.gree.jp/blog/2015/12/14831/
-知っておきたい7つのID連携実装パターン - Yahoo! JAPAN Tech Blog~
https://techblog.yahoo.co.jp/web/auth/id_federation_impl_patterns/
>
+スタンダードなブラウザーパターン
+推奨したいネイティブアプリとブラウザーパターン
+画面遷移がシンプルなネイティブアプリとWebViewパターン
+フィッシング防止なWebViewアプリとブラウザーパターン
+WebViewアプリ完結パターン
+実装が大変だけどより汎用的なハイブリッドアプリとブラウザーパターン
+汎用的なハイブリッドアプリとWebViewパターン
-OAuth2/OIDCの認証にWebViewはダメっぽい。
--OAuthなプラットフォームの中の人が椅子を投げたくなるアプリの実装 - r-weblife~
http://d.hatena.ne.jp/ritou/20120619/1340101421
--Google、WebViewからのOAuth認証リクエストをブロックへ | スラド セキュリティ~
https://security.srad.jp/story/16/08/30/0636245/
---WebViewでGoogleアカウントのOAuth認証が使えなくなる問題~
https://techracho.bpsinc.jp/hachi8833/2016_09_01/25471
---AndroidからGoogle Service OAuth2.0の利用で詰んでいる~
http://awwa500.blogspot.jp/2012/12/androidgoogle-service-oauth20.html
--代替の提案としては、以下のモノがある。~
---Chrome Custom Tabs（Android向け）~
https://developer.chrome.com/multidevice/android/customtabs
---SFSafariViewController（iOS向け）~
https://developer.apple.com/library/ios/documentation/SafariServices/Reference/SFSafariViewController_Ref/
***[[スマホ向けベストプラクティス (RFC 8252 ... OAuth 2.0 for Native Apps)>OAuth 2.0 for Native Apps]] [#q93a1734]
***[[認可コード横取り攻撃への対抗策 (RFC 7636 ... OAuth PKCE)>OAuth PKCE]] [#h47e1abd]
**新しい仕様 [#c3029b90]
その他、新しい仕様も策定されている。
***[[トークン取り消し (RFC 7009 ... OAuth Token Revocation)>OAuth 2.0 Token Revocation]] [#me8f72f8]
***[[トークン情報取得 (RFC 7662 ... OAuth Token Introspection)>OAuth 2.0 Token Introspection]] [#zd8a101d]
**[[OpenID Connect]]で追加された仕様 [#m0985cde]
***[[応答タイプ (response_type)の追加>OAuth 2.0 Multiple Response Type Encoding Practices]] [#gd28c140]
***[[応答モード (response_mode)の新設>OAuth 2.0 Form Post Response Mode]] [#j8d1a782]
***[[claimsリクエスト・パラメタ>OpenID Connect#e26320e4]] [#m41fbfa5]
***[[認証コンテキストクラス>OpenID Connect#ja81c8fa]] [#t1a6b311]
***[[リクエスト・オブジェクト>OpenID Connect#m6d72953]] [#uab73e23]
**[[Financial API (FAPI)]]で追加された仕様 [#s0c8773b]
**参考 [#bc772000]
-今更聞けない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
-GoogleのOAuth 2.0実装におけるToken置換攻撃の防ぎ方 - r-weblife~
http://d.hatena.ne.jp/ritou/20120702/1341235859
-HTTPS でも Full URL が漏れる？OAuth の Code も漏れるんじゃね？？~
http://oauth.jp/blog/2016/07/27/https-full-url-leaks/
***[[UserAgentでOAuth2のTokenを取得するベスト・プラクティス]] [#jec853e3]
***[[OAuth 2.0 の脅威モデルとセキュリティの考慮事項 (RFC 6819)>OAuth 2.0 Threat Model and Security Considerations]] [#t8e931a5]
***OAuth 1.0 のほうが OAuth 2.0 より安全なの？ [#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 を採用するのが良い。
-OAuth 2.0 and the Road to Hell – hueniverse~
http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
*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
***概要 [#z2e4e62c]
-認可サーバーにより発行されたアクセストークンを、~
保護リソースエンドポイント (狭義の Web API) に渡す方法を定めた仕様
-次の 3 つの方法を定義されている。
--[[Authorization Request Header Field>https://tools.ietf.org/html/rfc6750#section-2.1]]~
Authorization ヘッダに埋め込む方法
--[[Form-Encoded Body Parameter>https://tools.ietf.org/html/rfc6750#section-2.2]]~
リクエスト・ボディに埋め込む方法
--[[URI Query Parameter>https://tools.ietf.org/html/rfc6750#section-2.3]]~
クエリ・パラメタとして渡す方法
***フロー [#xf758bc1]
+--------+ +---------------+
| |--(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 - OAuth 2.0 Device Flow for Browserless and Input Constrained Devices~
https://tools.ietf.org/html/draft-ietf-oauth-device-flow
-概要
--入力デバイスを持たないデバイスでOAuth2を行う場合のフロー。
--別のデバイスで入力を始めるための(C) User Code & Verification URI には、以下が使用できる。
---QRコードやNFC、
---e-mailやSMS（Remote Phishingに注意）
-フロー
+----------+ +----------------+
| |>---(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 | | |
+----------+ +----------------+
*参考 [#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]]
-OAuth 2.0 の仕組みと認証方法 | murashun.jp~
https://murashun.jp/blog/20150920-01.html
-OAuth 2.0の代表的な利用パターンを仕様から理解しよう - Build Insider~
http://www.buildinsider.net/enterprise/openid/oauth20
***＠IT [#n0d6d892]
-デジタル・アイデンティティ技術最新動向 連載インデックス~
http://www.atmarkit.co.jp/fsecurity/index/index_digid.html
--デジタル・アイデンティティ技術最新動向（1）：「OAuth」の基本動作を知る
---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サービスの利用方法はどう変わるか
--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
***Qiita [#rde475d1]
-OAuth & OpenID Connect 関連仕様まとめ - Qiita~
https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3
-OAuth 2.0 の仕様を読むために - Qiita~
http://qiita.com/awakia/items/66975de18ba25f18a961
-色々な OAuth のフローと doorkeeper gem での実装 - Qiita~
http://qiita.com/tyamagu2/items/5aafff7f6ae0a9ec94aa
***slideshare [#o0d0ea56]
-今更聞けないOAuth2.0~
http://www.slideshare.net/ph1ph2sa25/oauth20-46144252
-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]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
