「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
UserAgent?(SPAやスマホ)でOAuth2のTokenを取得するベスト・プラクティス
(UserAgent?から、直接、Resource ServerのWebAPIにアクセスする)
詳細 †
SPA †
SPA : Single-page application
Implicitが使用できる...が非推奨。 †
- CORSで、TokenエンドポイントにRequest可能になってきたので、
と言う方法が、SPAにおける認証・認可の推奨になりつつある。
- これにより「Private-Use URL Scheme上書き攻撃」などから保護される。
- 入手したcodeはClientのServer側にポストしてアクセストークン・リクエストする。
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。
を参照のこと。
- 入手したcodeはClientのServer側にポストして使用する。
※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。
- 問題は、マイナーで、プロファイルがあまり明確ではないこと。
Token Bindingの雲行きが怪しくなっているので、
PKCE+Fragment みたいな方式はアリかもしれない。
- SPAをターゲットとして仕様が作成されている。
- 名前の通り、アプリケーション・レイヤで、記名式切符を発行することができる。
- これにより、SPAから直接Tokenエンドポイントにリクエストすることができる。
Authorization Code Grant Flow with PKCEがSPAでのImplicit代替としてデファクト化。
Token保存先の問題 †
- 上記で、安全にTokenを取得しても、保存先の問題がある。
- セキュアと言われているモノには、
SameSite?が前提であるモノも多いので、
結局アプリをセキュアにして行く必要がある。
- Defence in DepthしてもWeakest Linkになるので、
大差ない基盤の1層に注力しても全体としてセキュアにならない。
スマホ †
前提条件 †
- codeとtokenが、「Private-Use URL Scheme上書き攻撃」などから保護されない可能性がある。
Implicitは使用できない。 †
参考 †
ベストプラクティス †
≒S256のPKCE
OSSコンソーシアム †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth