「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>OAuth#jec853e3]] * 目次 [#v8b8e49a] #contents *概要 [#d531ad5d] UserAgentでOAuth2のTokenを取得するベスト・プラクティス~ (UserAgentから、直接、Resource ServerのWebAPIにアクセスする) *詳細 [#l33d0f36] **SPA [#q18ff74d] SPA : Single Page Application ***Implicitが使用できる。 [#g8b68319] -[[Implicitグラント種別>OAuth#m5c2d510]] -[[Implicit Flow>OpenID Connect#e7adf5c2]] ***[[Hybrid>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] **スマホ [#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>OpenID Connect#l565139a]]も使用できない。 [#ya921110] ***[[OAuth PKCE]]を適切に利用する。 [#x48308e1] -これにより「Private-Use URL Scheme上書き攻撃」などから保護される。 -入手したcodeはClientのServer側にポストしてアクセストークン・リクエストする。~ ※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。 ***response_typeにcodeやtokenを利用できる可能性。 [#j93aa5d5] -Private-Use URI Scheme Redirection以外にも、~ [[プラットフォームによっては、よりセキュアなプロセス間通信方法がある>OAuth 2.0 for Native Apps#m215f35d]]。 -これを利用することで、codeとtokenが完全に保護されるのであれば、~ response_typeにcodeやtokenを利用することもできるかも。 --Authorization Code ---[[Authorization Codeグラント種別>OAuth#yfeb403d]] ---[[Authorization Code Flow>OpenID Connect#mcde509a]] --Implicit ---[[Implicitグラント種別>OAuth#m5c2d510]] ---[[Implicit Flow>OpenID Connect#e7adf5c2]] --[[Hybrid Flow>OpenID Connect#l565139a]] ***[[Financial API (FAPI)>#q58a3e42]]も策定中。 [#q58a3e42] **[[Financial API (FAPI)]] [#q58a3e42] -金融向け規格なので、前述よりさらにセキュリティ・レベルが強化される。 -現時点では、まだドラフト段階だが、スマホ、SPA、共に、この規格の導入を検討してイイ。 *参考 [#t3d9eecd] **仕様 [#yba7af6f] ***[[スマホ向けベストプラクティス (RFC 8252 ... OAuth 2.0 for Native Apps)>OAuth 2.0 for Native Apps]] [#q93a1734] ***[[認可コード横取り攻撃への対抗策 (RFC 7636 ... OAuth PKCE)>OAuth PKCE]] [#h47e1abd] ***[[OAuth PKCE]]利用時の構成図 [#nd4ecb50] スマホの[[OAuth PKCE]]認証フローは複雑で忘れ易く、~ 開発環境の構築時も「どうするんだっけ?」と一苦労するのでメモ。 +[[OAuth PKCE]]の認可リクエスト ~ 認可レスポンスで、Client(UserAgent)はcodeを入手 +codeをClient(Server)にpostしてアクセストークン・リクエスト([[PKCE>OAuth PKCE]]) +Client(UserAgent)は、Client(Server)経由でaccess_tokenを受け取り、Resource Serverにリソースをリクエスト #ref(PKCE Flow.jpg,left,nowrap,OAuth PKCE利用時の構成図,30%) ---- Tags: [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]