銀行エンジニアリング 29：第三者アプリに口座を見せる（OAuth・PKCE・同意）

Level 1 基礎：合鍵ではなく、期限つきの入館証を渡す

家計簿アプリに口座の残高を見せたいとき、銀行のパスワードを渡すのは危険です。パスワードがあれば、そのアプリは何でもできてしまい、やめさせるにはパスワードを変えるしかありません。

OAuthは、パスワードの代わりに『この範囲だけ、この期間だけ』を示す入館証（トークン）を、顧客の同意にもとづいて渡す仕組みです。顧客はいつでも取り消せます。

1. 01アプリが顧客を銀行の同意画面へ送る
2. 02顧客が範囲を確認して許可
3. 03銀行がアプリの戻り先へ認可コードを返す
4. 04アプリがコードをトークンに交換
5. 05トークンで決められた範囲だけ読む

Level 2 銀行業務：MiniBankの登場人物と決まり

これは学習用の簡易な仕組みで、実在の認可サーバーの認証や準拠を示すものではありません。外部への通信もしません。

Level 3 システム：MiniBankでの実装

• openbanking.check_authorization が、クライアントの存在と状態、redirect_uri の完全一致、PKCE（S256のみ）、state（8文字以上）、範囲がクライアントの許可内かを確かめる。違反は OB001〜OB004
• 戻り先が未登録なら、エラーを画面に表示して、リダイレクトしない。攻撃者のURIへ認可コードを送らないため
• openbanking.authorize_decide が同意と認可コードを作る。同じ顧客・同じアプリの再許可は、古い同意を失効させて新しい同意を作る
• public.ob_token（openbanking.exchange_code）が、コードとPKCEの検証子を交換する。検証子のSHA-256がコード発行時のチャレンジと一致しなければ拒否。検証子・戻り先・期限・同意の検査に失敗した試行でも、コードはその場で使用済みになり、推測を許さない（クライアントの不一致や形式の不正では使用済みにならない）
• 使用済みのコードが再び提示されたら、そのコードから出たトークンと同意を失効させる（盗用の疑い）
• トークンの平文は交換の応答で一度だけ返し、DBにはSHA-256のハッシュだけを保存する。テストで全表を検索して、平文が残らないことを確かめている

異常時：コードが2回使われた

Level 4 アーキテクチャ：なぜPKCEか

スマートフォンのアプリのように、秘密の鍵を安全に持てないアプリでは、認可コードが途中で盗まれる危険があります。PKCEは、アプリが毎回ランダムな検証子を作り、そのハッシュだけを最初に銀行へ渡します。コードを盗んだ人は検証子を知らないので、トークンに交換できません。MiniBankは平文のplain方式を受け付けず、S256のみです。

どこを確認すればよいか

• 顧客画面「外部アプリ連携」（/app/consents）：許可の一覧、取消
• 管理画面「Open Banking」：アプリの登録・停止、同意、イベント