「[[マイクロソフト系技術情報 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]]