- 追加された行はこの色です。
- 削除された行はこの色です。
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>OAuth 2.0 セキュリティ関連トピック]]
* 目次 [#v8b8e49a]
#contents
*概要 [#d531ad5d]
UserAgent（[[SPA>#q18ff74d]]や[[スマホ>#m0aacf50]]）でOAuth2のTokenを取得するベスト・プラクティス~
（UserAgentから、直接、Resource ServerのWebAPIにアクセスする）
*詳細 [#l33d0f36]
**SPA [#q18ff74d]
SPA : Single Page Application
***Implicitが使用できる。 [#g8b68319]
...が、最近、
-[[Implicitグラント種別>OAuth#m5c2d510]]
-[[Implicit Flow>OpenID Connect#e7adf5c2]]
が、[[公式に非推奨>OAuth 2.0 Security Best Current Practice]]になったらしい。
***[[Hybrid Flow>OpenID Connect#l565139a]]でセキュリティが強化される。 [#ya921110]
-codeやtokenのscope（認可された権限）を変える。~
※ [[Financial API (FAPI)>#q58a3e42]]では、token：参照系、code：更新系などとなっている。
-入手したcodeはClientのServer側にポストして使用する。~
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。
***[[Financial API (FAPI)>#q58a3e42]]も策定中。 [#x3cf1768]
-[[Token Binding]]時代の到来。
-[[PKCE＋Token Binding＋Fragment>OAuth 2.0 Security Best Current Practice#c545761d]]
※ [[Token Binding]]の雲行きが怪しくなっているので、~
PKCE＋Fragment みたいな方式はアリかもしれない。
***[[OAuth2.0 DPoP]] [#gbb640b2]
-SPAをターゲットとして仕様が作成されている。
-名前の通り、アプリケーション・レイヤで、[[記名式切符>トークン#b38de47f]]を発行することができる。
-これにより、SPAから直接Tokenエンドポイントにリクエストすることができる。
**スマホ [#m0aacf50]
***前提条件 [#u115b44f]
-（セキュリティ的懸念から）認可リクエストを、外部Webブラウザを経由してのみ行う。~
[[プラットフォームによっては、外部Webブラウザ相当のUXを向上させる仕組みが用意されている>OAuth 2.0 for Native Apps#m215f35d]]。
-codeとtokenが、「Private-Use URL Scheme上書き攻撃」などから保護されない可能性がある。
***Implicitは使用できない。 [#ubdf2972]
-[[Implicitグラント種別>OAuth#m5c2d510]]
-[[Implicit Flow>OpenID Connect#e7adf5c2]]
***[[Hybrid Flow>OpenID Connect#l565139a]]も使用できない。 [#ya921110]
***[[OAuth PKCE]]を適切に利用する。 [#x48308e1]
-これにより「Private-Use URL Scheme上書き攻撃」などから保護される。
-入手したcodeはClientのServer側にポストしてアクセストークン・リクエストする。~
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。
***[[Financial API (FAPI)>#q58a3e42]]も策定中。 [#m9f94dc3]
[[Token Binding]]時代の到来。
**[[Financial API (FAPI)]] [#q58a3e42]
-金融向け規格なので、前述よりさらにセキュリティ・レベルが強化される。
-現時点では、まだドラフト段階だが、スマホ、SPA、共に、この規格の導入を検討してイイ。
--F-API 1 / 2 共に、Confidential Client / Public Clientのプロファイルを持っている。
--このうち、スマホ / SPA、は、Public Clientのプロファイルを適用する。
***[[FAPI Part 1>FAPI Part 1 (Read Only API Security Profile)#k5a50e89]] [#z00a2dcb]
[[S256のPKCE>OAuth PKCE#k363fd25]]
***[[FAPI Part 2>FAPI Part 2 (Read and Write API Security Profile)#y974f9a7]] [#sf28cb1a]
...未定...
**サマリ [#g08a7d1d]
現状では、
***図 [#b7b6e112]
|#|方式|Flow|認証（BackendからのResourceアクセス）|認可（FrontendからのResourceアクセス）|h
|1|>|Web Forms / MVC|||
|1-1|・|Authorization Code Flow|○|－|
|2|>|SPA|||
|2-1|・|Authorization Code Flow|○|△|
|2-2|・|Implicit Flow|△|○|
|2-3|・|Hybrid Flow|○|○|
|2-4|・|PKCE + Fragment|○|○|
|3|>|Native|||
|3-1|・|PKCE|○|○|
***解説 [#m755c54d]
-2-1~
SPAとAuthorization Code Flowはミスマッチ。
--Backendで認証可能
--FrontendにAccessTokenが渡らない（Hiddenに入れて渡すなどは可能）。
-2-2~
Authorization Code Flowより適合した方式。
--FrontendにAccessTokenが渡る。
--Backendの認証が出来ない（AccessTokenをBackendにPOSTすれば可能）。
-2-3~
上記の2-1, 2-2の問題を解消した方式。
--FrontendにAccessTokenが渡る。
--BackendにcodeをPOSTし、Backendが、AccessToken Requestする。
-2-4~
上記の2-3よりセキュアにした方式。
--BackendにcodeをPOSTし、Backendが、AccessToken Requestする。
--FrontendからのResourceServerアクセスは
---Backend経由とするか、
---codeをPOSTした際の戻り値としてAccessTokenを受け取る。
*参考 [#t3d9eecd]
**仕様 [#qd8e4d14]
***[[OAuth 2.0 for Native Apps]] [#ze7530a4]
***[[OAuth 2.0 Security Best Current Practice]] [#of822fba]
**OSSコンソーシアム [#a0dd64d2]
-UserAgentでOAuth2のTokenを取得するベスト・プラクティス~
https://www.osscons.jp/joavafb1i-537/#_537
-Single Sign-On user experience with OAuth PKCE by Open棟梁 and Cordova.~
https://www.osscons.jp/jobgbko8n-537/#_537
**[[OAuth PKCE]]利用時の構成図 [#nd4ecb50]
スマホの[[OAuth PKCE]]認証フローは複雑で忘れ易く、~
開発環境の構築時も「どうするんだっけ？」と一苦労するのでメモ。
Client（UserAgent）は、
+[[OAuth PKCE]]の認可リクエスト ～ 認可レスポンスで、codeを入手
+codeをClient（Server）にpostしてアクセストークン・リクエスト（[[PKCE>OAuth PKCE]]）
+Client（Server）経由でaccess_tokenを受け取り、
+access_tokenを使用してResource Serverにリソースをリクエスト
#ref(PKCE Flow.jpg,left,nowrap,OAuth PKCE利用時の構成図,30%)
※ よくよく見ると、Cordovaと外部ブラウザでSessionが違うので、~
stateもcode_verifierもCordova側で生成・保持しておく必要がある。
※ また、code_challengeは、Server側でcode_verifierを受け取り、~
ハッシュ関数（plain or S256）を選択して生成する必要がある。
----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
