「今すぐAPIを公開したい」と言われたシステム担当者が取り組むべき三つのこと(第4章)

第4章 APIを安全に公開、便利に活用してもらうためのAPI連携認証システム

デジタルビジネス(X-Tech)の取り組みは、さまざまな分野で行われるようになってきました。オープンAPIを通じて自社のビジネスを外部に開放し、サービスやデータを連携することで、デジタルビジネスが実現されます。オープンAPIを安全に公開し、アプリ開発者やエンドユーザーに便利に活用してもらうためには、API連携認証システムの構築が不可欠になります。今回はAPI連携認証システムの技術動向について解説していきます。

全5回シリーズ
「今すぐAPIを公開したい」と言われたシステム担当者が取り組むべき三つのこと

オープンAPIを公開・提供する際の課題

自社内や限定したパートナーなどに提供されるAPIは、保護されたネットワーク境界内からのみアクセスできるように提供されることがほとんどでした。

これに対しオープンAPIは、不特定多数のシステムやユーザーからアクセスされうる環境で提供することになるため、API利用者の認証と、機能やデータのアクセス権管理をこれまで以上に厳密に行なう必要があります。

また、オープンAPIの利用形態は、当事者間でのAPI利用(機能やデータの利用)だけでなく、特にコンシューマ向けサービスなどではAPI公開企業、サービス提供企業、利用者の3者が関連するAPI利用が行なわれます。

FinTechを例にした場合、別図のようにサービスB(金融機関)がAPIを公開し、サービスA(アプリ提供企業)がAPIを利用して、利用者に対して新たなサービスを提供するというモデルです。

このモデルでの具体的なサービスの流れは、サービスA(資産管理サービスなど)は、利用者の意図に基づき利用者に成り代わりサービスB(金融機関)のAPIにアクセスします。そして、サービスBは利用者向けの機能やデータ(預金残高等)をサービスAに提供します。こうすることで利用者はサービスAが提供する資産管理サービス上で自身の預金残高等を一元的に確認できる付加価値を得ることができるようになります。

オープンAPIの提供においては、この3者間でのAPI利用に対応する、認証・アクセス権管理の機能が不可欠となります。

利用者のデータ、利用者が私用する機能を、APIを使って、サービス間で連携させることが不可欠

「OAuth 2.0」で安全な3者間のAPI利用に対応する

3者間でAPIを利用する場合、利用者はサービスA(資産管理サービスなど)に対してアクセス可能なデータや操作を限定して、サービスB(金融機関)のAPIへアクセスさせたいと望みます。

API連携のため利用者のID、パスワードなどのクレデンシャル情報をサービスAに提供する方法では利用者の全権限をサービスAに与えてしまうことになります。これでは利用者が意図しない情報の変更や処理(決済や振込など)が起こり得る可能性が否定できず、利用者保護の観点で問題があり、利用者が安心してサービスを選択・利用することができません。

この課題に対応するための技術として「OAuth 2.0」が利用されます。利用者はサービスAがサービスBのどのデータや操作を行なうかを画面上で確認し、明示的に同意(アクセス認可)することで、利用者が意図する限定されたデータや操作のみをサービスAに提供することが可能となります。

FinTech分野では、全国銀行協会が事務局となり取りまとめが行われた「オープンAPIのあり方に関する検討会報告書」の中で、OAuth 2.0の利用を前提とした「アクセス権限の付与(認可)」と、その際の「説明・表示、同意取得」の必要性が明示されており、それを実現するシステムコンポーネントが「API連携認証システム」という名称で掲載されています。

金融グレードのAPI仕様「FAPI (Financial-grade API)」

FinTechの動きを受け、金融APIの仕様策定の動きが盛んになっています。その検討ワーキンググループとして、OpenID Foundation の Financial-grade API WG があります。

API仕様の中では、Security Profileとして金融API向けにOAuth 2.0を実装するための仕様の策定が進められています。その中では、鍵やトークンの長さ、パラメータの使い方、リクエストやデータの検証方法など、具体的な指定がなされていることが特徴です。

現在 (2018年11月1日現在)は3つの仕様が実装者向け仕様として公開されている段階にあります。


  • Financial-grade API -- Part 1: Read Only API Security Profile
  • Financial-grade API -- Part 2: Read & Write API Security Profile
  • Financial-grade API -- JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)

このワーキンググループと仕様では、もともと Financial API という名称が使われていましたが、2018年夏ごろに Financial-grade API へと名称が変更されており、金融以外の分野への適応も視野に入れられていることが伺えます。

一方で公開するAPIすべてが金融グレードである必要はありません。APIで提供される機能、情報のリスクを評価し、高いレベルのセキュリティが必要な場合は、FAPIの仕様を参照して実装するのが良いでしょう。


FAPIのProfileは主に金融API向け


オープンAPIを提供するにあたり、前章のライフサイクル管理、本章の認証・認可など必要な技術は専門的かつ多岐にわたります。また、それぞれの技術標準や仕様は日々進化しており、個別に追従する事は困難です。API公開には導入コンサルティングサービスやソリューションを活用し、こうした特別なノウハウを必要とする作業を外部へ委託することで、APIサービスの中身充実や短期間でのサービス提供が可能になります。次章では、これらのサービスやソリューションについて解説します。

全5回シリーズ
「今すぐAPIを公開したい」と言われたシステム担当者が取り組むべき三つのこと

関連サービス