OAuth 2.0 拡張のバックアップの現在との差分(No.1)

追加された行はこの色です。
削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>OpenID / OAuth / OpenID Connect]]
-[[戻る>OAuth 2.0]]

* 目次 [#q668539e]
#contents

*概要 [#he82b607]
OAuth 2.0には、様々な拡張仕様がある。

*拡張のフロー [#a928aa75]
以下のような拡張フローがある。

*その他のフロー [#a928aa75]
その他にも、以下のようなフローがある。

**[[JWTを使用したフロー>JWTとOAuth2.0]] [#x249e0e5]

***[[JWT bearer token authorizationグラント種別>JWTとOAuth2.0#f5007063]] [#y0f15b12]

***[[JWT Secured Authorization Request (JAR)>JWTとOAuth2.0#bdaa0ed5]] [#mfd0576e]

***[[OAuth2.0 Proof of Possession>JWTとOAuth2.0#u8ebfddc]] [#v22d1559]

**[[スマホ向けフロー>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>#b53eb0b8]] [#l14e2ae9]
「Redirect フロー」ではなく「Decoupled フロー」を使用。

***%%[[OAuth 2.0 Device Flow]]%% [#l14e2ae9]
http://self-issued.info/?p=1959

と言った理由で、[[以下>#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]

**[[Financial API (FAPI)で追加された仕様>Financial API (FAPI)#l4147461]] [#oddb9c14]
***[[リクエスト・オブジェクト>OpenID Connect#q19eeb33]] [#f04145a9]

*セキュリティ [#w4627adf]
セキュリティに関する考察と、考慮点。
**[[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]

**認証に使用する [#ff0c2b15]
**その他の拡張仕様 [#r44b96bf]

***問題点 [#xcb4d357]
認証ではなく認可のためのプロトコル（権限委譲プロトコル）である。~
OAuth 2.0の仕様を熟読してもOAuth2.0を認証に使用しても問題ないように見える。
***[[JWTとOAuth2.0]] [#q1643d9b]

以下のBlogを参照して、
***[[Token Binding]] [#v6e16f50]

-認可のためのプロトコルの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の作り次第）。

-OAuth2を拡張して、
--[[Bearer TokenをJWTアサーションに変更する。>JWTとOAuth2.0#y9c24d21]]
--[[OAuth 2.0 拡張で追加された仕様>#f7c32a8e]]をサポートする。
--[[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/

*The OAuth 2.0 Authorization Framework [#n3873207]
-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のフロー定義 [#g7821047]
OAuth 2.0仕様には4つのフローが定義されている。~
これらのフローのタイプを「グラント種別」と呼ばれる。

-IPA ISEC　セキュア・プログラミング講座：~
Webアプリケーション編　第8章 マッシュアップ：サーバサイドマッシュアップ~
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html

以下の様な「グラント種別」がある模様。

***Authorization Codeグラント種別 [#t756e577]
-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グラント種別 [#cf24d446]
-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グラント種別 [#jcb1236b]
-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グラント種別 [#sda19d82]
-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 [#a3ec5cbb]
-RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage~
https://tools.ietf.org/html/rfc6750

***概要 [#yc6bf6dd]
-認可サーバーにより発行されたアクセストークンを、~
保護リソースエンドポイント (狭義の 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]]~
クエリ・パラメタとして渡す方法

***フロー [#r91d6399]
  +--------+                               +---------------+
  |        |--(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 ---|               |
  +--------+                               +---------------+

**その他 [#o5ba38b5]
***OAuth 2.0 Device Flow [#iaf6a197]
-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 |                                |                |
      +----------+                                +----------------+

*参考 [#w02cc0d7]
-OAuth - Wikipedia~
https://ja.wikipedia.org/wiki/OAuth

**OAuth 1.0 [#p21aa8ec]

-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 [#kf0c5742]
-[[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 [#td234676]
-デジタル・アイデンティティ技術最新動向 連載インデックス~
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 [#l7c63c6d]
-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 [#n243ede8]
-今更聞けない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]] [#h250e475]

----
Tags: [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
OAuth 2.0 拡張 のバックアップの現在との差分(No.1)
