OAuth/OIDC/FIDO2認証技術比較【2026年版】

パスワード管理
2026.03.18

※本記事にはアフィリエイトリンクが含まれます。詳しくはプライバシーポリシー・広告掲載についてをご覧ください。

※ 本記事には広告リンクが含まれます。

「ログイン」という一見シンプルな操作の裏側には、複数の標準プロトコルが組み合わさって動いています。OAuth2.0・OIDC・SAML・FIDO2・パスキー・MFA——それぞれの違いを理解せずにシステム設計を進めると、セキュリティホールや過剰な実装コストに直結します。本記事では各技術の仕組み・シーケンス・実装ポイントを体系的に整理します。

認証（Authentication）と認可（Authorization）の違い

まず基礎の確認から。混同されやすい2つの概念です。

概念英語問いかけ例
認証Authentication (AuthN)あなたは誰ですか？ログイン確認
認可Authorization (AuthZ)あなたは何をできますか？リソースへのアクセス権限付与

OAuth2.0 は認可フレームワーク、OIDC はその上に認証を追加した仕様です。この区別が後述の理解に直結します。

OAuth2.0：認可フレームワークの標準

OAuth2.0（RFC 6749）は「リソースオーナーの代わりにサードパーティアプリケーションが保護されたリソースへアクセスする」ための認可フレームワークです。パスワードを渡さずにアクセス権限を委譲できます。

主要な登場人物

  • Resource Owner：ユーザー本人（保護リソースの所有者）
  • Client：アクセスを求めるアプリケーション
  • Authorization Server：認可を行いトークンを発行するサーバ
  • Resource Server：APIなど保護されたリソースを提供するサーバ

Authorization Code フロー（推奨）


[ユーザー]
   │  ① ログインボタンクリック
   ▼
[Client App]
   │  ② /authorize?response_type=code&client_id=xxx&redirect_uri=xxx&scope=xxx&state=xxx
   ▼
[Authorization Server]  ←  ユーザーが認証・同意
   │  ③ 認可コード(code) を redirect_uri へ返却
   ▼
[Client App]
   │  ④ code + client_secret を POST /token へ送信
   ▼
[Authorization Server]
   │  ⑤ access_token + refresh_token を返却
   ▼
[Client App]
   │  ⑥ Authorization: Bearer {access_token} でAPIコール
   ▼
[Resource Server]  →  レスポンス返却

PKCEを組み合わせることで、SPAやモバイルアプリなどクライアントシークレットを安全に保持できない環境でもセキュアに利用できます。

実装例（Python / requests）


import secrets, hashlib, base64, requests

# PKCE: code_verifier と code_challenge 生成
code_verifier = secrets.token_urlsafe(64)
code_challenge = base64.urlsafe_b64encode(
    hashlib.sha256(code_verifier.encode()).digest()
).rstrip(b"=").decode()

# ① 認可リクエスト URL 構築
auth_url = (
    "https://auth.example.com/authorize"
    f"?response_type=code&client_id=MY_CLIENT_ID"
    f"&redirect_uri=https://app.example.com/callback"
    f"&scope=openid+profile&state={secrets.token_urlsafe(16)}"
    f"&code_challenge={code_challenge}&code_challenge_method=S256"
)

# ④ トークンエンドポイントへ code を交換
resp = requests.post("https://auth.example.com/token", data={
    "grant_type": "authorization_code",
    "code": "RECEIVED_CODE",
    "redirect_uri": "https://app.example.com/callback",
    "client_id": "MY_CLIENT_ID",
    "code_verifier": code_verifier,
})
tokens = resp.json()  # access_token, id_token, refresh_token

OIDC（OpenID Connect）：OAuth2.0の上に認証を追加

OIDC は OAuth2.0 拡張仕様（OpenID Connect Core 1.0）で、アクセストークンに加えてID トークン（JWT）を発行します。これにより「誰がログインしているか」という認証情報を標準化された形で取得できます。

ID トークン（JWT）の構造


// JWT ヘッダー
{ "alg": "RS256", "typ": "JWT", "kid": "key-id-2026" }

// ペイロード（クレーム）
{
  "iss": "https://auth.example.com",    // 発行者
  "sub": "user_12345",                   // ユーザー識別子
  "aud": "MY_CLIENT_ID",                 // 対象クライアント
  "exp": 1742300000,                     // 有効期限（Unix時間）
  "iat": 1742296400,                     // 発行時刻
  "email": "user@example.com",
  "name": "山田 太郎"
}

クライアントは JWT の署名を Authorization Server の公開鍵（JWKS エンドポイント）で検証することで、トークンの改ざんを検知できます。

OIDCを使うべき場面

  • SSOを自前で実装する場合（Google / GitHub ログインなど）
  • マイクロサービス間でユーザーコンテキストを伝播する場合
  • セッション管理をステートレスに保ちたい場合

SAML 2.0：エンタープライズ SSO の定番

SAML（Security Assertion Markup Language）2.0 は XML ベースの認証・認可フレームワークです。OIDC が登場する前から企業向け SSO の標準として広く普及しており、Active Directory・Okta・Azure AD との連携で今も現役です。

SAML SP-initiated フロー


[ユーザー]
   │  ① 業務アプリ（SP）にアクセス
   ▼
[Service Provider (SP)]
   │  ② 認証要求（SAMLRequest）を生成 → IdP にリダイレクト
   ▼
[Identity Provider (IdP)]  ←  ユーザーが認証（パスワード / MFA）
   │  ③ 署名付き SAML Assertion（XML）を POST でSPへ返却
   ▼
[Service Provider (SP)]
   │  ④ Assertion を検証 → セッション確立
   ▼
[ユーザー]  → 業務アプリ利用開始

SAML vs OIDC 選択基準

観点SAML 2.0OIDC
データ形式XML（重い）JSON/JWT（軽量）
エンタープライズ連携◎ AD・Okta・Azure AD○ 増加中
モバイル/SPA対応△ リダイレクト制約あり◎ PKCE対応
新規開発での推奨既存システム連携時◎ 優先推奨

FIDO2 / パスキー：パスワードレス認証の本命

FIDO2（WebAuthn + CTAP2）は、パスワードを使わず公開鍵暗号で認証する標準です。パスキーはFIDO2の実装形態の一つで、iCloud Keychain・Google Password Manager などを通じてデバイス間同期が可能です。

WebAuthn 認証シーケンス


【登録フェーズ】
[サーバ]  → challenge（ランダム値）を生成 → クライアントへ送信
[クライアント / 認証器]
  ・公開鍵ペアを生成（秘密鍵はデバイス内 / クラウド保管）
  ・challenge に秘密鍵で署名
  ・公開鍵 + credentialId + attestation をサーバへ送信
[サーバ]  → 公開鍵を DB に保存

【認証フェーズ】
[サーバ]  → challenge を生成 → クライアントへ送信
[クライアント / 認証器]  → 指紋 / FaceID でローカル認証
  ・秘密鍵で challenge に署名 → assertion をサーバへ送信
[サーバ]  → 保存済み公開鍵で署名検証 → 認証成功

秘密鍵がサーバに送信されることは一切ありません。フィッシング耐性が極めて高く、パスワードリスト攻撃も無効化されます。詳細は当サイトのパスキー完全ガイドもご参照ください。

WebAuthn 実装例（JavaScript）


// 認証フェーズ（ブラウザ側）
async function authenticate() {
  // サーバから challenge 取得
  const { challenge, allowCredentials } = await fetchAuthOptions();

  const assertion = await navigator.credentials.get({
    publicKey: {
      challenge: base64urlDecode(challenge),
      allowCredentials: allowCredentials.map(c => ({
        id: base64urlDecode(c.id),
        type: "public-key",
      })),
      userVerification: "preferred",  // 生体認証 / PINを要求
      timeout: 60000,
    },
  });

  // サーバへ assertion 送信して検証
  await verifyAssertion(assertion);
}

MFA（多要素認証）：深層防御の基礎

MFA（Multi-Factor Authentication）は「知識・所持・生体」の複数要素を組み合わせる認証強化手法です。パスワード単体認証に比べ、不正ログインリスクを99%以上低減できるとされています（Microsoft 調査）。

MFA の種類と強度比較

方式仕組みフィッシング耐性利便性
SMS OTP6桁コードをSMSで受信低（SIMスワップ脆弱）◎
TOTP（認証アプリ）時刻ベース30秒OTP（RFC 6238）中（リアルタイムフィッシング可）○
FIDO2 / パスキー公開鍵署名◎（オリジン検証でフィッシング不可）○〜◎
ハードウェアキーYubiKey等 FIDO2 デバイス◎△（紛失リスク）

TOTP 実装例（Python / pyotp）


import pyotp, qrcode

# シークレット生成（初回登録時にユーザーへ提示）
secret = pyotp.random_base32()
totp = pyotp.TOTP(secret)

# QRコード用 URI 生成
uri = totp.provisioning_uri(name="user@example.com", issuer_name="MyApp")
qrcode.make(uri).save("totp_qr.png")

# 認証時の検証（valid_window=1 で前後30秒許容）
user_code = "123456"  # ユーザー入力値
is_valid = totp.verify(user_code, valid_window=1)
print("認証成功" if is_valid else "認証失敗")

技術選択ガイド：シーンごとの推奨構成

新規 Web アプリ（一般コンシューマ向け）

  • 認証：OIDC（Google / Apple ソーシャルログイン）＋ パスキー登録促進
  • 認可：OAuth2.0 Authorization Code + PKCE
  • MFA：FIDO2 優先、TOTP をフォールバック

エンタープライズ社内システム

  • 認証：SAML 2.0（Azure AD / Okta 連携）
  • MFA：ハードウェアキー（管理者・特権アカウント）、TOTP（一般社員）
  • ゼロトラスト：継続的な認証・デバイス証明書との組み合わせ

マイクロサービス間の認証

  • サービス間：mTLS（相互TLS）＋ JWT（短命トークン）
  • ユーザーコンテキスト伝播：OIDC ID トークンをヘッダで転送
  • トークン失効：Token Introspection エンドポイント活用

実装時のセキュリティチェックポイント

  • state パラメータ必須：OAuth2.0 の CSRF 対策。ランダム値を検証すること
  • redirect_uri の厳密マッチング：部分一致ではなく完全一致で検証
  • access_token の有効期限短縮：推奨は 15 分〜1 時間。長命トークンはリスク
  • refresh_token のローテーション：使用のたびに新トークン発行し古いものを無効化
  • JWT の alg:none 拒否：検証をスキップする脆弱な実装を排除
  • PKCE を SPAに必須化：Authorization Code Interception 攻撃対策

おすすめセキュリティ対策ツール

認証強化と並行して、エンドポイント全体を守るセキュリティソフトの導入も重要です。

🛡️ まず今日から始めるなら：エンドポイント保護ソフトの導入
不正アクセス・マルウェア感染のリスクを最小化するため、信頼性の高いセキュリティソフトの導入を強くお勧めします。

✅ おすすめのパスワードマネージャー

※ アフィリエイトリンクを含みます。料金・詳細は各公式サイトでご確認ください。

参考資料： 情報セキュリティ10大脅威 2026（IPA） / 内閣サイバーセキュリティセンター（NISC）

📋 無料配布：AIセキュリティ対策チェックリスト

中小企業・個人向け。今すぐできる30項目のセキュリティ確認リストを無料配布中。

無料でチェックリストを受け取る →

まとめ

認証・認可技術は「新しいものを使えばOK」ではなく、ユースケースに応じた選択が重要です。エンタープライズSSO にはSAML、新規開発にはOIDC+PKCE、フィッシング耐性を重視するならFIDO2/パスキーという基本軸を押さえつつ、MFAを多層で組み合わせることでリスクを大幅に低減できます。

パスキーの詳細な実装手順についてはパスキー導入完全ガイドを、ゼロトラスト設計との組み合わせについてはゼロトラストセキュリティ解説もあわせてご参照ください。

📚 関連記事

コメント

タイトルとURLをコピーしました