Skip to content

MS_OAuthForBrowserBasedApps

Jump to bottom
nishi_74322014 edited this page Sep 1, 2026 · 1 revision

OAuth 2.0 for Browser-Based Apps

概要

  • ブラウザベースのアプリケーション（≒ SPA）を
    開発するときの OAuth 2, OIDC の考慮事項とベストプラクティス

  • Native App 同様、

    • Public Client なので、client_secret を使用することはできない。
    • OAuth 2, OIDC を実装する際の類似点が取り上げられている。

詳細

アーキテクチャ

APIと同一ドメイン

エンプラ SPA 的なアプリケーションは Session を認証として使用してイイ

  • Session 認証には、可動部分が少なく、攻撃ベクトルが少ないという利点がある。

  • フェデレーション・アクセスが無いため、
    OAuth 2, OIDC が最適なソリューションではない。

バックエンド・コンポーネント

  • バックエンド・コンポーネントは本質的に、ブラウザ内で実行されているコードの新しい認証サーバ

    • 独自の token（たとえば SessionCookie）を発行する可能性。

  • Token リクエストをバックエンド・コンポーネントから実行することを希望する可能性がある。

    • Code → Access Token
    • Refresh Token → Access Token

  • 独自の Client Secret が発行された Confidential Client

    • HTTPS の Redirect URI の完全一致を Client 認証として自動再認証を許可できる。
      （ワイルドカード・ドメイン/パス、クエリ文字列を含まない）
    • ただし、Authentication Server は、デプロイメント全体から
      バックエンド・コンポーネントも Public Client と看做すことがある。

移行メモ（表記）: 元ページの「バックエンドコン・ポーネント」（3 箇所）は
中黒の位置が誤っているため「バックエンド・コンポーネント」に統一した。

補足（BFF パターン）: ここでいう「バックエンド・コンポーネント」は、
現在 BFF（Backend For Frontend）と呼ばれる構成である。
トークンをブラウザに渡さずサーバ側に置き、
ブラウザとは HttpOnly な Cookie でやり取りするため、
XSS でトークンを盗まれる経路がなくなる。
後継の草案（oauth-browser-based-apps）では、
この BFF 方式が推奨される第一の選択肢として整理されている。

Flow

Authorization Code

  • state を使用
  • Redirect URI
    • 完全一致を推奨
    • 柔軟性を提供する場合、ホスト名と一致

※ OAuth 2.0 で行う HTTP 通信

  • フロントチャネル（ユーザーのブラウザを介した通信）
  • バックチャネル（ユーザーが介在しない、サーバーサイド同士の通信）

Implicit Flow

  • 脅威

    • リダイレクト URI の傍受
    • ブラウザ履歴からのトークン漏洩
    • スクリプト
      • 悪意のあるスクリプト注入による操作
      • サードパーティ・スクリプトによる漏洩

  • 欠点

    • Access Token の検証メカニズムが無い
    • Redirect が失敗したり傍受されたりする可能性がある
    • 関連するセキュリティ上の考慮事項、追加のコードが多い。

  • 基本的に

    • PKCEが推奨
    • 特に側（皮）ネイティブの場合は、PKCE

補足（Implicit は廃止された）: 本ページが「非推奨の流れ」と
述べていた Implicit Flow は、その後 OAuth 2.0 Security BCP と
OAuth 2.1 で正式に廃止された。
現在はブラウザ アプリでも
Authorization Code ＋ PKCE が唯一の選択肢である。
「側（皮）ネイティブ」は、
WebView でラップしただけのハイブリッド アプリを指す著者の言い回し。

Refresh Token

Authentication Server は、SPA に（フロントチャネルで）Refresh Token を

  • 発行すべきではない。
  • 発行する場合、1 回限りの使用とする。
  • 長期保存する場合、静的 JavaScript に制限するなど。

補足（Refresh Token Rotation）: 「1 回限りの使用とする」は、
現在 Refresh Token Rotation として定着した方式である。
使うたびに新しい Refresh Token を発行して古いものを無効化し、
同じ Refresh Token が 2 回使われたら盗難とみなして
その系列をすべて失効させる。

OAuth PKCE

SPA 向けの OAuth PKCE

結論

OAuth 2.0 for Native Apps とだいたい同じ

使用するフロー

Implicitは脅威・欠点が多いので非推奨の流れ。

UserAgentでOAuth2のTokenを取得するベスト・プラクティスの
「詳細 → Implicit フロー非推奨」を参照。

バックチャネルで発行するならAuthorization Code

SPA に token を渡せないが、Implicit と比べ脅威・欠点が少ない。

フロントチャネルで発行するならOAuth PKCE

SPA に token を渡す場合、OAuth PKCE を使う。

Client認証

ただし、バックエンド・コンポーネントが Confidential Client とみなせるので、
一部扱いを変えることが出来る（ClientId ＋ RedirectUrl で Client 認証可能）。

参考

仕様

AppAuth

AppAuth

当該ベストプラクティスの採用を助ける OpenID Foundation が後援する一連のライブラリ。

本 Wiki 内

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally