お知らせ

野村総合研究所、APIセキュリティ規格「FAPI 2.0」に準拠したID管理ソリューション「Uni-ID Libra」の最新版を提供開始

～金融・医療・公共など、あらゆる産業のAPI連携をより安全かつシンプルに実現～

株式会社野村総合研究所

PDFダウンロード (452KB)

株式会社野村総合研究所（以下「NRI」）は、消費者向けWebサービス事業者に提供するID・アクセス管理ソリューション「Uni-ID Libra」（ユニアイディー・リブラ、以下「本製品」）の最新バージョン（2.12.0）について、APIセキュリティに関する国際規格である「FAPI 2.0」の認定を取得し、本日、提供を開始します。

近年、DXの進展に伴い、企業間でのデータ連携（API連携）はあらゆる産業へと急速に拡大しています。一方で、個人情報や重要データを扱うAPIのセキュリティは、その抜本的な強化が必要になっています。
「Uni-ID Libra」は、顧客IDの統合管理に加え、認証・API認可やプライバシー保護をオールインワンで提供するCIAM（Customer Identity and Access Management）1ソリューションです。本バージョンでは、金融機関レベルの高いセキュリティ要件に対応する「FAPI 2.0」へ準拠したことにより、API連携の安全性を一層強化しました。本製品を利用することで、金融・医療・公共など、あらゆる産業のAPI連携をより安全かつシンプルに実現することが可能です。

金融グレードのAPIセキュリティ標準「FAPI 2.0」

FAPIは、国際標準化団体OpenID Foundationが策定する、APIによるデータ連携を安全に行うための国際的なセキュリティ規格です。国内外のオープンバンキングをはじめ、高度なセキュリティが求められる領域で採用が進んでいます。2025年に正式に仕様が確定した「FAPI 2.0」は、従来のFAPI 1.0に比べ、よりシンプルかつ高い安全性を実現する設計にアップデートされました。
「Uni-ID Libra」はすでにFAPI 1.0の認定を取得していましたが、本バージョンでは、「FAPI 2.0 Security Profile Final」および「FAPI 2.0 Message Signing Final」の2つの仕様について、新たに認定を取得しました。

認定取得した仕様と、本製品の主な機能強化

1. FAPI 2.0 Security Profile Final

OAuth 2.02やOpenID Connect3をベースとした安全なAPI認可のための仕様です。トークンの不正利用防止や認可フローの保護のための機能を強化しました。

2. FAPI 2.0 Message Signing Final

APIでやり取りされるデータの改ざん・否認防止のための仕様です。実際にやり取りするデータの中身が改ざん・すり替えられていないかを証明するための機能が強化されました。

 

「Uni-ID Libra」の詳細は、下記のWebサイトをご参照ください。
https://uni-id.nri.co.jp/service/libra

NRIは、今後も、グローバルな技術動向とお客様のニーズに合わせた製品バージョンアップ・機能追加を行い、安全・安心なデジタル社会の実現に貢献してまいります。

  1. 1CIAM（Customer Identity and Access Management）：顧客（消費者）を対象に、ID情報とアクセス権限を一元的に管理し、安全性と利便性の両立を図る仕組み。
  2. 2OAuth 2.0：OAuthとは、Webサービス間の連携において、外部からのデータやサービスに対するアクセスを、利用者の同意に基づいて認可するための仕様。OAuthに対応したサービス連携では、利用者が外部サービスにIDやパスワードを漏らすことなく、必要最低限のアクセス権限のみを委譲することができる。2012年に策定されたOAuth 2.0が最新バージョン（2026年6月時点）であり、現在はOAuth 2.0の追加仕様やベストプラクティスを統合したOAuth 2.1が公開へ向けて議論中である。
  3. 3OpenID Connect：Webサービスを提供する複数のサイト間で、ユーザーの同意に基づき、ID情報を流通するための標準仕様。ユーザーはOpenID Connect対応サイトに登録したID情報を使って、他のOpenID Connect対応サイトにログインすることが可能となり、利便性の向上につながる。
  4. 4PAR（Pushed Authorization Requests）：認可要求のパラメータを、ブラウザのURL（クエリ文字列）経由ではなく、クライアントから認可サーバーへ直接バックチャンネル（サーバー間通信）で送信（Push）する仕組み。
  5. 5PKCE（Proof Key for Code Exchange）：認可コードの横取り攻撃を防ぐための仕様。
  6. 6CSRF（Cross-Site Request Forgery）：ユーザーがログインしている状態を悪用し、本人の意図しないリクエスト（操作）を強制的に実行させる攻撃手法。
  7. 7MTLS（Mutual-TLS）：サーバーとクライアントが互いに証明書で認証し、発行するアクセストークンをその証明書に紐付けることで、正当な送信者のみがアクセストークンを利用できるようにする仕組み。
  8. 8private_key_jwt方式：OAuth 2.0／OpenID Connectにおけるクライアント認証方式の一つで、クライアントが秘密鍵で署名したJWTを用いて認可サーバーに対し自身の正当性を証明する仕組み。
  9. 9DPoP（Demonstrating Proof of Possession）：アプリケーション層（HTTPヘッダー）で公開鍵暗号を用いてアクセストークンの送信者証明を実現する仕組み。
  10. 10JAR（JWT-Secured Authorization Request）：認可要求のパラメータを従来のクエリ文字列ではなく、JWT（JSON Web Token）を使用して署名・暗号化されたオブジェクト形式にまとめて送信する仕様。
  11. 11JWT（JSON Web Token）：システム間でJSON（JavaScript Object Notation）形式の情報を安全にやり取りするためのデータ規格。
  12. 12JARM（JWT Secured Authorization Response Mode）：認可サーバーが認可応答全体を「JWT」で署名・暗号化して安全に引き渡す仕様。