認証設計 ― IDaaS+Passkey+短命トークンの基本 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第2弾として、認証設計について解説する記事です。

認証は全アクセスの最初の関門で、ここが抜かれると他の防御が無意味になります。パスワード時代は事実上終わり、2026年現在は Passkey（FIDO2のパスワードレス認証）が本命です。本記事では認証の3要素・パスワード/MFA/Passkey・SSO・ソーシャルログイン・IDaaSといった認証方式の選定を扱い、セッション管理はソフトウェア章、ブラウザ防御はフロント章に委ねます。

本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』・『安全なWebアプリケーションの作り方 第2版』も参考にしてみてください。

そもそも認証とは何か

認証とは、ざっくり言えば「この人は本当に本人か？を確かめる仕組み」です。

オフィスビルの入口を想像してください。受付で社員証を見せて本人確認し、ゲートが開く──これが認証です。社員証だけでなく、顔認証や暗証番号を組み合わせれば、他人が社員証を拾っても入れません。デジタルの世界でも同じで、パスワード（知識）・スマホ（所持）・指紋（生体）を組み合わせて本人確認の精度を上げるのが現代の認証設計です。

この記事の守備範囲

本記事の問いは「どうやって本人と確かめるか」確かめたあとの持ち運びは別章で扱います。

入口が破られれば、家の中の全てが無意味になる

認証が突破されると、その先のアクセス制御は一切機能しません。認証の強度がシステム全体のセキュリティ上限を決めるため、最も入念に設計すべき領域です。パスワードだけでは突破される時代になり、多要素認証（MFA）が事実上の標準になっています。2022年のLastPass流出（暗号化されたパスワード金庫が大量に奪われた事件）や、同年のOktaサプライチェーン侵害は、認証基盤への攻撃が現実のリスクであることを示しました。

認証が弱いと全てのセキュリティ対策が無意味になります。ここは妥協できません。

なぜ必要か

① なりすまし被害が甚大

認証が突破されると、攻撃者は正規ユーザーとして振る舞えます。データ流出・金銭被害・他システムへの踏み台化まで可能で、一瞬で企業を沈める威力があります。

② パスワードだけでは守れない時代

フィッシング・情報漏洩・総当たり──パスワード単独で守る時代は終わりました。MFAなしは事実上無防備と言える状況です。

③ ユーザー体験との綱引き

強い認証はユーザーの手間を増やします。セキュリティと使い勝手のバランスを適切に取らないと、ユーザーが避けて回避策を使い始めます。

認証の3要素

認証は「何を根拠に本人と確認するか」で3つの要素に分類されます。MFAは異なる要素を組み合わせることで、1つが漏れても他が守る仕組みです。同じ要素2つ（パスワード + 秘密の質問）はMFAではない点に注意が必要です。

MFA ＝ 上記のうち2つ以上を組み合わせることで、1要素だけの認証（SFA）より桁違いに強くなります。

パスワードの限界

パスワード認証は古くからある方式ですが、現代では単独利用は非推奨です。理由は「ユーザーが弱いパスワードを使う」「使い回す」「フィッシングで抜かれる」──これらの人間的弱点を技術で埋められないからです。

NIST（米国国立標準技術研究所、米国のセキュリティ標準を作る組織）のガイドライン（SP 800-63B）では、定期変更の強制は非推奨に変わり、「長さ重視・漏洩時のみ変更」が推奨です。パスワードは「長さ・漏洩検知・MFA併用」が現代の基本です。

多要素認証（MFA）

異なる要素を2つ以上使う認証方式で、単独のパスワード認証より99.9%攻撃をブロックできるとMicrosoftのデータで示されています。主要な MFA 手段は以下です。

SMSは弱いため、企業向けシステムでは避けるべきです。本気で守るならFIDO2 / WebAuthn + ハードウェアキーが最強の組み合わせです。

パスワードレス認証

パスワードを完全に排除し、FIDO2 / WebAuthn + 生体認証だけで認証する方式です。Windows Hello・Apple Face ID・Google パスキー等で普及が進んでおり、パスワードが存在しないためフィッシング不可能という根本的なセキュリティ向上をもたらします。

2024年以降、主要サービスで「パスキー」が標準化しており、新規構築では最初からパスキー対応を前提にするべきです。

シングルサインオン（SSO）

