本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリ第7弾として、フロント側の認証認可について解説する記事です。
フロントはユーザーの手元・攻撃者の手元で動きます。本記事の問いは「F12で書き換えられる前提で何ができるか」です。XSS/CSRF対策・Cookie属性・CSP・トークン保管場所・リフレッシュ戦略を扱い、認証方式そのもの（MFA・Passkey・IDaaS選定）はセキュリティ章、セッション実装はソフトウェア章に委ねます。
この記事の結論
- F12（開発者ツール）で見える前提で、守れる範囲を見極める
- httpOnly Cookie+BFFを基本形にする（localStorage禁止）
- フロント認可はUIの出し分けだけ。本物の鍵はサーバにかける
- 認証は外部基盤（IDaaS）に委譲する
この記事を読む前に
本記事はブラウザ側（画面側）の仕組みの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「Webサービスが動く仕組み」と「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもフロント認証設計とは何か
フロント認証設計とは、ざっくり言えば「ブラウザという”敵の手の中”で、ユーザーの認証情報をどう安全に扱うかを決めること」です。
ガラス張りの金庫を想像してください。中身は丸見えで、鍵穴もむき出し──これがブラウザ環境です。F12（開発者ツール）を開けば変数もCookieも全て覗けます。この前提で「トークンをどこに保管するか」「XSSで盗まれない仕組みをどう作るか」を設計するのがフロント認証設計です。
なぜフロント認証設計が重要なのか
サーバーサイドのコードは管理者だけがアクセスできますが、ブラウザのJavaScriptはF12で丸見え・改ざん可能です。この前提を無視した設計は全ての認証を無意味にします。フロント側の認可判定はUIの飾りでしかなく、管理者ボタンを出す・出さないのUX制御はフロントで良いとして、本当のセキュリティチェックは必ずサーバ側で行う──この大原則を曲げた瞬間、認証設計は崩壊します。
{user.role === 'admin' && <AdminPanel />}これで管理機能は表示されなくなりますが、攻撃者はF12で条件を true に書き換えてAdminPanelを表示させられます。その時に管理APIが叩けないよう、API側で必ず権限チェックが要ります。そしてトークン保管場所の選択ミスは即座に脆弱性になります。JWTをlocalStorageに入れればXSSで盗まれ、Cookieの属性設定を誤ればCSRFで悪用される──保管場所と属性の選択がそのままセキュリティレベルを決めます。
認証方式の4択
フロント側から見た認証方式は、実質4パターンしかありません。
| 方式 | 詳細 |
|---|---|
| サーバセッション（Cookie） | 同一ドメインなら王道・最もシンプル |
| JWTをlocalStorage保持 | XSS一撃で全員分漏洩する地雷 |
| JWTをhttpOnly Cookie保持 | ハイブリッド・現実的な本命 |
| OAuth / OIDC委譲 | Auth0 / Cognito / Clerk等の外部基盤 |
「SPAだからJWTをlocalStorageに」は、古い情報源が未だに量産している罠です。現代の鉄板はCookie+BFFで、ログインフローはAuthorization Code+PKCEが一択です。PKCEはクライアントが作ったランダムなverifierのハッシュを最初のリクエストに渡し、コードをトークンに換える際に元のverifierを提示させる仕組みで、途中でcodeを盗まれても攻撃者は使えません。古いImplicit Flowは絶対に使いません。
XSSとCSRF ― フロントの2大脅威
XSS（悪意あるJSをページに混入）とCSRF（他サイトから認証済みリクエストを発火）は、どちらも認証システムを一撃で崩壊させます。XSSが通った瞬間、攻撃者はユーザーに成りすましてAPIを叩けるため、フロントのセキュリティはXSS対策が最優先、次にCSRF、という順序になります。
XSS対策の本丸がCSP（Content Security Policy）です。ページで許可するスクリプト・スタイルの出所をブラウザに宣言する仕組みで、インラインスクリプト禁止の設定だけでXSS攻撃の大半を無力化できます。
Content-Security-Policy:
default-src 'self';
script-src 'self' https://trusted.cdn.com;
object-src 'none';既存ページに突然かけるとサイトが壊れるので段階的に入れますが、Next.jsやAstroはCSP用のnonceを自動付与してくれるため、モダンFWでの導入の敷居は大きく下がりました。CSRFはSameSite Cookie（Lax以上）+CSRFトークンの二重防御が定石です。
トークンの保管場所とリフレッシュ戦略
保管場所の安全性は、httpOnly Cookie（◎ JSから読めない）> メモリ（○ リロードで消える）> sessionStorage（△）> localStorage（× XSS一発で全員分漏洩）の順です。推奨構成は「短命のAccess Tokenをメモリ、長命のRefresh TokenをhttpOnly Cookie」の二層構えです。
リフレッシュは、Access Token（15分）が切れたらRefresh Token（30日、Cookie）で更新するのが標準パターンで、Refresh Token Rotation（使うたびに新しいトークンを発行し古いものを即無効化）を有効にすると、古いトークンの再利用＝盗難を検知してセッションを全失効できます。
ログアウトも地味に要です。「Cookie削除だけ」では足りず、サーバ側でRefresh Tokenを失効させる必要があります。盗難・紛失時の「全端末ログアウト」、パスワード変更後の全セッション自動失効も、重要度の高いサービスでは必須です。
認証設定の数値Gate
※ 2026年4月時点の業界標準値です。
「正しいデフォルト値」を曖昧にすると必ず穴が空きます。
| 設定項目 | 推奨値 |
|---|---|
| Access Token有効期限 | 15分 |
| Refresh Token有効期限 | 14〜30日+Rotation有効化 |
| Cookie属性 | HttpOnly+Secure+SameSite=Lax（三点セット必須） |
CSP script-src | ’self’+nonce（インライン禁止） |
| 認証失敗レート制限 | 5回 / 15分 |
Cookie三点セットはChrome DevToolsで即座に確認できる基礎チェックです。属性を一つ忘れるだけで終わるので、チェックリストで機械的に確認します。
3つのシナリオで考える
個人開発・スタートアップの場合
ClerkやAuth.js、Supabase Authに全て委譲してしまいましょう。トークンの保存やCookie属性、セッション管理といった間違えやすい部分をSDKが正しく処理してくれるため、自前でJWTをlocalStorageに置いてしまうような事故を構造的に回避できるのです。
中小SaaSの場合
Auth0やCognitoを使い、HttpOnly CookieとBFF経由でトークンを管理する構成が本命です。B2B契約ではSAMLやOIDC対応が求められることが多いため、IdPを選定する際に上位プランの条件を必ず確認しておいてください。Access Tokenは15分、Refresh TokenはRotation有効化という数値Gateも忘れずに守りたいところです。
大企業の場合
社内IdP（Entra IDやOkta）とのSSO統合が前提となります。フロント側では独自の認証状態を持たず、IdPのセッションに従属させる形です。CSPのnonce運用や全端末ログアウト、パスワード変更時の全セッション失効といったところまで、監査要件として設計に含める必要があります。
AI判断軸 ― SDKは正確、認可の置き場所は要注意
認証SDKの設定はAIが正確に書ける領域
Auth.js（NextAuth）やClerkのセットアップコードは、学習データに大量の実装例があるためAIが高精度で生成できます。providers 配列の設定、middleware.ts での保護パス指定、コールバックでのセッション拡張まで一気通貫で書けます。Passkey（WebAuthn）のフロント実装もRFC準拠の定型コードなので正確です。自前で認証を書かせるより、SDKのセットアップを書かせる方が安全かつ正確です。
AIは認可をフロントで完結させがち
AIが書いたフロント認証コードで問題になりやすいのは、「フロント側で認可判定を完結させてしまう」ケースです。if (user.role === 'admin') のような判定をフロントだけに書き、サーバ側のAPIには認可チェックがない状態をAIは作りがちです。「認可は必ずサーバ側で検証する」という原則をプロジェクトルールとして明示する必要があります。
やってはいけないこと
全ユーザー漏洩・成りすまし・セッション乗っ取りの直接原因を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| JWTをlocalStorageに保存 | XSS一発で全員分漏洩する → httpOnly Cookieにする |
フロントの role === 'admin' 分岐だけで認可 | F12で書き換え可能 → サーバ側で必ず権限チェックする |
| PKCEなしのOAuth / Implicit Flow | コード横取りで終わる → PKCE付きAuthorization Codeにする |
CSPに unsafe-inline を残す | XSS対策として機能しない → nonce方式に移行する |
| ログアウトでCookie削除のみ | サーバ側のRefresh Tokenが生き続ける → 失効APIを実装する |
| 認証を自前実装 | 穴だらけになる → Clerk / Auth.js / Auth0に委譲する |
2022年のOkta侵害・LastPass流出のように、セキュリティ専業企業すら侵入される現実があります。委譲した後も「委譲先のMFA・監査ログ・権限最小化」を運用側で監視するのが不可欠です。認証は書くな、借りろ、見張れの3点セットです。
筆者メモ ― 「見た目だけ守られている」が崩れた事例
2022年、SlackがGitHubに置いていた一部の従業員トークンが盗まれ、そのトークン経由で社内プライベートリポジトリの一部へアクセスされた事件が報じられました。仕組み自体は一般的なトークンベース認証で、コード上は正しく動いていた構成です。それでも保管場所と失効運用の甘さで突破されるという教訓として、いまも語り草になっています。
同年にはOktaのサポート委託先の端末が侵害され、SSOの大本である認証基盤が関連会社の端末経由で揺さぶられた事件もありました。いずれも「フロント側のコードは綺麗」「プロトコルも標準」という状況で起きています。認証はコードの正しさと運用の正しさの両輪で守るもので、片方だけでは必ず穴が残ります。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 認証方式（Cookie / JWT / 外部委譲）
- 認証基盤（Auth0 / Cognito / Firebase Auth / Clerk）
- Cookie属性の設定（HttpOnly / Secure / SameSite）
- CSPの導入方針（nonce方式・段階導入）
- トークン保管場所とRefresh戦略
- ログアウト・全端末失効の実装
この記事に関連する記事
まとめ
本記事はフロント認証認可について、ブラウザ前提のXSS/CSRF対策・Cookie属性・CSP・トークン保管・Refresh Token Rotation・外部基盤委譲まで含めて解説しました。如何だったでしょうか。
F12前提で守れる範囲を見極め、httpOnly Cookie+BFFを基本に置き、認証は外部基盤に委譲する。これが2026年のフロント認証設計の現実解です。
次回はSEO（検索エンジン最適化・OGP・サイトマップ・構造化データ）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（43/95）