1. はじめに

1.1. 本書の目的

本ドキュメントは、Trust Idiom SDK（以下本製品）の導入手順および導入に関連する事項を解説しています。本章では、読み進めるにあたって必要になる前提事項などを解説しています。

1.2. 適用範囲

Trust Idiom サービス及び Trust Idiom SDK version 1及び2系 を利用したモバイルアプリケーション開発に適用されます。

1.3. 対象読者

本製品の導入やシステムのバックエンドを担当する開発者を対象としています。

また、本製品はiOS、Androidのモバイルアプリケーションで動作します。導入にあたっては、OSと認証認可の知識が必要です。

2. 用語の定義（本ドキュメントに出てくる用語の説明）

用語

説明

Trust IdiomⓇ

金融機関向けの本人確認済みIDを発行するIDaaS（Identity as a Service）

Trust Idiom SDK

Trust Idiomサービスを利用したモバイルアプリケーションを開発するためのソフトウェア開発キットのこと。

テナント

金融機関およびPay事業者を含む、Trust IdiomⓇを利用する事業者のこと。

TrustID

各テナントのアプリケーション向けに発行するユーザー識別子のこと。

CIBA

Client Initiated Backchannel Authentication。OAuth/OIDCを拡張した、新しいユーザー認証・認可フローに関する仕様。

消費デバイス

認証リクエストを送信し、API連携フローを開始するデバイス。

Confidentialクライアント

セキュアなクライアント認証が可能なクライアント。ここでのセキュアとは、クライアント認証に関わる情報を安全に管理できることを指す。

Publicクライアント

クライアント認証に関わる情報を安全に管理できないクライアント。モバイルアプリ、SPA、デスクトップアプリなどが相当する。

FAPI

Financial-grade API。OAuth/OIDC を拡張し、APIアクセスに必要な情報（アクセストークン）の不正取得・利用を防止するためのしくみなどを定めた仕様。

mTLS

TLS相互認証。TLSはクライアントがサーバーの身元を検証する仕組みであるが、相互TLSではサーバー・クライアントが相互に認証できる仕組みとなっており、高いセキュリティ要件を満たす際に用いられる。

FIDO UAF

Fast IDentity Online Universal Authentication Framework。FIDO Allianceが策定する生体認証プロトコル。

本人確認

口座開設などにおいて「その手続きを行っている人が本人かどうか」を確認する作業。

3. Trust Idiomサービスとは

3.1. サービス概要

Trust IdiomⓇは、金融機関向けの本人確認済みIDを発行するIDaaS（ID as A Service）です。これまで、金融機関がPayment事業者と連携する際には、それぞれ個別に身元確認を実施した上で、当人認証に金融機関側で事前登録された秘密情報（暗証番号を含む）を利用する形式が多く見られました。こうした認証方法において、悪意ある攻撃等により当人認証情報が外部に漏洩してしまい、本人ではない第三者が口座を不正利用する事象が市場の問題となっています。この問題に対し、全国銀行協会より「資金移動業者等との口座連携に関するガイドライン」（資金移動業者等との口座連携に関するガイドラインの策定について | 令和2年 | 一般社団法人 全国銀行協会 ）が発行されるなど、金融機関はその対応を求められている状況となっています。

Trust IdiomⓇは、生体認証を活用した身元確認及び当人認証を実施することでPayment事業者側・金融機関側双方が抱える問題を解決します。

3.2. システム構成図

Trust IdiomⓇ を導入するにあたるアプリケーション及びバックエンドサービスの構成について解説します。

Trust IdiomⓇ が提供する生体認証を活用した身元確認を行うにあたり、生体認証自体の実施はモバイル OS プラットフォーム (iOS または Android) の標準機能を利用します。自社サービスで各プラットフォームの生体認証機能を使用するためにはモバイルアプリを経由する必要があるため*、各金融機関で Trust IdiomⓇ 導入するには専用のモバイルアプリに対して Trust IdiomⓇ SDK を組み込む必要があります。

