「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>OpenID / OAuth / OpenID Connect]] * 目次 [#q668539e] #contents *概要 [#he82b607] *その他のフロー [#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] *新しい仕様 [#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] **[[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] ***[[認証コンテキストクラス>OpenID Connect#ja81c8fa]] [#v9600ae2] ***[[リクエスト・オブジェクト>OpenID Connect#m6d72953]] [#f04145a9] **[[Financial API (FAPI)で追加された仕様>Financial API (FAPI)#l4147461]] [#oddb9c14] *セキュリティ [#w4627adf] セキュリティに関する考察と、考慮点。 **認証に使用する [#ff0c2b15] ***問題点 [#xcb4d357] 認証ではなく認可のためのプロトコル(権限委譲プロトコル)である。~ 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で公開しているリソースへのアクセスを認可する。」 という限られた権限より、(システムにログインできるということは)大きい権限を委譲することになるので、~ この発言の背景では、「認可に比べ、認証に使用した場合、リスクが大きい。」という問題が懸念されている。 ***対応方法 [#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]]