セキュリティアーキテクチャ

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

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

本記事について

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

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

このカテゴリの他の記事

概要 ― 多層防御とゼロトラストの全体像 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-overview/認可とIAM ― 最小権限を貫く実務 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-iam/暗号化 ― 鍵管理が暗号の強度を決める ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-encryption/ネットワークセキュリティ ― 境界からゼロトラストへ ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-network/ゼロトラスト ― 何も信用せず常に検証する ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-zerotrust/秘密情報管理 ― ゼロ秘密化が最高の防御 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-secrets/脆弱性診断 ― CIに組み込み毎日検査する運用 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-vuln/

この記事の守備範囲

記事扱う範囲
本記事（認証設計）認証の3要素 / MFA / Passkey / パスワードポリシー / IDaaS / SSO
50/02 認可とIAMRBAC / ABAC / ReBAC / 最小権限 / IAM運用
20/07 認証・セッションサーバセッション vs JWT / OAuth実装 / Cookieサーバ設定
30/07 認証認可ブラウザ固有のXSS / CSRF / CSP / トークン保管場所

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

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

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

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

なぜ必要か

① なりすまし被害が甚大

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

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

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

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

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

認証の3要素

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

flowchart TB
    USER([ユーザー])
    KNOW["Something you know<br/>(知識)<br/>パスワード/PIN"]
    HAVE["Something you have<br/>(所持)<br/>スマホ/Key/IC"]
    BE["Something you are<br/>(生体)<br/>指紋/顔/虹彩"]
    SFA[1要素のみ = SFA<br/>弱い]
    MFA[2つ以上の組み合わせ = MFA<br/>桁違いに強い]
    USER --> KNOW
    USER --> HAVE
    USER --> BE
    KNOW --> SFA
    KNOW --> MFA
    HAVE --> MFA
    BE --> MFA
    classDef user fill:#fef3c7,stroke:#d97706;
    classDef factor fill:#dbeafe,stroke:#2563eb;
    classDef weak fill:#fee2e2,stroke:#dc2626;
    classDef strong fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
    class USER user;
    class KNOW,HAVE,BE factor;
    class SFA weak;
    class MFA strong;
要素意味例
Something you know知識パスワード・PIN・秘密の質問
Something you have所持スマホ・セキュリティキー・ICカード
Something you are生体指紋・顔認証・虹彩

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

パスワードの限界

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

問題内容
弱いパスワードpassword123 が上位常連
使い回し他サイトの漏洩で連鎖的に突破される
フィッシング偽サイトに入力してしまう
ブルートフォース総当たりで突破
漏洩リスト攻撃Credential Stuffing（他サイトで漏れたID/パスを使い回しで突破する手口）

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

多要素認証（MFA）

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

手段強度備考
SMS コード低SIM乗っ取り・盗聴リスクあり
TOTP（Google Authenticator等）中アプリでコード生成・広く普及
Push通知（Okta Verify等）中タップ1つ・人気
FIDO2 / WebAuthn（公開鍵暗号でフィッシングできない認証規格）最強フィッシング耐性・パスワードレス可
ハードウェアキー（YubiKey）最強物理的に奪わない限り安全

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

パスワードレス認証

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

メリットデメリット
フィッシング耐性対応デバイスが必要
ユーザー体験が良い古いシステムと相性悪い
パスワード管理不要生体漏洩時の扱いが難しい
漏洩リストで突破不可復旧手順の設計が複雑

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

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

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

プロトコル用途
SAML 2.0エンタープライズ古参・XMLベース
OAuth 2.0認可のプロトコル（認証ではない）
OpenID Connect（OIDC）OAuth 2.0上の認証拡張・現代主流
KerberosWindows AD（Active Directory、MSの認証基盤）社内環境

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

ソーシャルログイン

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

プロバイダ向くサービス
Google幅広い・最も普及
AppleiOSアプリは必須（App Store ルール）
MicrosoftB2B・企業向け
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行で選んで、成長したら見直せば十分です。

サービス特徴向くケース
Auth0機能最強・B2B/B2C両対応本格システム
Okta業界標準・エンタープライズ大企業・SSO中心
Firebase AuthGoogle・安価モバイル・小規模
Supabase AuthOSS・PostgreSQL統合スタートアップ
Azure AD B2CMicrosoft・低コストB2C・MS系企業
AWS CognitoAWS統合AWS使用企業

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

判断基準

① サービスの種類

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

サービス種別推奨認証
B2C・小規模ソーシャルログイン + オプションMFA
B2C・金銭扱うMFA必須（TOTP / Push）
B2B 業務システムSSO + MFA必須
金融・医療・政府系FIDO2 + ハードウェアキー + 多層認証

② ユーザー層

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

ユーザー層推奨
一般消費者（幅広い年齢）SMS + アプリの選択式
企業ユーザー（ITリテラシー高め）TOTP / Push / FIDO2
エンジニア・開発者FIDO2 + ハードウェアキー
高齢者・非IT層SMS + サポート体制重視

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

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

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

サービス種別ユーザー層推奨認証必須MFAパスワード強度
B2C・無料サービス一般消費者パスワード + ソーシャルログインオプション12文字以上
B2C・金銭扱う（EC・銀行）一般消費者MFA必須 + Passkey推奨TOTP / Push14文字 + 漏洩検知
B2B業務SaaS企業ユーザーSSO + MFA必須TOTP / Push / FIDO212文字 + 定期
金融・医療・政府系限定FIDO2 + ハードウェアキーFIDO2必須16文字 + 監査
管理者アカウント内部FIDO2 + ハードウェアキー（YubiKey等）必須長いパスフレーズ
AIエージェント用機械Service Account + 短命トークン—API Keyは避ける

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

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

認証設計の鬼門・禁じ手

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

禁じ手なぜダメか
認証を自作（bcrypt + Cookieセッション等）パスワードリセット経路・セッション固定攻撃・タイミング攻撃…10以上の観点を漏れる
SMSだけをMFAとして採用2019年のTwitter CEO Jack Dorsey氏SIMスワップ事件のように、10分で突破される
MFA疲れ攻撃への対策なし2022年のUber社内侵害はMFA疲れで突破。FIDO2 / Passkeyのフィッシング耐性が必須
パスワード定期変更を強制NIST 2017年以降非推奨。弱いパスワードを生むだけ。漏洩時のみ変更
パスワードをSHA-256単独でハッシュGPUで総当たり突破。Argon2id / bcrypt cost 12以上 必須
Access Tokenを30日以上有効漏洩時の被害が長引く。15分 + Refresh Tokenが鉄則
退職者の認証情報を即座に停止しない2019年米大手銀行の内部不正事例。退職処理チェックリストにIAM/IdP削除必須
OAuth Implicit Flowを新規実装2020年以降非推奨。PKCE付きAuthorization Code必須
永続API Keyをアプリに埋め込みGit誤コミットで即漏洩。短命トークン + Service Accountへ
AIエージェントに人間と同じ権限を付与高速大量操作で被害拡大。エージェント用に絞り込んだ専用アカウント

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

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

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用が前提になると、認証は人間 + AIエージェントの両方を想定する必要があります。AIエージェントが自律的にシステムを操作する時代には、エージェント用の認証（Service Account・API Key・OAuth Client Credentials）の設計が重要になります。

AI時代に有利AI時代に不利
IDaaS（Auth0・Okta・Firebase）自作認証
パスキー（FIDO2）パスワード中心
OAuth 2.0 + OIDC独自プロトコル
エージェント用の短命トークン永続API Key

AIエージェントには短命のトークンを発行し、用途・権限を厳密に絞るのがAI時代の認証設計です。AIが使うAPI Keyが漏洩すると、AI経由で全業務が乗っ取られるというリスクを忘れてはいけません。

AI時代の認証は「人間と機械の両方」を設計。エージェント用の認証は短命・限定が鉄則です。

よくある勘違い

  • パスワード定期変更すれば安全 → NISTは「定期変更を非推奨」に転換しました。漏洩時のみ変更するのが正解。無駄な変更はむしろ弱いパスワードを生む
  • SMS認証があればMFAとして十分 → SMSはSIMスワップ（携帯キャリアを騙してSIMを乗っ取る攻撃）で10分程度で突破される事例が実際に多数報告されています。2019年にはTwitter CEOのジャック・ドーシー氏のアカウントがSIMスワップで乗っ取られる事件まで起きました。TOTP以上を選びます
  • 認証は自作できる → できますが、セキュリティ穴を埋めるコストが膨大です。現代ではIDaaSを使うのが常識です
  • MFAを入れたから安心 → MFA疲れ攻撃・フィッシング耐性のないMFAは突破されます。FIDO2が真の解です

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

認証の自作で痛い目を見たという話が、業界ではよく語り草になっています。ある社内ツールで「認証くらい自分で書けた方が勉強になる」という動機で 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）

最終的な判断の仕方

認証設計の核心は認証の強度がシステム全体のセキュリティ上限を決めるという認識です。認証が突破されればその先の認可・暗号化は全て無意味になります。パスワード単独で守る時代は終わり、MFA標準・パスキー推奨・IDaaS活用の三点セットが現代の最低ラインで、SMS認証はSIM乗っ取り対策として避けます。扱うデータの機微度とユーザーのITリテラシーで強度を調整し、金融・医療はFIDO2 + ハードウェアキーまで、一般B2CはTOTP + Passkey推奨まで、段階的に合わせるのが合理的な判断です。

もう一つの決定的な軸は人間とAIエージェントの両方を認証対象として設計することです。AIが自律的に業務を実行する時代、エージェント用の認証（Service Account / OAuth Client Credentials）が重要な設計ポイントになり、永続API Keyはリスクの塊になります。短命トークン + 用途・権限の厳密な絞り込みが、AI時代の認証設計の鉄則です。

選定の優先順位

  1. IDaaSに委譲 — 自作認証はほぼ非推奨、Auth0 / Okta / Firebase Authを使う
  2. MFA標準 + パスキー対応 — SMSは避け、TOTP / Passkeyを推奨
  3. SSO + OIDCを採用 — エンタープライズはSSO必須で、標準プロトコルで組み立てる
  4. エージェント用認証は短命・限定 — 永続API Keyを避け、OAuth Client Credentials + 短命トークン

「認証は自作せず委譲、人間とAI両方を設計する」IDaaS + Passkey + 短命トークンが現代の標準形です。

まとめ

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

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

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

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

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

📚 シリーズ：生成AI時代のアーキテクチャ超入門（47/89）

← 概要 ― 多層防御とゼロトラストの全体像 ― 生成AI時代のアーキテクチャ超入門 認可とIAM ― 最小権限を貫く実務 ― 生成AI時代のアーキテクチャ超入門 →
← 記事一覧に戻る

関連記事

暗号化 ― 鍵管理が暗号の強度を決める ― 生成AI時代のアーキテクチャ超入門
セキュリティアーキテクチャ

暗号化 ― 鍵管理が暗号の強度を決める ― 生成AI時代のアーキテクチャ超入門
認可とIAM ― 最小権限を貫く実務 ― 生成AI時代のアーキテクチャ超入門
セキュリティアーキテクチャ

認可とIAM ― 最小権限を貫く実務 ― 生成AI時代のアーキテクチャ超入門
ネットワークセキュリティ ― 境界からゼロトラストへ ― 生成AI時代のアーキテクチャ超入門
セキュリティアーキテクチャ

ネットワークセキュリティ ― 境界からゼロトラストへ ― 生成AI時代のアーキテクチャ超入門
概要 ― 多層防御とゼロトラストの全体像 ― 生成AI時代のアーキテクチャ超入門
セキュリティアーキテクチャ

概要 ― 多層防御とゼロトラストの全体像 ― 生成AI時代のアーキテクチャ超入門