MS_UserAgentOAuthBestPractice

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

• 戻る（OAuth 2.0 セキュリティ関連トピック）
  • UserAgentでOAuth2のTokenを取得するベスト・プラクティス
  • AppAuth
  • OAuth 2.0 for Native Apps
  • OAuth 2.0 for Browser-Based Apps

概要

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

詳細

OAuth 2.1

OAuth 2.1を参照。

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

補足（結論は出た）: 「非推奨になってきたらしい」と書かれていた Implicit Flow は、
その後 RFC 9700（OAuth 2.0 Security BCP）と OAuth 2.1 で
正式に廃止された。
現在の SPA の標準構成は、本節が述べているとおり
Authorization Code ＋ PKCE である。

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

（OpenID Connect の 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 みたいな方式はアリかもしれない。

補足（Token Binding は普及しなかった）: 「雲行きが怪しくなっている」と
書かれていた Token Binding は、
主要ブラウザが実装を見送ったため事実上ディスコンになった。
送信者制約付きトークンの手段としては、現在
OAuth2.0 DPoP（RFC 9449）と
Mutual TLS（RFC 8705）が標準化されており、
FAPI 2.0 もこの 2 つを前提にしている。

OAuth2.0 DPoP（ドラフト）

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

（OAuth2.0 DPoPを参照。現在は RFC 9449 として発行済み）

PKCE 4 SPAでFA（現時点で）

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

移行メモ（添付ファイル）: 上の図（元の添付ファイル名 PKCE Flow.jpg）は、
元ページに添付されていたが本文からは参照されていなかった。
内容が本節（SPA における PKCE のフロー）に対応するため、ここに配置した。

Token保存先の問題

JWTのコンテキストで何故かSessionとかCookieとかを参照。

スマホ

スマホの前提条件

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

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

スマホではImplicitは使用できない。

• Implicit グラント種別

• Implicit Flow

スマホではHybrid Flowも使用できない。

（OpenID Connect の Hybrid Flow）

移行メモ（アンカーの重複）: 元ページでは SPA 側の
「Hybrid Flow でセキュリティが強化。」と
スマホ側の「Hybrid Flow も使用できない。」に
同じアンカー ID が振られていた（PukiWiki 側の記述ミス）。
移行先では見出しの文字列がそのままアンカーになるため影響はない。

スマホではOAuth PKCEを適切に利用する。

OAuth PKCEを参照。

スマホでもFinancial API (FAPI)は策定中。

Financial API (FAPI)を参照。

補足（SPA とスマホの違い）: 両者はどちらも
client_secret を持てないパブリック クライアントだが、
リダイレクトの受け口が違う。

	SPA	スマホ（ネイティブ）
受け口	自ドメインの HTTPS URL	カスタム URI スキーム／App Links
主な脅威	XSS によるトークン奪取	他アプリによるスキーム乗っ取り
対策	PKCE ＋ BFF、トークンを JS から隔離	PKCE ＋ クレーム済み HTTPS スキーム

本ページが SPA とスマホを別立てで論じているのは、この違いによる。

参考

OAuth 2.1 の参考

OAuth 2.1

ベストプラクティス

• AppAuth
• OAuth 2.0 for Native Apps
• OAuth 2.0 for Browser-Based Apps

Financial API (FAPI) の参考

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

本 Wiki 内

• OAuth 2.0 セキュリティ関連トピック
• OAuth PKCE
• Single-page application
• OAuth2.0 DPoP

---

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