- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>OAuth]]
-[[戻る>OAuth 2.0]]
* 目次 [#q668539e]
#contents
*概要 [#he82b607]
OAuth 2.0には、（主に[[セキュリティ>#w4627adf]]強化のための）様々な拡張仕様がある。
OAuth 2.0には、様々な拡張仕様がある。
*拡張のフロー [#a928aa75]
以下のような拡張フローがある。
**[[スマホ向けフロー>UserAgentでOAuth2のTokenを取得するベスト・プラクティス#m0aacf50]] [#kf23d0ff]
***[[スマホ向けベストプラクティス (RFC 8252 ... OAuth 2.0 for Native Apps)>OAuth 2.0 for Native Apps]] [#w3e356fb]
***[[認可コード横取り攻撃への対抗策 (RFC 7636 ... OAuth PKCE)>OAuth PKCE]] [#ec698d28]
**その他のデバイス向けフロー [#u7974975]
***OAuth 2.0 Device Flow [#l14e2ae9]
-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
「Redirect フロー」ではなく「Decoupled フロー」を使用。
-概要
--入力デバイスを持たないデバイスでOAuth2を行う場合のフロー。
--別のデバイスで入力を始めるための(C) User Code & Verification URI には、以下が使用できる。
---QRコードやNFC、
---e-mailやSMS（Remote Phishingに注意）
***%%[[OAuth 2.0 Device Flow]]%% [#l14e2ae9]
http://self-issued.info/?p=1959
-フロー
+----------+ +----------------+
| |>---(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 | | |
+----------+ +----------------+
と言った理由で、[[以下>#l14e2ae9]]に変更される。
***[[OAuth 2.0 Device Authorization Grant]] [#g7ba4478]
***[[CIBA(Client Initiated Backchannel Authentication)]] [#a36cb842]
*新しい仕様 [#z5a41bc7]
その他、新しい仕様も策定されている。
**OAuth 2.0 拡張で追加された仕様 [#gc724ffd]
***[[トークン取り消し (RFC 7009 ... Token Revocation)>OAuth 2.0 Token Revocation]] [#i4195867]
***[[トークン情報取得 (RFC 7662 ... Token Introspection)>OAuth 2.0 Token Introspection]] [#m4ddb086]
***[[各種クライアント認証>JWTとOAuth2.0#pebd83d3]] [#t68364d7]
**[[OpenID Connect]]で追加された仕様 [#ta009e42]
***[[応答タイプ (response_type)の追加>OAuth 2.0 Multiple Response Type Encoding Practices]] [#c0f7842f]
***[[応答モード (response_mode)の新設>OAuth 2.0 Form Post Response Mode]] [#m6ef2050]
***[[claimsリクエスト・パラメタ>OpenID Connect#e26320e4]] [#l4d1b973]
***[[claimsリクエスト・パラメタ>OpenID Connect#nd004268]] [#l4d1b973]
***[[認証コンテキストクラス>OpenID Connect#ja81c8fa]] [#v9600ae2]
***[[リクエスト・オブジェクト>OpenID Connect#m6d72953]] [#f04145a9]
＝ [[JWT Secured Authorization Request (JAR)]]
***[[リクエスト・オブジェクト>OpenID Connect#q19eeb33]] [#f04145a9]
**[[Financial API (FAPI)で追加された仕様>Financial API (FAPI)#l4147461]] [#oddb9c14]
**[[Financial API (FAPI)>Financial API (FAPI)#l4147461]]で追加された仕様 [#oddb9c14]
***[[FAPI Part 1>FAPI Part 1 (Read Only API Security Profile)#i8ef7e99]] [#q5522efe]
***[[FAPI Part 2>FAPI Part 2 (Read and Write API Security Profile)#i8ef7e99]] [#oa771b04]
*セキュリティ [#w4627adf]
セキュリティに関する考察と、考慮点。
**その他の拡張仕様 [#r44b96bf]
**認証に使用する [#ff0c2b15]
***[[JWTとOAuth2.0]] [#q1643d9b]
***問題点 [#xcb4d357]
認証ではなく認可のためのプロトコル（権限委譲プロトコル）である。~
OAuth 2.0の仕様を熟読してもOAuth2.0を認証に使用しても問題ないように見える。
***[[Token Binding]] [#v6e16f50]
以下の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で公開しているリソースへのアクセスを認可する。」
という限られた権限より、（システムにログインできるということは）大きい権限を委譲することになるので、~
この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。
***対応方法 [#la5fb715]
従って、この問題は、
-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の作り次第）。
-基本実装を拡張する。
--[[Bearer TokenをJWTアサーションに変更する。>JWTとOAuth2.0#y9c24d21]]
--OAuth 2.0 拡張で
---[[追加のクライアント認証>#t68364d7]]をサポートする。
---[[追加された仕様>#gc724ffd]]をサポートする。
--[[OpenID Connect]]をサポートする。
**参考 [#o3895e58]
-今更聞けない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を取得するベスト・プラクティス]] [#efffc2bf]
***[[OAuth 2.0 の脅威モデルとセキュリティの考慮事項 (RFC 6819)>OAuth 2.0 Threat Model and Security Considerations]] [#x831a54c]
***OAuth 1.0 のほうが OAuth 2.0 より安全なの？ [#bd33e119]
-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/
*参考 [#w02cc0d7]
-OAuth & OpenID Connect 関連仕様まとめ - Qiita~
https://qiita.com/TakahikoKawasaki/items/185d34814eb9f7ac7ef3
----
Tags: [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
