金融グレード
銀行・証券・決済サービ スに求められるセキュリティ水準を、標準仕様で実現します。
「API連携時のなりすまし」「トークン窃取による不正送金」「中間者攻撃」── これらのリスクに対して、国際標準（FAPI）に準拠した多層防御を提供します。
こんな課題はありませんか？
| 課題 | idp-serverでの解決策 |
|---|---|
| API連携先が本物かどうか確認したい | 相互証明書認証（mTLS） でアプリの身元を証明書で検証 |
| アクセストークンが盗まれたら不正利用される | 証明書バウンドトークン でトークン単体では使えない仕組みに |
| 認可リクエストがブラウザ上で改ざんされるかも | 事前登録（PAR） でリクエストをサーバー間で直接受け渡し |
| 認可レスポンスが途中で差し替えられるかも | 署名付きレスポンス（JARM） で改ざんを即座に検知 |
| 高額送金時に本人の意思を確実に確認したい | モバイル承認（CIBA） でスマホの生体認証による取引承認 |
| 残高照会と送金で同じ認証レベルでいいのか | 多段認証ポリシー で操作の重要度に応じて認証レベルを自動切替 |
| 本人確認済みのユーザーだけにAPI利用を許可したい | 身元確認（eKYC）+ verified_claims で本人確認済みユーザーのみアク セス可能に |
| 金融庁やOpenID Foundationの認定基準を満たせるか | FAPI 1.0 Advanced 準拠 で国際標準に対応 |
守れること
1. API連携の安全性
「このAPIを叩いているのは、本当に許可されたアプリか？」
通常のOAuth 2.0では、Client ID/Secretが漏洩すればなりすましが可能です。 金融グレードでは、クライアント証明書による相互認証（mTLS） を追加します。
一般的なOAuth 2.0:
アプリ → 「IDとSecretはこれです」 → サーバー
⚠️ IDとSecretが漏れたら誰でもなりすませる
金融グレード:
アプリ → 「IDとSecretに加え、この証明書で身元を証明します」 → サーバー
✅ 証明書の秘密鍵がなければなりすまし不可能
✅ 発行されたトークンもこの証明書に紐付く
効果: トークンだけ盗んでも、証明書がなければAPIは使えません。
2. リクエスト・レスポンスの完全性
「ブラウザを経由する通信が途中で書き換えられていないか？」
認可リクエストがブラウザのアドレスバーを通過する際、パラメータの改ざんリスクがあります。
一般的なOAuth 2.0:
アプリ → ブラウザ → サーバー
↑ ここで送金額や送金先が書き換えられるかも
金融グレード:
Step 1: アプリ → サーバー（直接通信で事前登録: PAR）
Step 2: ブラウザには参照用IDだけ渡す
Step 3: サーバー → アプリ（署名付きレスポンス: JARM）
✅ パラメータはサーバー間で直接やり取り
✅ レスポンスは署名済みなので改ざん検知可能
効果: 中間者攻撃によるパラメータ改ざんを防止します。
3. 取引の重要度に応じた認証
「残高照会と1,000万円の送金が同じ認証レベルでいいのか？」
操作の重要度に応じて、自動的に認証レベルを切り替えます。
残高照会（read, account）
→ メールOTPで認証
→ 低リスク操作なので簡易認証
振込設定の変更（write）
→ FIDO2 生体認証で認証
→ 設定変更は中リスク
高額送金（transfers）
→ FIDO2 生体認証 + メールOTP
→ 高リスク操作なので二重認証
効果: ユーザー体験を損なわず、リスクに見合った認証を実現します。
4. モバイルでの取引承認
「PCで送金操作 → スマホで最終承認」という二段階承認フローを実現します。
銀行員/ユーザーがPCで操作 モバイルアプリ
│ │
│ 「A社へ1,000万円送金」 │
│ [実行] │
│ ↓ │
│ 「スマホで承認してください」 │
│ │ プッシュ通知が届く
│ 待機中... │ 「A社へ1,000万円の送金を
│ │ 承認しますか？」
│ │
│ │ [指紋認証で承認]
│ ↓ │
│ 送金完了 │
効果: 操作端末とは別のデバイスでの生体認証により、不正送金リスクを大幅に低減します。
5. 本人確認済みユーザーのみに制限
「口座開設や送金APIを使えるのは、本人確認が完了したユーザーだけ」
金融機関のAPI連携では、犯罪収益移転防止法（犯収法）等の規制により、本人確認（KYC）が事実上必須です。idp-serverでは、eKYCと金融グレードを組み合わせることで、これを仕組みとして強制できます。
未確認ユーザーが送金APIにアクセス
→ スコープに identity_verification が必要
→ 本人確認が未 完了なのでアクセス拒否
確認済みユーザーが送金APIにアクセス
→ verified_claims で本人確認済みを証明
→ アクセス許可
→ IDトークンに確認済み情報（氏名・生年月日等）を含めて発行
仕組み:
required_identity_verification_scopesで、特定スコープ（送金、口座開設等）に本人確認を必須化- 外部eKYCサービスとの連携で、本人確認書類の検証を自動化
- 確認済み情報は OIDC4IDA 標準の
verified_claimsとして発行
効果: 本人確認を「運用ルール」ではなく「システム制約」として組み込み、規制遵守を確実にします。
eKYC機能の詳細は 身元確認/eKYC を参照してください。
対応する規制・標準
| 規制・標準 | 対応状況 |
|---|---|
| FAPI 1.0 Advanced | 準拠（OpenID Foundation策定の金融API標準） |
| FAPI-CIBA | 準拠（バックチャネル認証の金融拡張） |
| 犯罪収益移転防止法（犯収法） | eKYC + verified_claims + required_identity_verification_scopes で本人確認の強制が可能 |
| 電子決済等代行業に関するAPI連携 | FAPI準拠により対応可能 |
| PSD2 / Open Banking（欧州） | FAPI準拠により対応可能 |
技術構成
上記の保護を実現するために、以下の技術要素を組み合わせています。
| 保護対象 | 技術要素 | 役割 |
|---|---|---|
| アプリの身元確認 | mTLS（相互証明書認証） | クライアント証明書でアプリを認証 |
| トークン窃取の防止 | 証明書バウンドトークン | トークンを証明書に紐付け |
| リクエスト改ざん防止 | PAR + 署名付きリクエスト | パラメータをサーバー間で直接受渡し |
| レスポンス改ざん防止 | JARM（署名付きレスポンス） | レスポンスに電子署 名 |
| 取引承認 | CIBA + FIDO2 | モバイル生体認証による承認 |
| 認証レベル制御 | 多段認証ポリシー | スコープに応じた認証レベル自動切替 |
| 本人確認の強制 | eKYC + verified_claims | 特定スコープに本人確認済みを必須化 |
FAPI Advanced フロー（技術詳細）
アプリ idp-server
│ │
│ PAR（署名付きリクエスト） │
│ + mTLS クライアント認証 │ ← アプリの身元を証明書で検証
│ ────────────────────────────→│
│ │
│ request_uri │ ← ブラウザに渡すのは参照IDだけ
│ ←────────────────────────────│
│ │
│ 認可リクエスト │
│ (request_uri) │
│ ────────────────────────────→│
│ │
│ [ユーザー認証] │ ← 操作に応じた認証レベル
│ │
│ JARM（署名付きレスポンス） │ ← レスポンスの改ざんを防止
│ ←────────────────────────────│
│ │
│ トークンリクエスト │
│ + mTLS クライアント認証 │ ← 再度証明書で検証
│ ────────────────────────────→│
│ │
│ 証明書バウンドアクセストークン │ ← この証明書でしか使えない
│ ←────────────────────────────│
導入時に決めること
1. API連携先アプリの認証方式
| 方式 | 仕組み | 向いているケース |
|---|---|---|
| 証明書認証（tls_client_auth） | クライアント証明書で身元を証明 | PKI基盤がある金融機関 |
| JWT認証（private_key_jwt） | 秘密鍵で署名したJWTで身元を証明 | 証明書運用が難しい環境 |
| 両方 | アプリ種別ごとに使い分け | 社内アプリと外部連携先の混在 |
2. 操作ごとの認証レベル
| 操作 | 認証レベルの例 |
|---|---|
| 残高照会・取引履歴 | メールOTP（低リスク） |
| 振込先登録・限度額変更 | 生体認証（中リスク） |
| 高額送金・海外送金 | 生体認証 + メールOTP（高リスク） |
| 窓口での高額取引承認 | CIBA モバイル承認（最高リスク） |
3. 証明書の運用方針
| 決めること | 選択肢の例 |
|---|---|
| 認証局（CA） | 自社CA、商用CA |
| 証明書の有効期限 | 1年、2年 |
| 失効管理 | CRL配布、OCSP応答 |
| 秘密鍵の保管 | HSM（推奨）、ソフトウェアキーストア |
4. トークンの有効期限
金融サービスでは短命トークンが推奨されます。
| トークン | 推奨値 | 理由 |
|---|---|---|
| アクセストークン | 300秒（5分） | 窃取時の影響を最小化 |
| IDトークン | 300秒（5分） | 認証情報の鮮度を維持 |
| リフレッシュトークン | 30日 | 長期セッション用（ローテーション必須） |
5. 本人確認（eKYC）の必須化
金融機関間のAPI連携では、犯収法等の規制上、本人確認が事実上必須です。
| 決めること | 選択肢の例 |
|---|---|
| 本人確認が必要なスコープ | transfers（送金）、account_opening（口座開設）、全スコープ |
| 確認方法 | idp-server経由で外部eKYCサービス連携、既存KYC結果の登録 |
| trust_framework | jp_aml（犯収法準拠）、eidas（欧州）、独自定義 |
| 確認済み情報の保持 | 氏名・ 生年月日・住所、最小限（氏名のみ） |
詳細は 身元確認/eKYC を参照してください。
6. CIBA モバイル承認の利用
| 決めること | 選択肢の例 |
|---|---|
| 対象取引 | 高額送金のみ、全送金、窓口取引 |
| 承認タイムアウト | 120秒（推奨） |
| 承認画面の表示内容 | 送金先・金額・日時を表示 |
まとめ
idp-serverが提供すること
- FAPI 1.0 Advanced / FAPI-CIBA 準拠の認可基盤
- 相互証明書認証（mTLS）と証明書バウンドトークン
- リクエスト事前登録（PAR）と署名付きリクエスト/レスポンス（JARM）
- 多段認証ポリシー（操作の重要度に応じた認証レベル自動切替）
- 本人確認の強制（eKYC + verified_claims + required_identity_verification_scopes）
- モバイル取引承認（CIBA + FIDO2 生体認証）
自分で用意すること
- mTLS 対応のクライアントアプリケーション
- 証明書の調達と運用体制（PKI）
- CIBA利用時: モバイル承認アプリ（FIDO2対応）
セキュリティの注意点
- 秘密鍵は HSM での保管を推奨
- アクセストークンは5分以内の短命設定を推奨
- 本番環境では商用CAの証明書を使用
- OpenID Foundation の FAPI 認定テストの実施を推奨
テンプレートで試す
ローカル環境ですぐに試せるテンプレートが用意されています。
cd config/templates/use-cases/financial-grade
# クライアント証明書を生成（初回のみ）
./generate-certs.sh
# セットアップ実行
./setup.sh
セットアップ後の動作確認:
| スクリプト | 内容 |
|---|---|
VERIFY.md | 基本動作確認（FAPIフロー、mTLS、PAR、JARM） |
verify.sh | FAPI設定検証スクリプト |
ciba-device-auth.sh | CIBAデバイス認証 |
環境変数でカスタマイズ
# 組織名を指定
ORGANIZATION_NAME="my-bank" ./setup.sh
# mTLS URL を指定
MTLS_BASE_URL="https://mtls.mybank.example.com" ./setup.sh
# トークン有効期限をカスタマイズ
ACCESS_TOKEN_DURATION=600 REFRESH_TOKEN_DURATION=86400 ./setup.sh
詳細: config/templates/use-cases/financial-grade/
関連ドキュメント
- Concept: FAPI
- Protocol: FAPI-CIBA
- CIBA - モバイル承認の詳細
- パスワードレス認証 - FIDO2/生体認証の詳細
- ローカルサブドメイン設定 - mTLS環境の証明書構成
最終更新: 2026-03-13