本稿はJCB Advent Calendar 2024の12月14日の記事です。

3-Dセキュアにおける認証取引の仕組み解説

JCB デジタルソリューション開発部アプリチームの村井です。
アプリチームではJCBが提供する様々なサービスの開発・運用をしています。
今回は非対面のクレジットカード決済で導入が進んでいる3-Dセキュア（本人認証サービス）について、各システムの動きにフォーカスして認証取引の主な仕組みを紹介します。

3-Dセキュアの認証取引の仕組みは、提唱元であるEMVCoのサイトから公式ドキュメントをダウンロードできます。本記事では公式ドキュメントの内容を噛み砕いて解説します。

そもそも3-Dセキュアって何？という方は過去の記事もご覧ください。

認証取引

認証取引の概要を図示します。

JCBではDSシステムを運用しています。また、アクワイアラドメインで稼働するシステムが3DSS（3D Secure Server）、イシュアドメインで稼働するシステムがACS（Access Control Server）です。 3-Dセキュア認証の始点となる加盟店システムも存在します。

認証取引は主に2段階あり、1段階目をリスクベース認証、2段階目をチャレンジ認証と呼びます。必ず2段階の認証するわけではなく、リスクベース認証のみで認証取引が完結する場合と、チャレンジ認証まで実行する場合があります。 3-Dセキュア利用者目線での違いとしては、3-Dセキュアのパスワード入力画面やワンタイムパスワード入力画面が表示された場合はチャレンジ認証が実行されています。一方で認証画面が表示されず決済処理画面に遷移した場合はリスクベース認証のみで認証取引が完結しています。リスクベース認証およびチャレンジ認証を行うのはイシュアドメインのACSです。

認証取引が完了すると3DSSが結果情報を同じアクワイアラドメインのオーソリ用ホストに連携し、認証OKの場合は決済処理に進みます。

フリクションレスフロー

リスクベース認証のみで認証取引が完結する場合の処理フローをフリクションレスフローと呼びます。以下に概要を図示します。

フリクションレスフローは利用者のアクションを必要としないため、3DSS、DS、ACSの3システムで処理が完結します。フリクションレスフローでやり取りされる電文をA電文と呼び、A電文には加盟店システムから受け取ったカード利用者の情報に加えて3DSS/ACSの情報が含まれます。

A電文は以下の流れで処理されます。

3DSSがA電文リクエスト（以降、AReq）をDSに送信します。
DSが受信したAReqを検証します。送信元3DSSの正当性や電文の各種設定値が規定通りであるか等を検証します。
DSがAReqをACSに送信します。
ACSが受信したAReqを検証します。このタイミングでACSがリスクベース認証処理を行います。リスクベース認証結果がOKとなる場合はフリクションレスフローで認証取引が完結します。NGとなる場合はAReqの内容によって後述するチャレンジフローに派生するか、あるいはこの時点で認証失敗となります。
ACSがA電文レスポンス（以降、ARes）をDSに送信します。AResにはリスクベース認証結果やチャレンジ認証の必要有無を設定します。
DSが受信したAResを検証します。送信元ACSの正当性や電文の各種設定値が規定通りであるか等を検証します。
DSがAResを3DSSに送信します。
3DSSが受信したAResを検証します。これでA電文の処理が完了します。

リスクベース認証の内容やチャレンジ認証を実行するかどうかの判定基準は各ACSによって異なります。

チャレンジフロー

チャレンジ認証まで実行する場合の処理フローをチャレンジフローと呼びます。以下に概要を図示します。

チャレンジフローは先述のフリクションレスフローの4.にてチャレンジ認証が必要と判断された場合に、AResに設定されたチャレンジ認証用の設定値を引き続く形で追加電文のやり取りが行われます。チャレンジフローにおいて追加でやり取りされる電文をC電文およびR電文と呼び、C電文にはチャレンジ認証（各種パスワード認証）の実行のための情報が、R電文にはその結果情報が含まれます。

チャレンジフローにおけるC電文およびR電文は以下の流れで処理されます。(A電文の流れは省略しています)

0.まずは準備として、3DSSがAResからチャレンジ認証実行用の各種項目を取り出し、C電文を作成します。

3DSSが加盟店システムを経由してC電文リクエスト（以降、CReq）をACSに送信します。
ACSが受信したCReqを検証します。CReqの各種設定値が規定通りであるか等を検証します。
ACSが加盟店システムに対してチャレンジ認証用の画面を表示します。
加盟店システムが(利用者の入力した)チャレンジ認証情報をACSに送信します。
ACSが受信したチャレンジ認証情報を検証します。ここで入力されたパスワード等が正しいかを判定します。
ACSがR電文リクエスト（以降、RReq）をDSに送信します。RReqにはチャレンジ認証結果を設定します。
DSが受信したRReqを検証します。ここでも送信元ACSの正当性や電文の各種設定値が規定通りであるか等を検証します。
DSがRReqを3DSSに送信します。
3DSSが受信したRReqを検証します。
3DSSがR電文レスポンス（以降、RRes）をDSに送信します。RResの目的は3DSSがチャレンジ認証結果を受け取ったことをACSに伝達することです。
DSが受信したRResを検証します。
DSがRResをACSに送信します。
ACSが受信したRResを検証します。
ACSが加盟店システムに対してC電文レスポンス（以降、CRes）を送信します。CResの目的はチャレンジ認証が終了したことを加盟店側システムに伝達することです。