![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>UserAgentでOAuth2のTokenを取得するベスト・プラクティス]] --[[AppAuth]] --[[OAuth 2.0 for Native Apps]] --OAuth 2.0 for Browser-Based Apps * 目次 [#pa22b9dc] #contents *概要 [#k77a528c] -ブラウザベースのアプリケーション（≒ [[SPA>SPAとMPA#q8640287]]）を~ 開発するときの[[OAuth]]2, [[OIDC>OpenID Connect]]の考慮事項とベストプラクティス -[[Native App>OAuth 2.0 for Native Apps]]同様、 --Public Clientなので、client_secretを使用することはできない。 --[[OAuth]]2, [[OIDC>OpenID Connect]]を実装する際の類似点が取り上げられている。 *詳細 [#bb1e75ec] **アーキテクチャ [#ge97172e] ***APIと同一ドメイン [#jafe0e54] エンプラ[[SPA>SPAとMPA#q8640287]]的なアプリケーションはSessionを認証として使用してイイ -Session認証には、可動部分が少なく、攻撃ベクトルが少ないという利点がある。 -フェデレーション・アクセスが無いため、[[OAuth]]2, [[OIDC>OpenID Connect]]が最適なソリューションではない。 ***バックエンド・コンポーネント [#dcd8c1b5] -バックエンドコン・ポーネントは本質的に、ブラウザ内で実行されているコードの新しい認証サーバ --独自のtoken（たとえばSessionCookie）を発行する可能性。 -Tokenリクエストをバックエンド・コンポーネントから実行することを希望する可能性がある。 --Code → Access Token --Refresh Token → Access Token -独自のClient Secretが発行されたConfidential Client --HTTPSのRedirect URIの完全一致をClient認証として自動再認証を許可できる。~ （ワイルドカード・ドメイン/パス、クエリ文字列を含まない） --ただし、Authentication Serverは、デプロイメント全体から~ バックエンドコン・ポーネントもPublic Clientと看做すことがある。 **Flow [#p9606379] ***Authorization Code [#x2bc34ee] -stateを使用 -Redirect URI --完全一致を推奨 --柔軟性を提供する場合、ホスト名と一致 ※ OAuth 2.0 で行うHTTP通信 --フロントチャネル（ユーザーのブラウザを介した通信） --バックチャネル（ユーザーが介在しない、サーバーサイド同士の通信） ***Implicit Flow [#oa547cf4] -脅威 --リダイレクトURIの傍受 --ブラウザ履歴からのトークン漏洩 --スクリプト --- 悪意のあるスクリプト注入による操作 ---サードパーティ・スクリプトによる漏洩 -欠点 --Access Tokenの検証メカニズムが無い --Redirectが失敗したり傍受されたりする可能性がある --関連するセキュリティ上の考慮事項、追加のコードが多い。 -基本的に --[[PKCE>#c4bc526c]]が推奨 --特に側（皮）ネイティブの場合は、[[PKCE>#c4bc526c]] ***Refresh Token [#udfd76ec] Authentication Serverは、[[SPA>SPAとMPA#q8640287]]に（フロントチャネルで）Refresh Tokenを -発行すべきではない。 -発行する場合、1回限りの使用とする。 -長期保存する場合、静的JavaScriptに制限するなど。 ***[[OAuth PKCE>OAuth PKCE#k3b1f3c9]] [#c4bc526c] [[SPA向けのOAuth PKCE>OAuth PKCE#k3b1f3c9]] *結論 [#fcac960e] [[OAuth 2.0 for Native Apps>OAuth 2.0 for Native Apps#sd27cd31]]とだいたい同じ **使用するフロー [#r7253af8] ***Implicitは脅威・欠点が多いので非推奨の流れ。 [#baa5e6d8] [[UserAgentでOAuth2のTokenを取得するベスト・プラクティス → 詳細 → Implicitフロー非推奨>UserAgentでOAuth2のTokenを取得するベスト・プラクティス#c545761d]] ***バックチャネルで発行するならAuthorization Code [#a5a78018] SPAにtokenを渡せないが、Implicitと比べ脅威・欠点が少ない。 ***フロントチャネルで発行するなら[[OAuth PKCE]] [#r2146209] SPAにtokenを渡す場合、[[OAuth PKCE]]を使う。 **Client認証 [#k2e780c6] ただし、バックエンド・コンポーネントがConfidential Clientとみなせるので、~ 一部扱いを変えることが出来る（ClientId＋RedirectUrlでClient認証可能）。 *参考 [#wef0bf7a] **仕様 [#k0a4be73] -draft-parecki-oauth-browser-based-apps-01 - OAuth 2.0 for Browser-Based Apps~ https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps -超雑訳 OAuth2.0 for Browser-Based Apps - Qiita~ https://qiita.com/NewGyu/items/77c332a81f43c839c64c ***[[OAuth PKCE]] [#wd3956e1] ***[[OAuth 2.0 for Native Apps]] [#k576ac0e] **[[AppAuth]] [#af5eb035] 当該ベストプラクティスの採用を助けるOpenID Foundationが後援する一連のライブラリ。 ---- Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]