Trust IdiomⓇ を導入することで、Trust IdiomⓇ への各ユーザーのアカウント作成、口座との紐付け、Trust IdiomⓇ SDK を経由した生体認証情報の登録および認証、金融機関サービスで身元確認に利用できるアクセストークンの発行を行うことができます。以下に口座振込の中で身元確認を行うフローの例を示します。

  1. ユーザーは金融機関に口座を登録する。

  2. ユーザーは Trust IdiomⓇ に TrustID (アカウント) を作成する。TrustID に生体認証情報を登録する。

  3. ユーザーは TrustID と口座の連携を申請する。金融機関審査担当者は口座連携システム上で申請内容を確認し承認する。

  4. ユーザーは Trust IdiomⓇ SDK が導入されたアプリ内で生体認証を行い Trust IdiomⓇ 認証・認可サーバーからアクセストークンを発行する。

  5. ユーザーは金融機関のConfidentialクライアントに口座振込リクエストを行う。

  6. 金融機関のリソースサーバーはアクセストークンの検証を行った上で口座振込を実施する。

SDK全体概要図

*Web ブラウザ経由で生体認証を利用することができる技術(WebAuthn / FIDO2)もありますが、Trust IdiomⓇ では現時点で未サポートです。

3.3. 技術要素の概要

3.3.1. FAPI-CIBA

FAPI-CIBAとはCIBAにFAPIのセキュリティプロファイルを適用した仕様です。 クライアント証明書を紐付けた送信者限定のアクセストークンを発行することで、アクセストークンだけではAPIの利用ができなくなります。

fapi ciba

3.3.2. FIDO UAF

パスワードレス認証を実現するプロトコルです。FIDO UAF対応デバイスを用いて、早く・安全なユーザー認証を行うことができます。対応デバイスでローカル認証(生体認証、PIN認証等)を行った後に、個人を特定する情報を含まない形でサーバーでの認証を行うため、ユーザビリティを損なうことなく、より安全なユーザー認証が可能となります。

fido uaf

4. RPの実装

4.1. アーキテクチャ

CIBAフローはConfidentialクライアントのみ利用が可能です。

消費デバイスがSingle Page Application（以下、SPA）などのPublicクライアントに該当する場合、Backend For Frontend (以下、BFF) Proxyのアーキテクチャを採用する必要があります。

BFFでクライアント証明書などのシークレット情報を保持します。

4.1.1. 参考

ベストプラクティス

4.2. セキュリティ考慮事項

4.2.1. トークン管理

トークンの管理はConfidentialクライアントで行います。

Confidentialクライアントにトークンを保持することで、アクセストークンの漏洩を防ぐことができます。

消費デバイスがSPAの場合、SPAで実行されるコードとConfidentialクライアントとの間の接続のセキュリティは、ブラウザーレベルの保護メカニズムを利用することを前提としています。

参考

OWASP

5. FAPI-CIBAユースケース

具体的なユースケースとして、インターネットバンキングのウェブサービスから送金をする場合などが想定されます。

この場合、消費デバイスがインターネットバンキングのウェブサービスとなります。

fapi ciba usecase

6. 提供方法

6.1. 認可サーバー

6.1.1. 提供API

FIDO および CIBA の仕様を満たすバックエンドサービスを提供します。主な API は次の通りです。

  • OpenID Configurationエンドポイント

  • バックチャンネル認証エンドポイント

  • トークンエンドポイント

  • JWKsエンドポイント

  • トークンイントロスペクションエンドポイント

利用時にOpenID Configurationエンドポイントにリクエストして各エンドポイントのURIとサポート機能を確認してください。

6.2. クライアントSDK

Trust Idiom/IDサービスは、モバイルアプリ向けの SDK を提供しています。詳細については SDKガイド を参照してください。