本ページは認証・認可に関するページです。Webサービス・API・社内システムで必須の「誰であるかを確認」＝認証、「何をしてよいかを判定」＝認可の仕組みをまとめています。

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

認証と認可の違い

用語	英語	意味	例
認証	Authentication (AuthN)	誰であるかを確認する	ID/パスワードでログイン、生体認証
認可	Authorization (AuthZ)	何をしてよいかを判定する	管理者だけが削除可、自分のデータだけ閲覧可

混同しがちですが、認証で「誰」を確定してから、認可で「何を許すか」を判定する、という流れになります。

本ページの子ページ

• OAuth2.0 — 認可フレームワークの標準。Google / Twitter / GitHub ログインなどで使用

代表的な認証方式

方式	説明
パスワード認証	ID/Passの組合せ。最も基本
多要素認証 (MFA / 2FA)	パスワード＋TOTP / SMS / プッシュ通知 等
SSO (シングルサインオン)	1回のログインで複数サービスに利用可（SAML、OIDC）
ソーシャルログイン	Google/Twitter/GitHub等の認証情報を利用
生体認証	指紋、顔、虹彩
クライアント証明書	TLSクライアント証明書による相互認証
APIキー / トークン	サーバー間通信、Webhook、CLIで広く利用
パスキー (Passkey)	FIDO2 / WebAuthn。生体認証＋デバイス紐づけ

代表的な認可モデル

モデル	説明
RBAC（Role-Based Access Control）	ロール（管理者/編集者/閲覧者）に権限を割り当て
ABAC（Attribute-Based）	属性（部署、勤務時間、IP等）で動的に判定
ACL（Access Control List）	リソースごとに許可ユーザーをリスト管理
PBAC / OPA	ポリシー言語で柔軟に表現

主要なプロトコル・標準

標準	用途
OAuth 2.0	認可委譲。"Twitterで認可してこのアプリにアクセス許可"
OpenID Connect (OIDC)	OAuth 2.0 上に認証機能を追加。IDトークンで身元証明
SAML 2.0	エンタープライズSSOの標準。XMLベース
WebAuthn / FIDO2	パスワードレス認証（パスキー）
JWT (JSON Web Token)	署名付きトークン。OAuth/OIDCのアクセストークンで多用
LDAP / Active Directory	社内ユーザーディレクトリ

典型的なログインの流れ（OAuth 2.0 Authorization Code Flow）

1. ユーザーがアプリで「Googleでログイン」をクリック
2. アプリがGoogleの認可エンドポイントへリダイレクト
3. Googleが認証画面を表示。ユーザーが承認
4. Googleが認可コードを付けてアプリへリダイレクト
5. アプリがバックエンドから認可コードを送り、アクセストークン／IDトークンを取得
6. 取得したトークンをセッションに保存。以降の操作で利用

実装時の注意

• パスワードの保存はソルト＋強いハッシュ（bcrypt / argon2）。平文・MD5 / SHA1単体は絶対NG
• ログイン試行のレートリミットとアカウントロックを実装
• セッション固定攻撃対策に、認証成功時にセッションIDを再生成
• HTTPS必須。Cookieは Secure; HttpOnly; SameSite=Lax で発行
• OAuth/OIDCはライブラリ任せ: 自作署名検証は危険
• 権限チェックは必ずサーバー側: クライアントでの非表示は防御にならない

関連

• 親カテゴリ: セキュリティ
• 関連: 認証
• API認証: API