クライアントタイプ
OAuth 2.0 では、クライアント（アプリケーション）を2つのタイプに分類します。 この分類は、セキュリティの考え方やフローの選択に大きく影響します。
なぜ分類するのか？
クライアントタイプの分類は、 「クライアントシークレット（秘密鍵）を安全に保管できるかどうか」 で決まります。秘密鍵を安全に保管できないアプリケーションには、 異なるセキュリティ対策が必要です。
機密クライアント (Confidential Client)
サーバーサイドで動作し、クライアントシークレットを安全に保管できるアプリケーションです。
シークレットを安全に保管: サーバー側の環境変数やシークレットマネージャーに保存。 ユーザーのブラウザからはアクセスできない。
トークン交換がサーバー間で行われる: 認可コードからトークンへの交換は、バックエンドサーバーから直接認可サーバーに通信する。
リフレッシュトークンを安全に利用できる: 長期間有効なリフレッシュトークンもサーバー側で管理。
具体例
パブリッククライアント (Public Client)
ユーザーのデバイス上で動作し、クライアントシークレットを安全に保管できないアプリケーションです。 ソースコードやネットワーク通信がユーザーに見える環境で動作します。
シークレットを持てない: JavaScript のソースコードやモバイルアプリのバイナリは解析可能。 埋め込んだシークレットは秘密にならない。
PKCE が必須: シークレットの代わりに PKCE (Proof Key for Code Exchange) を使って、認可コードの横取りを防ぐ。
トークンの扱いに注意が必要: ブラウザの localStorage や sessionStorage に保存するトークンは、XSS攻撃で窃取されるリスクがある。
具体例
セキュリティの違い
| 機密クライアント | パブリッククライアント | |
|---|---|---|
| シークレット | 安全に保管可能 | 保管不可 |
| PKCE | 推奨 | 必須 |
| リフレッシュトークン | 安全に利用可能 | ローテーション必須 |
| トークン保管場所 | サーバーのメモリ/DB | ブラウザ/デバイス |
| 推奨フロー | 認可コード + シークレット | 認可コード + PKCE |
フロー選択への影響
# どのフローを選ぶべきか？
サーバーサイドアプリ（機密）
→ 認可コードフロー + クライアントシークレット
→ 最も安全。バックチャネルでトークン交換。
SPA・モバイルアプリ（パブリック）
→ 認可コードフロー + PKCE
→ シークレット不要。コード横取り攻撃を防止。
非推奨: インプリシットフロー
→ セキュリティ上の問題が多く、現在は推奨されない。
→ 代わりに認可コード + PKCE を使うべき。
まとめ
クライアントタイプの分類はシークレットを安全に保管できるかどうかで決まる
パブリッククライアントではPKCE が必須（機密クライアントでも推奨）
どちらのタイプでも、現在は認可コードフローが推奨される