本稿は 認証系の Web サービス・仕組みに関する記事です。Web アプリで「誰がアクセスしているか」を確認するための方式・サービスをまとめます。
子ページから項目を選択してください。
本ページの子ページ
認証 (Authentication) と認可 (Authorization)
| 用語 | 意味 | 例 |
|---|
| 認証 (Authentication / AuthN) | 誰であるかを確認 | ID + パスワード、生体認証 |
| 認可 (Authorization / AuthZ) | 何ができるかを許可 | ロール (管理者・一般)、権限スコープ |
| 監査 (Auditing) | いつ・誰が・何をしたか記録 | 監査ログ、SIEM |
代表的な認証方式
| 方式 | 用途 | 特徴 |
|---|
| パスワード認証 | もっとも基本 | 強度・漏洩リスクが課題。多要素 (MFA) との併用必須 |
| 多要素認証 (MFA / 2FA) | 知識 + 所持 + 生体の組み合わせ | TOTP (Google Authenticator)、SMS、プッシュ通知 |
| パスキー (FIDO2 / WebAuthn) | パスワードレス | 端末の生体認証＋公開鍵暗号。フィッシング耐性 |
| シングルサインオン (SSO) | 1 回認証で複数サービス | SAML 2.0、OIDC、Azure Entra ID、Okta |
| OAuth 2.0 | API への認可委譲 | アクセストークン。スコープで権限制御 |
| OpenID Connect (OIDC) | OAuth 2.0 を拡張したログイン | ID トークン (JWT)。ソーシャルログインの標準 |
| API キー | 機械対機械 | シンプルだが万能ではない。利用範囲を絞る |
| クライアント証明書 | 高セキュリティ | mTLS。社内 / 政府系で利用 |
| LDAP / AD 連携 | 社内認証 | 既存の Active Directory に統合 |
| SAML 2.0 | エンタープライズ SSO | XML ベース。SaaS 連携で多用 |
主な認証関連サービス・ライブラリ
| サービス | 位置づけ |
|---|
| Auth0 | マルチテナント IDaaS。アプリへの認証導入が短時間 |
| Firebase Authentication | モバイル・Web 向け。Google 系 |
| Azure Entra ID (旧 Azure AD) | マイクロソフト系の SSO / SCIM / Conditional Access |
| Okta | SSO / IDaaS の老舗 |
| AWS Cognito | AWS の認証基盤 |
| Google OAuth / Sign In | Google アカウントでのログイン (こちら) |
| Keycloak | OSS の認証基盤 (Red Hat) |
| LINE / X / Facebook ログイン | 各 SNS の OAuth/OIDC ログイン |
| WebAuthn / FIDO2 | 標準仕様。Yubikey / 生体認証 / パスキー |
| reCAPTCHA | bot 対策 (こちら) |
セッション管理
| 仕組み | 概要 |
|---|
| セッション Cookie | サーバ側にセッションを保持、Cookie に ID。HttpOnly + Secure + SameSite |
| JWT (JSON Web Token) | 署名付き自己完結トークン。サーバ側のセッション保持が不要だが、失効が難しい |
| リフレッシュトークン | 短命アクセストークン + 長命リフレッシュ。OAuth 2.0 の典型 |
| Idle / Absolute タイムアウト | 無操作 / 絶対時間の 2 段 |
パスワードに関する基本
- 保存は必ずソルト付きハッシュ (
bcrypt / argon2)。MD5/SHA1 は不可
- パスワードの使い回し検知 (Have I Been Pwned 等)
- 長さ・複雑度の過度な制約はかえって弱くなる。長さ重視 (12 文字以上)
- ログイン失敗のレートリミットとロックアウト
- パスワードレス (パスキー) を最終目標に
セキュリティ上の脅威と対策
| 脅威 | 対策 |
|---|
| パスワード総当たり (Brute Force) | レートリミット、CAPTCHA、ロックアウト |
| クレデンシャルスタッフィング | 2FA、漏洩パスワード検査 |
| フィッシング | パスキー、ドメインバインド認証 |
| セッションハイジャック | HTTPS、HttpOnly / Secure / SameSite Cookie、トークン再発行 |
| CSRF | CSRF トークン、SameSite=Lax/Strict |
| XSS によるトークン窃取 | HttpOnly Cookie、CSP、入力エスケープ |
| ボット登録 | reCAPTCHA、メール認証、行動分析 |
運用設計のポイント
- 認証ログの保管・監査 (ログイン成功・失敗・ロック)
- SSO + プロビジョニング (SCIM) で入退社運用を自動化
- 秘密情報 (Secret / API キー / 証明書) のSecrets Manager 管理
- パスワードリセット導線 (メール / SMS / 本人確認)
- 退会・データ削除のフロー (GDPR 等)
注意点
- 自前で認証を作るより、IDaaS / OAuth プロバイダを使う方が安全なケースが多い
- 独自実装の MD5/SHA1 + ソルト無しは事実上ノーガード
- OAuth 2.0 を「ログイン」として使うのは厳密には誤り。OIDC を使う
- 「2FA を SMS のみで実装」は SIM スワッピング攻撃に弱い。アプリ認証 / パスキーを優先
- 監査・退会・侵害対応を最初から設計に組み込む
関連