こんにちは、イケメンエンジニアです。
大手通信業界でWebアプリケーションを開発している現役エンジニアとして、 日々「認証基盤」「SSO設計」「BtoB向けIdP連携」などに向き合っています。
副業案件やSaaS開発の相談で、ほぼ必ず出るのがこのテーマです。
- 認証と認可って何が違うんですか？
- SSOってOIDCのことですよね？
- JWTで作ればセキュアですよね？
- RBACとABACどっちがいいですか？
実はこれ、全部レイヤーが違う話なんです。
今回は「仕組みの詳細」ではなく、 全体構造を俯瞰できる記事を書きます。
エンジニアとして設計できる状態になるための“地図”を作ります。
1. 認証と認可とは？まずここを混同しない
🔐 認証（Authentication）
認証とは、 「あなたは誰か？」を確認することです。
具体例
- ID・パスワード入力
- Googleログイン
- 指紋認証
- ワンタイムパスワード
ログイン行為はすべて認証です。
ここで重要なのは、 認証＝信頼の起点だということ。
システムは「誰か」を特定しないと、 権限も課金もデータ紐付けもできません。
🛂 認可（Authorization）
認可とは、 「その人は何ができるか？」を決めることです。
具体例
- 管理者だけ削除できる
- 一般ユーザーは閲覧のみ
- 営業部は営業データのみ閲覧可能
一言で整理すると
| 項目 | 認証 | 認可 |
|---|---|---|
| 問い | あなたは誰？ | あなたは何ができる？ |
| 発生タイミング | ログイン時 | 操作時 |
ここを混同すると、設計は崩壊します。
2. 認証方式の分類（どこで本人確認するか）
① ローカル認証
アプリが自分でユーザー情報を持つ方式。
例
- 個人開発のWebサービス
- 小規模社内ツール
メリット
- 実装がシンプル
- 外部依存がない
デメリット
- 複数サービス間でID分断
- パスワード管理責任が重い
MVP段階では最適。 しかしスケールすると限界が見えます。
② ディレクトリ認証
LDAPやActive Directoryなど、 中央ディレクトリで管理する方式。
例
- 企業内ポータル
- 社内勤怠システム
メリット
- 組織単位で一元管理
- 社内SSOが可能
デメリット
- 構築コストが高い
- インターネット向きではない
③ フェデレーション認証
GoogleやOktaなどの外部IdPに認証を委任。
例
- Googleログイン
- B2B SaaSのSSO連携
メリット
- パスワードを扱わない
- セキュリティ向上
- SSO実現可能
デメリット
- 外部依存
- 設定が複雑
BtoB SaaSでは事実上必須の方式です。
④ MFA（多要素認証）
パスワード＋追加要素。
例
- SMSコード
- 認証アプリ
- 物理キー
メリット
- なりすまし耐性が高い
デメリット
- UX低下の可能性
3. 認可モデルの分類（何ができるかをどう決めるか）
① RBAC（Role-Based Access Control）
ユーザー → ロール → 権限
例
- 管理者
- 編集者
- 閲覧者
メリット
- 分かりやすい
- 実装が容易
デメリット
- ロール爆発問題
② ABAC（Attribute-Based Access Control）
属性ベース制御。
例
- 営業部のみ閲覧可能
- 営業時間内のみ編集可能
メリット
- 柔軟
デメリット
- 設計難易度が高い
③ ACL（Access Control List）
リソース単位で許可を設定。
例
- ファイル単位の閲覧権限
④ PBAC（Policy-Based Access Control）
ポリシーベースで制御。
マイクロサービス構成で採用されることが増えています。
4. 管理場所（Identity Store）
ユーザー情報をどこが保持するか。
- 内部DB
- LDAP
- IdP（Googleなど）
BtoB SaaSでは外部IdP連携はほぼ必須。
5. 認証プロトコル（どうやって安全に伝えるか）
OIDC（OpenID Connect）
OAuth 2.0上に構築された認証プロトコル。
SAML（Security Assertion Markup Language）
XMLベースの企業向け認証プロトコル。
Kerberos
ネットワーク認証プロトコル。
Windowsドメイン環境で広く利用。
6. トークン方式（ログイン状態の保持方法）
セッション方式
- サーバー側に状態を持つ
- 強制失効が容易
JWT方式（JSON Web Token）
- ステートレス
- API・マイクロサービス向き
7. SSOとは？
SSO（Single Sign-On）とは、 一度のログインで複数サービスを利用できる状態。
SSOはプロトコルではなく「結果（UX）」。
まとめ｜設計できるエンジニアになる
認証・認可は単なるログイン機能ではありません。
それはアーキテクチャ設計の核心です。
副業案件やBtoB開発で 「認証どうします？」と聞かれたとき、 この構造で説明できるエンジニアは強い。
次回はOIDC・JWT・SSOの内部構造を徹底解説します。
コメント