Webアプリ統合
このページでは、Web & SDK契約のクライアントサイド統合方法として、ユーザーをUnicoホスト型ジャーニーにリダイレクトする方法と、iFrame SDKでジャーニーを埋め込む方法の2つを説明します。
- ユーザーをリダイレクトする
- iFrame
プロセス作成後、レスポンスにはUnicoホスト型ジャーニーを指すURLが含まれます。このURLを使用してユーザーをキャプチャ体験へ誘導してください。この遷移を管理する方法は2つあります。
1. 標準リダイレクト
ユーザーをジャーニーURLに直接リダイレクトします。ユーザーがプロセスを完了すると、Unicoはプロセス作成時に指定したURLにユーザーをリダイレクトします。
2. window.open() を使った新しいタブ
ジャーニーを新しいブラウザタブで開き、ユーザーを別のコンテキストに保ちます。返却URLへのURL変更を監視し、プロセス完了時にタブを閉じます。
window.open() APIの詳細については、MDNドキュメントを参照してください。
このドキュメントの標準に従わない統合は予期しない中断を引き起こす可能性があり、Unicoサポートの対象外となります。
サポートされていないアプローチの例：WebView内へのSDKの埋め込み、またはHTMLタグから直接iFrameを読み込む方法。
開始方法
ステップ 1 — インストール
by Unico SDKはIDPayと同じパッケージを使用します。
npm install idpay-b2b-sdk
特定バージョンを固定せずにインストールすることで、パッケージマネージャーが常に最新のマイナーおよびパッチリリースを自動的に取得します。
開始前に、Unicoサポートチームにドメインを登録してください。すべてのドメインはHTTPSを使用する必要があります。
ステップ 2 — init(options) を呼び出す
SDKを初期化してアセットを事前読み込みし、エンドユーザーへのよりスムーズな体験を実現します。フローの可能な限り早い段階で呼び出してください。
| パラメータ | 必須 | 説明 |
|---|---|---|
type | はい | by Unicoフロー用に 'IFRAME' を設定 |
token | はい | Create Process APIが返すプロセストークン |
env | いいえ | テスト環境のみ 'uat' を設定 |
import { ByUnicoSDK } from "idpay-b2b-sdk";
ByUnicoSDK.init({
type: 'IFRAME',
token,
// env: 'uat' // only for test environments
});
ステップ 3 — open(options) を呼び出す
事前読み込み済みのiFrameを表示し、ページとUnicoジャーニー間のメッセージフローを開始します。
| パラメータ | 必須 | 説明 |
|---|---|---|
transactionId | はい | Create Process APIが返すプロセスID |
token | はい | Create Process APIが返すプロセストークン |
onFinish | はい | ジャーニー終了または閉じられたときに実行されるコールバック |
onFinish コールバックは、トランザクションID、リダイレクトURL、および完了タイプを含むプロセスオブジェクトを受け取ります。
ByUnicoSDK.open({
transactionId: '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf',
token: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...',
onFinish: (process) => {
console.log('Process finished', process);
// process.transaction.redirectUrl — use this to navigate the user
},
});
// To close the SDK explicitly at any point:
ByUnicoSDK.close();
以下のシーケンス図は、SDKおよびAPI結果を使用してiFrameを設定する方法を示しています。
セキュリティ
CSPの代わりに認証トークンを使ったiFrameソリューションを採用する
慎重な分析の結果、Content Security Policy (CSP) を実装するのではなく、認証トークン付きのiFrameを使用するアプローチが選択されました。この決定は、セキュリティ要件とクライアントのニーズに対応するために必要な柔軟性によって動機付けられています。
CSPの背景と課題
Content Security PolicyはXSSやコードインジェクション攻撃からWebアプリケーションを保護する強力なツールです。ただし、CSPポリシーの設定には信頼できるドメインの厳密なリストを定義する必要があります。このアプローチはドメインが固定かつ予測可能な場合には有効ですが、動的かつ可変なドメインを使用するクライアントにとって、この硬直した設定は大きな課題となります。
動的ドメインに伴う脆弱性
CSPを使用する際、動的ドメインは重大なセキュリティリスクをもたらします。クライアントが頻繁に変更または動的に作成されるドメインを持つ場合、CSPポリシーは新しいドメインを含めるよう常に更新する必要があります。これはメンテナンスの負担を増大させるだけでなく、適切に管理されなければポリシーに列挙されたすべてのドメインが潜在的な攻撃対象となるリスクを生じさせます。
iFrameと認証トークンを使ったソリューション
これらのリスクを軽減し、クライアントに必要な柔軟性を満たすために、選択されたソリューションはiFrameと認証トークンを組み合わせており、静的なドメインリストを必要とせずに追加のセキュリティ層を提供します。
仕組み：
- セキュアな認証 — 各iFrameはトランザクションごとに一意の認証トークンで読み込まれ、承認されたユーザーのみがコンテンツにアクセスできることを保証します。トークンはリアルタイムで検証されます。
- コンテンツの分離 — iFrameは別個のブラウジングコンテキストで実行され、異なるオリジン間の干渉リスクを低減し、潜在的な攻撃を軽減します。
- 動的ドメインへの柔軟な対応 — 静的CSPポリシーに依存しないことで、ポリシーの継続的な更新を必要とせず、動的なクライアントドメインに適応します。