【モダンアプリシリーズ】Webアプリ認証の全体像の社内勉強会を開催しました
こんにちは。クラウド事業統括本部 モダンアプリコンサルティングチームの北野です。
私が現在所属しているモダンアプリケーション開発支援を担当するMACチーム主催で、開発関連の技術勉強会を定期的に開催しています。
2026/06/15に、社内で「今更聞けない認証入門」というテーマで勉強会を開催しました。今回はその資料と内容を紹介します。
資料
発表資料はこちらです。
勉強会の目的
最近はAIエージェントを活用してWebシステムを開発する機会が増えていますが、認証機能そのものの判断基準は依然としてエンジニア自身が持っておく必要があります。この勉強会では、次のことを持ち帰ってもらうことを目的にしました。
- ライブラリの使い方ではなく、判断基準を持ち帰る
- 細かいプロトコルの詳細より、位置づけを優先する
- 前提（構成）が変わると、認証の「正解」も変わることを理解する
「認証」という言葉は範囲が広く、セッション・JWT・OAuth・SAML・パスキーなど個別の技術トピックとして語られがちです。今回はそれらを1つの地図の上に並べ直し、「認証とは何か」というメタな概念と、「状態維持」「手段」「委譲」という3つの実装観点に整理して説明しました。
内容の概要
資料は全9章構成です。
第1章 認証とは何か
認証（Authentication）と認可（Authorization）の違いを確認し、「認証」を1語で語らずメタ概念（認証とは何か）と実装の3観点（状態維持・手段・委譲）に切り分ける、という今回の資料全体の地図を示しました。
第2章 [状態維持] Webブラウザの状態維持
HTTPは本来ステートレスであることのおさらいから、Cookie・セッションの仕組み、セッションストアの選択肢（メモリ/RDB/Redis等）を解説しました。Cookieの重要属性であるSecure・HttpOnly・SameSite・Domainや、セッションハイジャック・セッション固定攻撃・CSRFといった代表的な攻撃と対策も扱っています。
第3章 [状態維持] トークン認証 / JWT
セッションDBを持つことの弱点から、JWTという選択肢へどう発想が転換するかを説明しました。JWTの構造と検証方法、アクセストークンとリフレッシュトークンの役割分担、リフレッシュトークンのローテーションを取り上げています。
SPA + APIの構成ではトークンをlocalStorageとCookieのどちらに保存するかがよく議論になりますが、これは単なる保存場所の選択ではなく、BFF（Backend For Frontend）の有無というインフラ構成の選択に直結する話であることを説明しました。あわせて、Next.jsが「BFF付きSPA」になれるハイブリッド構成であること、セッションIDの代わりにJWTを使うアンチパターン、ログアウト設計の考え方にも触れています。
第4章 [手段] 認証の3要素
知識（Something you know）・所有（Something you have）・生体（Something you are）という認証の3要素と、なぜ多要素認証（MFA）では異なる要素を重ねる必要があるのかを解説しました。
第5章 [手段] パスワード
パスワードを平文で保存してはいけない理由と、ハッシュ・ソルト・ストレッチングの仕組みを説明しました。アルゴリズムはArgon2idを第一候補として紹介しています。
第6章 [手段] 多要素認証（MFA）& パスキー
TOTP・SMS・プッシュ通知承認・パスキーといったMFA手段を比較し、SMSのリスクやWebAuthn（パスキー）の仕組みを解説しました。あわせて、パスワードリセットの経路が認証の「裏口」になりやすいという落とし穴も取り上げています。
第7章 [委譲] ソーシャルログイン & SSO
認証の手段を自前で持たず外部のIdP（Identity Provider）に委譲する、という考え方を説明しました。OIDCで登場するIDトークン・アクセストークン・リフレッシュトークンの役割の違い、OAuth 2.0とOIDCが別物であること、SSOの仕組み、OIDCとSAMLの違い、委譲は連鎖できる（フェデレーション）ことを取り上げています。
第8章 実装の選択肢
認証ロジックは自作せず、IDaaSを使うのが基本路線であることを説明しました。ただし、IDaaSを選んで終わりではなく、IDaaS連携・状態維持・ルート保護を担う「つなぎ役」のライブラリが別途必要になることや、フルスタック系フレームワークとSPA向けSDKで守備範囲が異なることも取り上げています。IDaaSの選び方として、シンプルな認証ならAmazon Cognito、SSOや多機能が必要ならAuth0、大規模B2C・会員統合ならfannaly auth（※これは宣伝です）を紹介しました。
第9章 まとめ
認証を「状態維持」「手段」「委譲」の3観点で振り返り、最初に選んだ構成（SSR / SPA + BFF / SPA + 外部APIなど）によって状態維持のデフォルトがほぼ自動的に決まる、という判断基準の表で締めくくりました。
最後に
「認証」という一言でまとめられがちなテーマを、状態維持・手段・委譲という3つの観点に分解して整理することで、個別の技術トピックの位置づけが見えやすくなったのではないかと思います。AIエージェントを活用して開発を進める場面が増えても、認証方式を選ぶ判断基準そのものはエンジニアが持っておくべき知識です。このブログがどなたかのお役に立てれば幸いです。
