本稿は 認証系の Web サービス・仕組みに関する記事です。Web アプリで「誰がアクセスしているか」を確認するための方式・サービスをまとめます。

子ページから項目を選択してください。

本ページの子ページ

• Google OAuth 2.0 — Google アカウントでのソーシャルログイン
• reCAPTCHA — bot 排除のためのチャレンジ

認証 (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 スワッピング攻撃に弱い。アプリ認証 / パスキーを優先
• 監査・退会・侵害対応を最初から設計に組み込む

関連

• 親カテゴリ: Web サービス
• 子ページ: Google OAuth 2.0 / reCAPTCHA