SSO は、1回の認証で複数のサービスにログインできる仕組みです。業務で Google Workspace・Slack・GitHub・Salesforce 等を使う組織では、アカウントを一元管理できるのが最大の利点で、退職者のアカウント停止も IdP 側で1箇所停止すれば終わります。

SSOを導入する組織は、IdPとしてOkta・Azure AD（Entra ID）・Google Workspace などを中心に据え、そこから各サービスへSAML/OIDCで連携させるのが定石です。

ソーシャルログイン

Google・Apple・GitHub・LINE等のアカウントを使って、自社サービスにログインさせる方式です。ユーザーは新規登録不要で、コンバージョン率が数倍に上がるという効果があります。B2Cサービスでは事実上の標準です。

AppleはiOSアプリで他ソーシャルログインを提供するなら併設必須というルールがあります。実装は Auth0・Firebase Auth・Supabase Auth 等のIDaaSを使うと数十行で済みます。

IDaaS（認証のSaaS）

IDaaS は認証機能を「SaaSとして提供」するサービスで、自社で認証基盤を構築するコスト・リスクを削減します。パスワード保存・MFA・ソーシャルログイン・SSO・パスキー対応──これらを自社実装すると数人月、IDaaSなら数日で導入できます。

規模別のざっくり判定：個人開発・小規模スタートアップなら Supabase Auth / Firebase Auth、B2B SaaSなら Auth0 / Clerk、大企業・SSO中心なら Okta / Entra ID、AWS中心なら Cognito。この3行で選んで、成長したら見直せば十分です。

認証を自作するのは現代ではほぼ非推奨です。セキュリティ専門家以外が作ると穴だらけになります。

判断基準

① サービスの種類

認証の厳しさは扱うデータの機微度で決めます。ECサイトと医療システムでは必要な認証強度が違います。

② ユーザー層

ユーザーの IT リテラシーによっても選択が変わります。高齢者向けサービスで FIDO2 を強制すると誰もログインできなくなります。

認証強度×サービス種別の実務段階表

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

認証強度は扱うデータの機微度 × ユーザー層のITリテラシーで決まります。下記が実務での対応表です。

「Microsoft の研究データでは、MFAを有効化するだけで99.9%の自動化攻撃をブロックできる」ことが示されています。SMSは SIMスワップで突破されるため企業向けでは避け、TOTP / FIDO2 / Passkeyを標準にするのが現代の鉄板です。

MFA未導入は論外。最低でもTOTP、新規はPasskey対応を前提に設計します。

やってはいけないこと

認証領域で事故る典型パターンを整理します。どれもなりすまし・企業存続レベルの損害に直結します。

2022年Uber社内侵害（請負業者パスワード漏洩 + MFA疲れ攻撃で社内Slack・AWS・GCPまで到達）、2019年Twitter CEO SIMスワップ事件、2022年 Okta / LastPass 侵害——認証領域の事故は年々巧妙化しており、「MFA入れれば安心」は過去の話です。

認証は自作せず外部委譲 + Passkey + 短命トークン。3点セットで事故率が激減します。

AI判断軸

AIエージェントの認証をどう設計するか

AI時代の認証設計で最も大きな変化は、人間だけでなくAIエージェントが正規のアクターとしてAPIを叩くようになっていることです。GitHub Copilot がコードを書き、Devin がPRを出し、カスタムAIエージェントがSlack経由で社内システムを操作する──こうしたエージェントに「どの権限で、どこまで許すか」は、従来の認証設計にはなかった課題です。

従来の Machine-to-Machine 認証（バッチ処理・マイクロサービス間通信）は決まった処理を繰り返すだけでした。AIエージェントは自律的に判断して異なるAPIを叩きます。そのため従来の固定スコープでは権限が広すぎるか狭すぎるかのどちらかになり、設計の考え方自体を変える必要があります。

エージェント認証の設計パターン

「エージェントに永続API Keyを渡して終わり」は非常に危険です。永続キーは漏洩リスクが時間とともに蓄積しますし、エージェントの行動範囲も制限できません。短命トークン + 最小スコープ + 操作ログの3点は必須です。

エージェント操作の監査証跡

AIエージェントが行った操作は、「誰の指示で、何の目的で、いつ実行されたか」を完全にトレースできなければなりません。人間の操作は「ログインユーザーID」で追えますが、エージェントの場合はそれだけでは足りず、以下を記録します。

