IBM 製品ベースの銀行 API に関する考察

# **API コール時の X-IBM-Client-Id**

IBM 社の製品を使って銀行 API を作ると、API コール時の必須パラメーターとして **`X-IBM-Client-Id` というカスタムヘッダーでクライアント ID を指定する必要**があるようです。 銀行 API を『三菱東京 UFJ 銀行』という大銀行の名前のもとに公開するにしても、IBM 社の名前が API 仕様の一部として含まれることになります。

>**三菱東京 UFJ 銀行 / 入出金明細照会 API**
https://developer.portal.bk.mufg.jp/node/1947

アクセストークンには少なくとも次の情報が紐づいているはずなので、

||紐づく情報|
|:-:|:--|
|1| **ユーザー**<br/><sub>（ただし、[クライアントクレデンシャルズフロー](https://tools.ietf.org/html/rfc6749#section-4.4)で発行されたアクセストークンにはユーザーは紐付かない。）</sub> |
|2| **クライアント ID** |
|3| **権限** |
|4| **有効期限** |

アクセストークンからクライアント ID の情報を取得することはリソースサーバー（銀行 API を提供するサーバー）側で可能なのです。 にも関わらず、API コール時、アクセストークンに加えて `X-IBM-Client-Id` というカスタムヘッダーでクライアント ID を指定する必要があるようです。

このことは、IBM 社の次のドキュメントからも明らかです。

>***IBM API Connect for Bluemix
OAuth 2.0 を使用した API の保護
アクセス・トークンの使用***
https://www.ibm.com/support/knowledgecenter/ja/SSFS6T/com.ibm.apic.toolkit.doc/tutorial_apionprem_security_OAuth.html#OAuth_Tute__Using_Tokens

```shell-session
curl -k -v ¥
  -H "X-IBM-Client-Id: Client_ID" ¥
  -H "Authorization: Bearer Access_Token" ¥
  -X GET 'Operation_URL'
```

上記は IBM 社のドキュメントから引用したコマンドラインですが（若干整形してあります）、「[RFC 6750](https://tools.ietf.org/html/rfc6750), [2.1. Authorization Request Header Field](https://tools.ietf.org/html/rfc6750#section-2.1)」の仕様に則って `Authorization` ヘッダーでアクセストークンを指定しているにも関わらず、`X-IBM-Client-Id` というカスタムヘッダーも指定しています。


# **アクセストークン検証を外部に移譲しても**

アクセストークンの検証を標準イントロスペクション API（[RFC 7662](https://tools.ietf.org/html/rfc7662)）を実装する外部の認可サーバーに投げるとしても、依然として API コール時に `X-IBM-Client-Id` カスタムヘッダーが必要です。

> ***IBM API Connect 5.0.x
Integrating third party OAuth provider***
https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/con_oauth_introspection.html

普通は、アクセストークンを発行する認可サーバーがクライアント ID も発行・管理するので、「アクセストークンを発行する認可サーバーは外部にあるがクライアント ID は IBM のシステムが発行・管理する」というは、かなり使い勝手が悪い仕組みです。 標準イントロスペクション API を活用している点は良いですが、設計としては [Amazon API Gateway](https://aws.amazon.com/api-gateway/) の Custom Authorizer のほうに分があります（参考：『[Amazon API Gateway の Custom Authorizer を使い、OAuth アクセストークンで API を保護する](https://qiita.com/TakahikoKawasaki/items/b372ab49da0a9aedb76a)』）。

「クライアント ID に別名を付ける」という機能を持つ [Authlete](https://www.authlete.com/) のようなプロダクトであれば、クライアント ID の発行・管理が IBM 製品側に残っていたとしても、アクセストークン検証をおこなうことはできますが、それでも、リソースサーバーが `X-IBM-Client-Id` カスタムヘッダーを要求する点については認可サーバー側ではなんともできません。


# **BIAN にも X-IBM-Client-Id**

私の勘違いでなければ、IBM 社が世界標準銀行 API と謳っている（ときいている）『BIAN』（Banking Industry Architecture Network）という API 仕様の一部にも `X-IBM-Client-Id` が含まれています。

> ***IBM Bluemix Banking APIs
Party Authentication (v3)***
https://bian-api.developer.eu.apim.ibmcloud.com/node/41#/

![X-IBM-Client-Id_in_BIAN_API.png](https://qiita-image-store.s3.amazonaws.com/0/106044/4803b3e3-8230-2d82-9c20-dd657fe95423.png)


# **クライアント種別でエンドポイントが分かれる**

IBM 社の製品を用いて OAuth 2.0 のエンドポイントを実装できますが、エンドポイント生成時、クライアントタイプ（[RFC 6749](https://tools.ietf.org/html/rfc6749), [2.1. Client Types](https://tools.ietf.org/html/rfc6749#section-2.1)）を指定する必要があります。 このため、一つのエンドポイントで Public クライアントと Confidential クライアントの両方を同時にサポートすることはできないと推測されます。

> ***IBM API Connect for Bluemix
Creating an OAuth provider API***
https://www.ibm.com/support/knowledgecenter/en/SSFS6T/com.ibm.apic.toolkit.doc/tapim_sec_api_config_scheme_oauth_endpoint.html


# **おまけ**

非営利国際標準化団体『**[The OpenID Foundation](http://openid.net/)**』の [Financial API ワーキンググループ](http://openid.net/wg/fapi/)で **Financial API**（金融 API）仕様を策定しています。 BIAN とは競合する仕様になります。 詳細は Financial API ワーキンググループの[ウェブサイト](http://openid.net/wg/fapi/)や『[Financial API 実装の技術課題](https://qiita.com/TakahikoKawasaki/items/48a9d22205f77db59726)』を参照してください。