認証の現代：パスキー、OIDC、セッション - 真の短いリスト

セキュリティと信頼 Jul 11, 2026 at 17:195ブックマークに追加

人気のHNスレッドが再び問いかける：2026年にアプリをどのように認証すべきか？もはや答えは「JWT + リフレッシュトークン」ではない。整理された概観。

簡単に言うと

2026年には、Webアプリケーションの「正しい」認証方法は2つの質問で決まります：(1) B2Cの一般消費者向けアプリか、それともB2BのSaaSか？ (2) 独自のIdP（アイデンティティプロバイダー）を運用する準備ができているか、それともプロバイダーに委ねるか？ 2020年代中期のパターン（JWTステートレス + localStorageでのリフレッシュ）は、正当な理由により時代遅れとなっています。

事の顛末

HNのスレッドでは古典的な議論が繰り広げられ、興味深い収束点に達しました。ほとんどのアプリにとって、2026年の実用的なスタックは次のとおりです：

暗号化されたサーバーサイドセッション（HttpOnly + SameSite=LaxのCookie）で認証状態を管理。クライアント側にJWTを保存するのは終わりです。
OIDC（Google/Apple/GitHub）でパスワードレスのオンボーディング。
Passkeys（WebAuthn）を2段階目またはパスワード完全置換に使用。iOS 17+、Android 13+、すべての主要ブラウザでついに普及しました。
サーバーサイドセッションの短いローテーション（約1時間） + 長いリフレッシュ（約14日間）を別のCookieで管理。
マルチテナントの真のステートレス処理がない限り、クライアント側のJWTは不要。

構造的に変化したのは3つのポイントです。1つ目：機密トークンのlocalStorage廃止（XSSによる完全な侵害リスクがあるため、もはや議論の余地なし）。2つ目：Passkeysの成熟 - Google、Apple、Microsoftを含む主要エコシステムで普及率が臨界点を超えました（詳細な数字は公開されていませんが）。3つ目：Clerk、WorkOS、Auth0などのIdPホスティングサービスが、SSO/SCIM/Passkeysをオールインワンで提供しており、5人未満のチームが再実装するメリットはありません。

技術的詳細

セッションCookie：Secure; HttpOnly; SameSite=Lax; __Host-プレフィックス。権限昇格時に毎回ローテーション。
CSRF：SameSite=Laxで95%のケースをカバー。機密ミューテーションにはCSRFトークンを追加。
PKCE：すべての公開OAuthフロー（SPA、モバイル）で必須。
よくある罠：Passkeyを早期に2FAとして「必須」に設定すると、ユーザーが1台のデバイスしか持っていない場合にアカウントを失うリスクあり。
流行中の脆弱性：ブラウザ拡張機能がSPAのメモリを読み取る - localStorageに何も保存しないというさらなる根拠。

結論

3つのポイントにまとめられます。1つ目：2026年に新規で始める場合、規制上の理由がない限りプロバイダー（Clerk、WorkOS、Stack Auth）を選択。エンジニアリングの時間を節約し、製品開発に注力できます。2つ目：JWT-in-localStorageのレガシースタックをお持ちの場合、サーバーセッションCookieへの移行計画を立てましょう。これは見た目の問題ではなく、セキュリティ上の優先事項です。3つ目：Passkeysは実用段階にあります。現在はオプションとして有効化し、2027年までにエンタープライズで義務化することを検討。注目すべきは、Passkeysのマルチプラットフォーム標準化（B2Bの真の障壁）。