• エージェントID（どのエージェントか）
• 委譲元ユーザー（誰の代理か。On-behalf-of の場合）
• トリガー（何がきっかけで実行されたか。Slack メッセージ・スケジュール・別エージェントからの呼び出し等）
• 実行コンテキスト（プロンプト要約・判断根拠）

これは将来のコンプライアンス要件（EU AI Act等）で必須になる見込みですが、後から追加するのは困難です。設計段階で組み込んでおかないと、運用開始後にログ構造を変えるのは現実的ではありません。

人間 + エージェントの認証判断フロー

選定の優先順位

1. IDaaSに委譲 — 自作認証はほぼ非推奨、Auth0 / Okta / Firebase Authを使う
2. MFA標準 + パスキー対応 — SMSは避け、TOTP / Passkeyを推奨
3. SSO + OIDCを採用 — エンタープライズはSSO必須で、標準プロトコルで組み立てる
4. エージェント用認証は短命・限定 — 永続API Keyを避け、OAuth Client Credentials + 短命トークン + DPoP検討
5. エージェント操作の監査ログを設計段階で組み込む — 後付けは困難。「誰の代理で・何をしたか」を全て追跡可能にしておく

筆者メモ — 「認証くらい自作できる」の罠

認証の自作で痛い目を見たという話が、業界ではよく語り草になっています。ある社内ツールで「認証くらい自分で書けた方が勉強になる」という動機で bcrypt + Cookie セッションを素朴に組んだところ、リリース直前のセキュリティレビューで、パスワードリセット経路・ブルートフォース対策・セッション固定攻撃・タイミング攻撃・アカウントロックアウト…と、思いつきもしなかった観点を10個以上指摘され、丸ごと書き直す羽目になった、という事例は少なくありません。

もう一つ有名なのが2022年のUber社内侵害事件で、請負業者のパスワードが漏れた上に「MFA疲れ攻撃」（MFA通知を大量に送りつけ、ユーザーが根負けして承認するのを狙う手法）が刺さり、攻撃者が社内Slack・AWS・GCPまで到達しました。「MFAさえ入れれば安全」という思い込みが崩れた分かりやすい事例で、FIDO2 / Passkeyのフィッシング耐性の重要性が一気に広まるきっかけになりました。

筆者も新人時代に「認証くらい書けそう」と思って一度手を出しかけて、先輩に「絶対に自作するな」と止められた記憶があります。「認証はCRUDの親戚くらいの感覚で作れる」というのは書いた本人だけがそう思っている錯覚で、「自作で学べるのは自作してはいけないという教訓だけ」と言われる所以です。

自作認証は動くと守れるの間に大きな溝がある。溝に気づいた頃には本番が動いています。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• 認証方式（パスワード / MFA / パスキー / SSO）
• MFA手段（SMS / TOTP / Push / FIDO2）
• IDaaSの採用（Auth0 / Okta / Firebase / 自作）
• ソーシャルログイン（対応範囲）
• セッション設計（Cookie / JWT / リフレッシュ）
• パスワードポリシー（長さ・漏洩検知）
• エージェント認証（Service Account・API Key）

決定理由の残し方

認証基盤はセキュリティとユーザー体験の両方に影響するため、なぜその方式・製品を選んだかをADRとして残すことが重要です。以下に具体例を示します。

認証方式の変更は全ユーザーに影響するため、後任者が「なぜ自前実装ではなくIDaaSなのか」を理解できる状態にしておく必要があります。後から見返したとき「なぜこの選択をしたか」が一目でわかることが、ADR の最大の価値です。

この記事に関連する記事

https://senkohome.com/arch-intro-security-zerotrust/ https://senkohome.com/arch-intro-index-security/ https://senkohome.com/arch-intro-security-iam/

まとめ

本記事は認証設計について、認証3要素・MFA・Passkey・SSO・ソーシャルログイン・IDaaS選定・人間とAIエージェントの両方を視野に入れた現代の認証設計まで含めて解説しました。如何だったでしょうか。

IDaaSに委譲し、MFA標準+Passkey対応、SSO+OIDCを採用し、エージェント用認証は短命・限定にする。これが2026年の認証設計の現実解です。

次回は認可とIAM（RBAC・ABAC・ReBAC・最小権限）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は AWS Amazon Cognito も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。