UserAgentでOAuth2のTokenを取得するベスト・プラクティス

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

UserAgent?（SPAやスマホ）でOAuth2のTokenを取得するベスト・プラクティス
（UserAgent?から、直接、Resource ServerのWebAPIにアクセスする）

詳細 †

SPA †

SPA : Single-page application

Implicitが使用できる...が非推奨。 †

• Implicitグラント種別、Implicit Flowが、非推奨になってきたらしい。

• CORSで、TokenエンドポイントにRequest可能になってきたので、

• OAuth PKCEを使用して、Public Client でも sender constrainedなcodeを発行。
• Fragment(response_mode=fragment) で、codeをフラグメントに乗せる。

と言う方法が、SPAにおける認証・認可の推奨になりつつある。

• これにより「Private-Use URL Scheme上書き攻撃」などから保護される。

• 入手したcodeはClientのServer側にポストしてアクセストークン・リクエストする。
  ※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。

• 詳しくは、

  OAuth 2.0 for Browser-Based AppsのPKCE

を参照のこと。

• 参考
  • OAuth 2.0 の Implicit grant 終了のお知らせ - r-weblife
    https://ritou.hatenablog.com/entry/2018/11/12/110613
    • Why you should stop using the OAuth implicit grant!
      https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926
    • OAuth 2.0 Security Best Current Practice
    • OAuth 2.0 for Browser-Based Apps

Hybrid Flowでセキュリティが強化。 †

• codeやtokenのscope（認可された権限）を変える。
  ※ Financial API (FAPI)では、token：参照系、code：更新系などとなっている。

• 入手したcodeはClientのServer側にポストして使用する。
  ※ Publicクライアントにclient_id、client_secretを持たせてはダメなので。

• 問題は、マイナーで、プロファイルがあまり明確ではないこと。

Financial API (FAPI)も策定中。 †

Token Bindingの雲行きが怪しくなっているので、
PKCE＋Fragment みたいな方式はアリかもしれない。

OAuth2.0 DPoP（ドラフト） †

• SPAをターゲットとして仕様が作成されている。
• 名前の通り、アプリケーション・レイヤで、記名式切符を発行することができる。
• これにより、SPAから直接Tokenエンドポイントにリクエストすることができる。

PKCE 4 SPAでFA（現時点で） †

Authorization Code Grant Flow with PKCEがSPAでのImplicit代替としてデファクト化。

Token保存先の問題 †

• 上記で、安全にTokenを取得しても、保存先の問題がある。

• セキュアと言われているモノには、
  SameSite?が前提であるモノも多いので、
  結局アプリをセキュアにして行く必要がある。

• Defence in DepthしてもWeakest Linkになるので、
  大差ない基盤の１層に注力しても全体としてセキュアにならない。

• 参考
  • Qiita

• SPA認証トークン、Cookieに保存するか？LocalStorage?に保存するか?
  https://qiita.com/T-Tokumori/items/b531d2c8612747dabe1e

• 認証トークンをWeb Storageに保存して良いか？
  https://qiita.com/some-nyan/items/d51c50de5f0663cf3bea

• SPAのログイン認証のベストプラクティスがわからなかったので
  わりと網羅的に研究してみた〜JWT or Session どっち？〜
  https://qiita.com/Hiro-mi/items/18e00060a0f8654f49d6

• 認証用トークン保存先の第4選択肢としての「Auth0」 - ログミーTech
  https://logmi.jp/tech/articles/324349

• Web Storage: セッショントークンのマシな手段
  cookieとセキュリティ面を比較してみる | POSTD
  https://postd.cc/web-storage-the-lesser-evil-for-session-tokens/

スマホ †

前提条件 †

• （セキュリティ的懸念から）認可リクエストを、外部Webブラウザを経由してのみ行う。
  プラットフォームによっては、外部Webブラウザ相当のUXを向上させる仕組みが用意されている。

• codeとtokenが、「Private-Use URL Scheme上書き攻撃」などから保護されない可能性がある。

Implicitは使用できない。 †

• Implicitグラント種別

• Implicit Flow

Hybrid Flowも使用できない。 †

OAuth PKCEを適切に利用する。 †

Financial API (FAPI)も策定中。 †

参考 †

ベストプラクティス †

AppAuth †

OAuth 2.0 for Native Apps †

OAuth 2.0 for Browser-Based Apps †

Financial API (FAPI) †

FAPI Part 1 †

≒S256のPKCE

FAPI Part 2 †

OSSコンソーシアム †

• 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

Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth