🔐 仕組みで理解する：SSO と メールアドレス認証

実装や設計のときに迷いやすい「SSO（SAML/OIDC）」と「メールアドレス認証（マジックリンク/OTP）」の動作の流れと注意点を、最短で把握できるように整理しました。

ざっくり結論: 社内/B2B → SSO B2C/軽量登録 → メール認証 どちらも MFA・レート制限・監査ログは必須

1) SSO（SAML / OpenID Connect）の仕組み

登場人物

典型フロー（OIDC Authorization Code + PKCE）

ユーザー → SP: /login を開く
SP → ブラウザ: IdPの認可エンドポイントへリダイレクト(client_id, scope, code_challenge...)
ブラウザ → IdP: ログイン画面（MFA/条件付きアクセス含む）
IdP → ブラウザ: 認可コード付きでSPのredirect_uriへリダイレクト
ブラウザ → SP: redirect_uri?code=...
SP → IdP(Tokenエンドポイント): code + code_verifier を送信しトークン請求
IdP → SP: IDトークン(JWT) + アクセストークン 等を返却
SP: IDトークン検証（署名/exp/aud/iss）、ユーザーをローカルセッションに紐付け
SP → ユーザー: ログイン完了

※SAMLの場合は「認証レスポンス（署名付きアサーション）」を受け取り、SPが検証してセッションを張る点が要点。

キーポイント

  • トークンは 署名検証（JWKs / x509）。iss/aud/exp を必ず検査。
  • セッション管理はSP側。短命クッキー＋SameSite/HttpOnly/Secure。
  • 権限付与は グループ/クレーム（ロール）で行い、アプリ側に反映。
  • ユーザー作成/削除は SCIM で自動化がベスト。

セキュリティ注意点

  • 認可コード奪取対策：PKCE、redirect_uri の厳格一致。
  • トークン漏えい対策：短期有効／ローテーション、バックチャネルで交換。
  • フェデレーション障害時の BCP（緊急ログイン/代替IdP）。
  • ログ：IdPとSP双方で監査一元化。

2) メールアドレス認証（マジックリンク / ワンタイムコード）の仕組み

概要

パスワードを使わず、メールで送る 一時トークン（リンクまたは数字コード）で本人性を確認する方式。

典型フロー（マジックリンク）

ユーザー → アプリ: メールアドレス入力
アプリ: 使い捨てトークン(短期有効・1回限り)をDBに保存し、リンクを生成
アプリ → メール: 署名付きURLを送信 (例: https://app.example.com/callback?t=...)
ユーザー → ブラウザ: メールのリンクをクリック
ブラウザ → アプリ: /callback?t=... に到達
アプリ: トークンの有効期限/未使用/端末情報を検証 → ログイン成立
アプリ: ローカルセッション発行（クッキーまたはアプリ内セッション）

実装の勘所

  • 有効期限：5〜10分目安。一回限りで失効。
  • 端末バインド：発行時のユーザーエージェント/デバイス情報と突合。
  • レート制限：同一IP/メール宛の連続送信を抑制。
  • メール到達率：SPF/DKIM/DMARC 設定と送信ドメイン監視。

セキュリティ注意点

  • メール乗っ取り・転送経由の漏えいに注意。短命・一回限り・デバイス固定が基本。
  • リンク改ざん対策：署名付きトークン（HMAC/JWT）とstate等。
  • 中間者対策：HTTPS必須、SameSite/HttpOnly/Secureクッキー。
  • OTP方式では試行回数制限と時刻ズレ耐性の設計。

3) どちらの方式でも押さえる共通ポイント

項目推奨
MFA必須（TOTP, WebAuthn/パスキー, デバイス認証など）
セッション短寿命・更新型、クッキーは HttpOnly/Secure/SameSite、CSRF対策
監査成功/失敗/多要素/トークン交換/設定変更をログ、相関ID付与
可用性リトライ/冪等性、メール送信・IdPの障害時の退避経路
まとめ: SSOは組織のIdPに統合しガバナンスを効かせるのに最適。メール認証は登録摩擦を最小化できるが、トークンの短期・一回限り・端末バインド・レート制限が鍵。用途に応じて選びつつ、共通でMFA/監査/セッション安全化を徹底しましょう。