OpenID Connect（OIDC）やIDトークン・UserInfo APIでは「クレーム（claim）」でユーザー属性情報をやり取りします。
サービス連携やeKYC、B2B SaaSの本人確認でもクレーム設計は超重要！
何をどう載せるかで使い勝手もセキュリティも変わるが、最小連携が基本的な考え方となる。
1. クレームとは？
- IDトークンやUserInfoで渡される「ユーザー属性」のこと
- 例：
name, email, birthdate, phone_number, address, sub（ユーザーID）など
- 標準クレーム＋独自クレーム（カスタムclaim）を設計できる
2. クレーム設計の基本方針
必要最小限・目的特化
- 利用する属性だけ載せる（最小権限の原則）
- 例：フルネーム・生年月日・住所・本人確認済フラグなど
標準クレームの活用
明確な命名・フォーマット
- ユーザーが見て分かる、サービス間で意思疎通できる名前に
- 日付はISO 8601、住所は分割/連結など、実装・利用側の都合も考慮
3. 標準クレーム例
| クレーム名 | 内容 | 例 |
|---|
| sub | ユーザーID | "b6c7e2a1-..." |
| name | 氏名 | "山田太郎" |
| given_name | 名 | "太郎" |
| family_name | 姓 | "山田" |
| email | メールアドレス | "taro@example.com" |
| birthdate | 生年月日 | "1970-01-01" |
| phone_number | 電話番号 | "+81-90-1234-5678" |
4. カスタムクレーム設計例（独自属性）
| クレーム名 | 内容 | 例 |
|---|
| verified | 本人確認済フラグ | true/false |
| ekyc_level | eKYC認証レベル | "basic", "plus" |
| member_status | 会員ステータス | "premium" |
| organization_id | 所属組織ID | "org-1234" |
5. 設計・運用のポイント
- クレームごとに「取得同意」をユーザーに明示
- カスタムクレームは仕様書＆連携先と合意して設計
- 機微情報（住所・電話番号等）は暗号化やアクセス制限も検討
- 必要に応じて「スコープ」とセットで設計（
profileスコープでname・emailのみ許可など）