「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
詳細 †
アーキテクチャ †
APIと同一ドメイン †
エンプラSPA的なアプリケーションはSessionを認証として使用してイイ
- Session認証には、可動部分が少なく、攻撃ベクトルが少ないという利点がある。
- フェデレーション・アクセスが無いため、OAuth2, OIDCが最適なソリューションではない。
バックエンド・コンポーネント †
- バックエンドコン・ポーネントは本質的に、ブラウザ内で実行されているコードの新しい認証サーバ
- 独自のtoken（たとえばSessionCookie?）を発行する可能性。
- Tokenリクエストをバックエンド・コンポーネントから実行することを希望する可能性がある。
- Code → Access Token
- Refresh Token → Access Token
- 独自のClient Secretが発行されたConfidential Client
- HTTPSのRedirect URIの完全一致をClient認証として自動再認証を許可できる。
（ワイルドカード・ドメイン/パス、クエリ文字列を含まない）
- ただし、Authentication Serverは、デプロイメント全体から
バックエンドコン・ポーネントもPublic Clientと看做すことがある。
Flow †
Authorization Code †
- stateを使用
- Redirect URI
- 完全一致を推奨
- 柔軟性を提供する場合、ホスト名と一致
- OAuth 2.0 authorization code flow with the PKCE extensionでは、
フロントチャンネルにアクセストークンを返さないようにする。
※ OAuth 2.0 で行うHTTP通信
- フロントチャネル（ユーザーのブラウザを介した通信）
- バックチャネル（ユーザーが介在しない、サーバーサイド同士の通信）
Implicit Flow †
- 脅威
- リダイレクトURIの傍受
- ブラウザ履歴からのトークン漏洩
- スクリプト
- 悪意のあるスクリプト注入による操作
- サードパーティ・スクリプトによる漏洩
- 欠点
- Access Tokenの検証メカニズムが無い
- Redirectが失敗したり傍受されたりする可能性がある
- 関連するセキュリティ上の考慮事項、追加のコードが多い。
Refresh Token †
Authentication Serverは、SPAに（フロントチャネルで）Refresh Tokenを
- 発行すべきではない。
- 発行する場合、1回限りの使用とする。
- 長期保存する場合、静的JavaScriptに制限するなど。
結論 †
OAuth 2.0 for Native Appsとだいたい同じ
使用するフロー †
Implicitは脅威・欠点が多いので非推奨の流れ。 †
UserAgentでOAuth2のTokenを取得するベスト・プラクティス → 詳細 → Implicitフロー非推奨
バックチャネルで発行するならAuthorization Code †
SPAにtokenを渡せないが、Implicitと比べ脅威・欠点が少ない。
SPAにtokenを渡す場合、OAuth PKCEを使う。
Client認証 †
ただし、バックエンド・コンポーネントがConfidential Clientとみなせるので、
一部扱いを変えることが出来る（ClientId?＋RedirectUrl?でClient認証可能）。
参考 †
仕様 †
当該ベストプラクティスの採用を助ける
OpenID Foundationが後援する一連のライブラリ。
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
