- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>UserAgentでOAuth2のTokenを取得するベスト・プラクティス]]
* 目次 [#sb94521c]
#contents
*概要 [#n67c1874]
Nativeアプリ（スマホ）からの[[OAuth]] 2.0 は、
-認可リクエストを、外部Webブラウザを経由してのみ行う。
-外部Webブラウザとの連携には基本的に~
「[[Private-Use URI Scheme Redirection>#m733bd4e]]」を使用する。~
（その他、プラットフォーム毎に利用可能な連携方法がある）
-外部Webブラウザ以外は、[[諸事情>#zb80abe1]]により使用しない。
-外部Webブラウザ以外には、以下のようなモノが存在しうる。
--埋め込まれたUserAgent
---WebView
---InAppBrowser
--ブラウザ以外の外部UserAgent
※ なお、Hybridアプリは、この仕様の目的ではNativeアプリ（スマホ）と同等に扱う。~
※ また、このページでは、[[OAuth]] 2.0 の一般的な考慮事項と重複する部分は割愛する。
*詳細 [#a81a5883]
**外部Webブラウザを使用した方が良い理由 [#f98074ab]
外部Webブラウザを使用すると、
-ブラウザに備わっている通常のアドレスバーや証明書の検証機能を利用できる。
-他のアプリケーションやブラウザと認証状態を共有するため優れたUXを提供できる。
-パスワード・マネージャーの機能を使用できるため、UXが向上する。
**外部Webブラウザ以外を使用してはいけない理由 [#zb80abe1]
偽造Clientの可能性があり、偽造Clientによって、
***IdPのアカウントを盗むことができる。 [#p7aa60b6]
IdPのアカウントをClientが盗む事ができる。
***IdPのSessionを盗むことができる。 [#oaec5a81]
IdPのSession cookieをClientが盗む事ができ、~
Sessionが有効な間、SSO可能な状態が持続する。
***偽造Clientは拒否されることがある。 [#le8b0457]
Googleなどが提供するOAuth2 / OIDCのAuthorization Server(IdP & STS)~
には、コレらの偽造Clientからの認可リクエストを拒否する実装が加えられている。
**Nativeアプリ（スマホ）と外部Webブラウザの連携方法 [#kabe17d0]
***Private-Use URI Scheme Redirection [#m733bd4e]
-アプリケーションが受け取る独自のURL Schemeを事前にシステムに登録する方式。
-複数のアプリが通常同じURL Schemeを登録できるため、~
Private-Use URI Scheme上書き攻撃が可能。
***Claimed Https Scheme URI Redirection [#we803830]
-[[Private-Use URI Scheme Redirection>#m733bd4e]]を改良した方式。
--ドメイン名などから、アプリを特定可能
--事前登録されていない場合は、自サイトにHTTPSで飛ぶタメ安全。
-URI権限の存在によりURI傍受の影響を受けにくいが、
--アプリはまだPublicクライアントであり、
--仕様が不明瞭なOSのURIディスパッチハンドラを使用しURIが送信される可能性がある。
***Loopback Interface Redirection [#e907b06d]
-"http://localhost:{port}/{path}"などと、~
ローカル・ループバックでHTTPリクエスを受け取る方式。
-デスクトップOSなどでの利用を想定している。
-一部のOSで同じローカル・ループバックにアクセスする、~
他のアプリの傍受の影響を受ける可能性がある。
-例えばWindowsではhostsファイルを編集される可能性があるので、~
localhostより、127.0.0.1を使用することが推奨される。
*結論 [#sd27cd31]
**使用するフロー [#ff1151b1]
***Implicitは使用できない。 [#l5080e3e]
Private-Use URI Scheme上書き攻撃などの傍受攻撃からtokenを保護できないためNG。
***Authorization Codeは、より実用的。 [#q2688eda]
Nativeにtokenを渡せないが、Implicitより実用的なオプション。
***サポートがあれば、[[OAuth PKCE]]を使う。 [#wb3e0b9c]
-Private-Use URI Scheme上書き攻撃からの保護が可能。
-スマホで認証・認可をする場合は、[[OAuth PKCE]]を使う。
**Client認証について。 [#sef76d23]
-Publicクライアントにclient_id、client_secretを持たせてはダメ。
-[[OAuth PKCEの場合、・・・。>OAuth PKCE#odafd559]]
***Client認証できない。 [#xe8b719d]
client_id、client_secretを持たないため。
***自動再認証は抑止する。 [#h2542c30]
Client認証できないので、自動再認証は抑止する。
***偽造Clientの可能性を考慮する。 [#v9c4ec9f]
-Client認証できないので、偽造Clientの可能性を考慮する必要がある。
-ここでの、偽造Clientとは、外部Webブラウザ以外を指す。
-従って、偽造Clientではない、外部Webブラウザを使用する。
--外部Webブラウザを使用すると、
---ブラウザに備わっている通常のアドレスバーや証明書の検証機能を利用できる。
---他のアプリケーションやブラウザと認証状態を共有するため優れたUXを提供できる。
--また、Googleなどが提供するOAuth2 / OIDCのAuthorization Server(IdP & STS)~
には、コレらの偽造Clientからの認可リクエストを拒否する実装が加えられている。
**動的RP登録（RFC 7591）について。 [#j8045f83]
Nativeアプリ（スマホ）は、Publicクライアントであるため、~
Dynamic Client Registrationを行う場合は、
-Client Typeを登録させ、
-合わせて、URIをチェックする
--OAuth 2.0で推奨されるURIの完全一致
--＋[[連携方式>#kabe17d0]]に合わせた＋αのチェックを行う）。
*プラットフォーム独自の有用な機能 [#m215f35d]
**iOS [#ddb9518b]
***認可リクエスト送信 [#e6b6c269]
-Safari~
アプリ内ブラウザのタブ機能なしで、~
古いバージョンのiOSで許可リクエストを開始できる。
-SFAuthenticationSession（iOS 11 以降）~
ユーザがアプリを離れることなくブラウザで許可リクエストを開始できる。
***認可レスポンス受信 [#q4309bf5]
-[[Private-Use URI Scheme Redirection>#m733bd4e]]~
Custom URL Scheme
-[[Claimed Https Scheme URI Redirection>#we803830]]~
Universal Links (iOS 9 以降)
**Android [#g21e140f]
***認可リクエスト送信 [#xe686b2f]
-Android Custom Tab
--CustomTabsServiceを使用して各ブラウザで実装する。
--Android Custom Tab の Chrome 実装が Chrome Custom Tabs になる。
***認可レスポンス受信 [#b82cdbb7]
-[[Private-Use URI Scheme Redirection>#m733bd4e]]~
Implicit Intents
-[[Claimed Https Scheme URI Redirection>#we803830]]~
Android App Links
**Windows(UWP) [#x655a186]
***認可リクエスト送信 [#f2b40ddb]
－
***認可レスポンス受信 [#nc1e8a6c]
-[[Private-Use URI Scheme Redirection>#m733bd4e]]
--URI Activation
--WebAuthenticationBroker (強化版)
-[[Loopback Interface Redirection>#e907b06d]]
--デフォルトのファイアウォールルールによって許可
--"SO_EXCLUSIVEADDRUSE"ソケットオプションを設定すべき
**macOS [#e8e59d4f]
***認可リクエスト送信 [#x4a75716]
-platform API
***認可レスポンス受信 [#r0a263b4]
-[[Private-Use URI Scheme Redirection>#m733bd4e]]~
CFBundleURLSchemes
-[[Loopback Interface Redirection>#e907b06d]]
--デフォルトのファイアウォールルールによって許可
**Linux [#ve2434e6]
***認可リクエスト送信 [#x94eb5db]
-xdg-openなどのコマンド
***認可レスポンス受信 [#d5906c2b]
-[[Loopback Interface Redirection>#e907b06d]]
--"SO_REUSEPORT"または "SO_REUSEADDR"ソケットオプションを設定してはならない
*参考 [#t35a0dca]
-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パターン
**WebView代替 [#de967a4d]
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
-代替の提案としては、以下のモノがある。~
***Android向け [#xf7a6d9c]
-Chrome Custom Tabs~
https://developer.chrome.com/multidevice/android/customtabs
***iOS向け [#hd2a71cb]
-SFSafariViewController~
https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller
-SFAuthenticationSession~
https://developer.apple.com/documentation/safariservices/sfauthenticationsession~
**仕様 [#w27f303b]
-RFC 8252 - OAuth 2.0 for Native Apps~
https://tools.ietf.org/html/rfc8252
**関連 [#i2c4b810]
***[[OAuth PKCE]] [#sfc027c9]
----
Tags: [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
