JP6463803B2 - サービス管理システム及びサービス管理方法 - Google Patents

サービス管理システム及びサービス管理方法 Download PDF

Info

Publication number
JP6463803B2
JP6463803B2 JP2017123222A JP2017123222A JP6463803B2 JP 6463803 B2 JP6463803 B2 JP 6463803B2 JP 2017123222 A JP2017123222 A JP 2017123222A JP 2017123222 A JP2017123222 A JP 2017123222A JP 6463803 B2 JP6463803 B2 JP 6463803B2
Authority
JP
Japan
Prior art keywords
service
server
api
user
url
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017123222A
Other languages
English (en)
Other versions
JP2019008525A (ja
Inventor
光伸 大久保
光伸 大久保
健太 松島
健太 松島
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mizuho Bank Ltd
Original Assignee
Mizuho Bank Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mizuho Bank Ltd filed Critical Mizuho Bank Ltd
Priority to JP2017123222A priority Critical patent/JP6463803B2/ja
Publication of JP2019008525A publication Critical patent/JP2019008525A/ja
Application granted granted Critical
Publication of JP6463803B2 publication Critical patent/JP6463803B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

本発明は、APIを利用したサービスを提供するためのサービス管理システム及びサービス管理方法に関する。
今日、銀行が保有している顧客に関する金融情報の利用促進を図るために、他のシステムとの連携が検討されている(例えば、非特許文献1)。このような銀行システムから情報を取得するための銀行APIの公開も検討されている(例えば、非特許文献2)。ここで、銀行API(Application Programming Interface)とは、残高照会や資金移動等、既存機能を個別にサービス化して、外部のアプリケーションから利用するために、ソフトウェアコンポーネントが互いにやり取りするために使用するインターフェースである。このような銀行APIを公開することにより、モバイル端末を中心とした顧客金融行動を早期にキャッチアップできる。更に、非金融機関との連携により新規市場の創出も期待できる。
また、事業者に対して、APIを利用して会計処理を支援する技術も検討されている(例えば、特許文献1)。この文献に記載された会計処理装置は、ウェブサーバと、ウェブサーバとVPN技術により接続されたDBと、DBとVPN技術により接続されたスクレイピングサーバとを備える。ウェブサーバは、スクレイピングサーバにより取り込んだウェブ明細データを取引ごとに識別し、各取引を、各取引の取引内容の記載に基づいて、特定の勘定科目に自動的に仕訳する。ウェブサーバは、この際、取引内容の記載を形態素に分節し、各形態素に対応づけられた1又は複数の勘定科目の出現頻度を参照して、取引内容の記載が表す勘定科目を推測する。
特開2016−21147号公報
株式会社みずほ銀行、「LINEでかんたん残高照会」、[online]、株式会社みずほ銀行ホームページ、[平成29年5月28日検索]、インターネット<http://www.mizuhobank.co.jp/net_shoukai/line/index.html> 全国銀行協会、「現代的な「金融業」のあり方」、2016年3月、[online]、金融調査研究会、[平成29年5月28日検索]、インターネット<http://www.zenginkyo.or.jp/fileadmin/res/news/news280341_1.pdf>
オープンAPIにおいてURLが解放された場合、URLが流出し、DoS(Denial of Service attack)やDDoS(Distributed Denial of Service attack)等の攻撃の対象になる可能性がある。また、このオープンAPIにおいては、通信可能なIPアドレス及びクライアント証明書を用いてアクセス制御することが基本であるが、パブリッククラウドのIPアドレスなど、広く解放せざる得ないケースも想定される。
オープンAPIにおいては、ID及びパスワードがハッシュ化されてトークンとして固定されるOAuth認証が用いられることがある。この場合、例えば、振込と住所変更が同じアクセス権範囲(スコープ)に設定される等、API提供者による誤ったスコープ設定に起因する改ざんリスクも発生する。この場合、期限付きのアクセストークンを顧客が発行するような仕組みが必要となる。
上記課題を解決するサービス管理システムは、ワンタイムURLを管理する管理サーバと、サービスを提供するAPIを有するAPI中継サーバと、前記サービスを利用するサービスサーバを備える。そして、前記管理サーバが、ユーザの本人認証に基づいて、前記API中継サーバにアクセスするためのワンタイムURLを発行し、ユーザ情報に関連付けてワンタイムURLをURL記憶部に記録し、ユーザ情報とともに前記ワンタイムURLを前記サービスサーバに提供し、サービス要求を受け付けるサービスサーバが、ユーザの本人認証を行ない、前記ユーザのユーザ情報に関連付けられたワンタイムURLを用いて、前記API中継サーバに対して、サービス要求を送信する。
本発明によれば、APIを利用したサービス提供において、安全性を高めることができる。
本実施形態のシステム概略図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。
以下、図1〜図3に従って、サービス管理システム及びサービス管理方法を具体化した一実施形態を説明する。本実施形態では、API中継サーバを介して、金融機関が提供するサービスを利用する場合を想定する。
図1に示すように、本実施形態では、ユーザ端末10、管理サーバ20、銀行サーバ30、サービスサーバ40、API中継サーバ50を用いる。
ユーザ端末10は、金融機関(銀行)が提供するサービスを利用する顧客が用いるコンピュータ端末である。このユーザ端末10は、サービスサーバ40から取得した情報を利用して、銀行との間で取引を行なう。ユーザ端末10は、情報を入力するための入力部や情報を出力するための表示部を備える。
管理サーバ20は、ユーザ端末10からAPI中継サーバ50のアクセスを支援するコンピュータシステムである。この管理サーバ20は、API中継サーバ50にアクセスするためのURLを生成する。本実施形態では、ワンタイムURLを用いる。このワンタイムURLは、限られた時間或いは回数でリクエストを受け付ける。これにより、アクセス制限されたリソースに対しての未承認アクセスをより困難にすることができる。この管理サーバ20は、制御部21、URL記憶部22を備えている。
図1に示す制御部21は、制御手段(CPU、RAM、ROM等)を備え、後述する処理(URL管理段階、ユーザ認証段階、URL確認段階等の各処理等)を行なう。そのためのサービス管理プログラムを実行することにより、制御部21は、URL管理部211、ユーザ認証部212、URL確認部213として機能する。
URL管理部211は、ワンタイムURLを管理する処理を実行する。
ユーザ認証部212は、ワンタイムURLを利用するユーザを認証する処理を実行する。
URL確認部213は、ワンタイムURLの有効性を確認する処理を実行する。
URL記憶部22には、ユーザに付与したワンタイムURLに関するURL管理レコードが記録される。URL管理レコードは、ワンタイムURLを生成した場合に記録される。このURL管理レコードには、ワンタイムURL、ステータス、ユーザID、アクセストークンに関するデータが記録される。
ワンタイムURLデータ領域には、各ユーザに付与したワンタイムURLに関するデータが記録される。
ステータスデータ領域には、ワンタイムURLの有効性を判定するためのフラグが記録される。具体的には、ユーザ認証を完了した場合、ワンタイムURLを有効にするために、認証完了フラグが記録される。
ユーザIDデータ領域には、ワンタイムURLを付与したユーザを特定するための識別子に関するデータが記録される。
アクセストークンデータ領域には、各ユーザの認証(ここでは、OAuth認証)において用いられる認証情報に関するデータが記録される。
銀行サーバ30は、利用者の口座を管理する銀行のコンピュータシステムである。この銀行サーバ30は、顧客情報記憶部32、口座情報記憶部33を備えている。
顧客情報記憶部32には、銀行の顧客である利用者に関する情報を管理するための顧客管理レコードが記録される。この顧客管理レコードは、顧客登録が行なわれた場合に記録される。顧客管理レコードには、ユーザID、パスワード、口座番号、取引状況に関する情報が記録される。
ユーザIDデータ領域には、各顧客を特定するための識別子に関するデータが記録される。
パスワードデータ領域には、この顧客を認証するために用いられるパスワードに関するデータが記録される。
口座番号データ領域には、この顧客が保有している口座に関する情報が記録されている。
取引状況データ領域には、この顧客と銀行との取引状況(例えばローン残高)等の情報が記録される。
口座情報記憶部33には、銀行の顧客の口座に関する情報を管理するための口座管理レコードが記録される。この口座管理レコードは、口座が開設された場合に登録される。この口座管理レコードには、口座番号、入出金履歴、残高に関する情報が記録される。
口座番号データ領域には、この口座を特定するための識別子に関する情報が記録される。
入出金履歴データ領域には、この口座への入金やこの口座からの出金に関する情報(入出金日時、金額、入出金先口座等)に関するデータが含まれる。
残高データ領域には、この口座の現在の残高に関する情報が記録される。
サービスサーバ40は、ユーザ端末10に対して、金融サービスを提供するサービスプロバイダ(いわゆるFintech企業)のコンピュータシステムである。サービスサーバ40は、ユーザ端末10からのアクセスに応じて、API中継サーバ50を介して、銀行サーバ30から各種情報を取得し、この情報を加工や編集を行なって、ユーザ端末10に提供する。このサービスサーバ40は、ユーザ情報記憶部42を備える。
ユーザ情報記憶部42には、ユーザのワンタイムURLに関するユーザ管理レコードが記録される。ユーザ管理レコードは、ユーザ登録が行なわれた場合に記録される。このユーザ管理レコードには、アクセストークン、ワンタイムURLに関するデータを含んで構成される。
アクセストークンデータ領域には、各ユーザの認証(ここでは、OAuth認証)において用いられる認証情報に関するデータが記録される。
ワンタイムURLデータ領域には、各ユーザに付与したワンタイムURLに関するデータが記録される。
API中継サーバ50は、ユーザ端末10やサービスサーバ40からのアクセスに応じて、顧客の口座に関する情報を提供するコンピュータシステムである。このAPI中継サーバ50は、ファサードAPI51、業務API52を備えている。ここで、各APIは、銀行サーバ30における情報連携を行なうためのアプリケーションサービスインターフェースである。
ファサードAPI51は、複数の業務API52のインターフェースとなるAPIである。
業務API52は、銀行サーバ30における各種業務と連携するAPIである。業務には、銀行サーバ30の口座情報記憶部33に記録された口座管理情報を用いて、利用者の取引についての決済を行なう振込等がある。
次に、図2〜図3に従って、上記のように構成されたシステムにおいて実行される処理手順について説明する。
(サービス利用前処理)
まず、図2を用いて、サービス利用前処理を説明する。この処理は、ユーザ端末10を用いて、管理サーバ20で取引を行なう前に実行される。
ここでは、ユーザ端末10は、事前認証開始処理を実行する(ステップS1−1)。具体的には、ユーザは、ユーザ端末10を用いて、管理サーバ20にアクセスする。
この場合、管理サーバ20の制御部21は、ワンタイムURLの仮確保処理を実行する(ステップS1−2)。具体的には、制御部21のURL管理部211は、API中継サーバ50にアクセス可能なワンタイムURLを生成する。そして、URL管理部211は、生成したワンタイムURLを記録したURL管理レコードを生成し、URL記憶部22に記録する。
次に、管理サーバ20の制御部21は、認証要求処理を実行する(ステップS1−3)。具体的には、制御部21のユーザ認証部212は、ユーザ端末10に対して、セッション情報を含めた認証要求を送信する。
この場合、ユーザ端末10は、認証画面の表示処理を実行する(ステップS1−4)。具体的には、ユーザ端末10は、表示部に認証画面を出力する。この認証画面には、ユーザID、パスワードを入力するためのユーザ設定欄が設けられている。
次に、ユーザ端末10は、認証情報の入力処理を実行する(ステップS1−5)。具体的には、ユーザは、認証画面に、銀行サーバ30を利用するためのユーザID、パスワードを入力する。そして、ユーザ端末10は、セッション情報を含めた認証情報を管理サーバ20に送信する。認証情報には、認証画面に入力されたユーザID、パスワードに関するデータを含める。
次に、管理サーバ20の制御部21は、認証依頼処理を実行する(ステップS1−6)。具体的には、制御部21のユーザ認証部212は、ユーザ端末10から認証情報を受信し、銀行サーバ30に対して、セッション情報を含めた認証依頼を送信する。この認証依頼には、ユーザ端末10から取得したユーザID、パスワードに関するデータを含める。
次に、銀行サーバ30は、認証処理を実行する(ステップS1−7)。具体的には、銀行サーバ30は、認証依頼に含まれるユーザID、パスワードが、顧客情報記憶部32に登録されているかどうかを確認する。ユーザID、パスワードが記録された顧客管理レコードを抽出した場合には、認証を完了する。そして、銀行サーバ30は、セッション情報を含めた認証結果を管理サーバ20に返信する。この認証結果には、認証を完了した場合には完了フラグを設定し、認証を完了できなかった場合にはエラーフラグを設定する。
次に、管理サーバ20の制御部21は、認証完了かどうかについての判定処理を実行する(ステップS1−8)。具体的には、制御部21のユーザ認証部212は、銀行サーバ30から取得した認証結果に基づいて、認証完了か否かを判定する。ここでは、完了フラグが設定された認証結果を取得した場合に、認証完了と判定する。
エラーフラグが設定された認証結果を取得し、認証完了でないと判定した場合(ステップS1−8において「NO」の場合)、管理サーバ20の制御部21は、ワンタイムURLの解放処理を実行する(ステップS1−9)。具体的には、制御部21のユーザ認証部212は、セッション情報に基づいて、このユーザ端末10に割り当てたワンタイムURLを特定し、URL記憶部22に記録されているURL管理レコードを削除する。
一方、完了フラグが設定された認証結果を取得し、認証完了と判定した場合(ステップS1−8において「YES」の場合)管理サーバ20の制御部21は、ワンタイムURLのユーザとの関連付け処理を実行する(ステップS1−10)。具体的には、制御部21のユーザ認証部212は、URL記憶部22に記録されたURL管理レコードにおいて、ワンタイムURLに関連付けて、ステータスとして認証完了フラグを記録するとともに、認証を完了したユーザIDを記録する。
次に、管理サーバ20の制御部21は、トークン及びワンタイムURLの提供処理を実行する(ステップS1−11)。具体的には、制御部21のユーザ認証部212は、ユーザIDを暗号化した固有コードを含めたアクセストークンを生成する。このアクセストークンにより、OAuth認証において利用者を特定することができる。ユーザ認証部212は、URL管理レコードにおいて、ワンタイムURLに関連付けて、アクセストークンを記録する。そして、ユーザ認証部212は、リダイレクト要求をユーザ端末10に送信する。このリダイレクト要求には、アクセストークン及びワンタイムURL、リダイレクト先アドレスに関するデータを含める。
次に、ユーザ端末10は、リダイレクト処理を実行する(ステップS1−12)。具体的には、リダイレクト要求を受信したユーザ端末10は、サービスサーバ40にアクセスする。この場合、ユーザ端末10は、管理サーバ20から取得したアクセストークン及びワンタイムURLをサービスサーバ40に転送する。
次に、サービスサーバ40は、ワンタイムURLの保存処理を実行する(ステップS1−13)。具体的には、サービスサーバ40は、リダイレクトにより取得したワンタイムURLを、アクセストークンに関連付けてユーザ情報記憶部42に登録する。そして、サービスサーバ40は、ユーザ端末10に対して、事前認証完了メッセージを送信する。
次に、ユーザ端末10は、完了表示処理を実行する(ステップS1−14)。具体的には、ユーザ端末10は、表示部に、事前認証を完了したことを示すメッセージを出力する。
(サービス利用時の処理)
次に、図3を用いて、サービス利用時の処理を説明する。
まず、ユーザ端末10は、ログイン要求処理を実行する(ステップS2−1)。具体的には、ユーザは、サービスサーバ40を利用する場合、アクセス画面を出力する。このアクセス画面には、ユーザの生体情報の読取指示を含める。この場合、ユーザは、ユーザ端末10の認証デバイスを用いて、生体情報の読取操作を行なう。そして、ユーザ端末10は、ログイン要求を、サービスサーバ40に送信する。このログイン要求には、生体認証に基づいて特定されたアクセストークンを含める。
次に、サービスサーバ40は、アクセストークンの取得処理を実行する(ステップS2−2)。具体的には、サービスサーバ40は、ユーザ端末10から、アクセストークンを含めたログイン要求を取得する。
次に、サービスサーバ40は、ログイン処理を実行する(ステップS2−3)。具体的には、サービスサーバ40は、ユーザ端末10から取得したアクセストークンが、ユーザ情報記憶部42に記録されているかどうかを確認する。アクセストークンが、ユーザ情報記憶部42に記録されている場合には、ログインを許可し、サービスメニュー画面をユーザ端末10に返信する。なお、アクセストークンが、ユーザ情報記憶部42に記録されていない場合には、ログインを拒否して、エラーメッセージをユーザ端末10に返信する。
次に、ユーザ端末10は、サービス要求処理を実行する(ステップS2−4)。具体的には、ログインが許可された場合、ユーザは、サービスメニュー画面において、所望のサービスを選択する。例えば、サービスとしては、振込処理依頼等がある。この場合、ユーザ端末10は、サービスメニュー画面において選択されたサービスについてのサービス要求をサービスサーバ40に送信する。
次に、サービスサーバ40は、ワンタイムURLの特定処理を実行する(ステップS2−5)。具体的には、サービスサーバ40は、ユーザ情報記憶部42から、アクセストークンに関連付けられたワンタイムURLを取得する。
次に、サービスサーバ40は、ワンタイムURLにアクセス処理を実行する(ステップS2−6)。具体的には、サービスサーバ40は、ワンタイムURLに対して、サービス要求を送信する。
次に、API中継サーバ50は、URL照会処理を実行する(ステップS2−7)。具体的には、API中継サーバ50のファサードAPI51は、管理サーバ20に対して、URL照会要求を送信する。このURL照会要求には、サービスサーバ40から取得したワンタイムURLを含める。
URL照会要求を取得した管理サーバ20の制御部21は、ワンタイムURLの確認処理を実行する(ステップS2−8)。具体的には、制御部21のURL確認部213は、URL照会要求のワンタイムURLのステータスを確認する。ここで、URL記憶部22において、ワンタイムURLに対して、認証完了フラグ、ユーザIDが関連付けられている場合には、ワンタイムURLは有効と判定する。一方、ワンタイムURLに対して、ユーザIDが関連付けられていない場合には、ワンタイムURLは無効と判定する。そして、URL確認部213は、API中継サーバ50に確認結果を返信する。この確認結果には、ワンタイムURLの有効フラグ又は無効フラグを含める。
次に、API中継サーバ50は、ワンタイムURLの妥当性の検証処理を実行する(ステップS2−9)。具体的には、API中継サーバ50のファサードAPI51は、管理サーバ20から取得した確認結果に基づいて、ワンタイムURLの妥当性を検証する。ここでは、有効フラグを含む確認結果を取得した場合には、ワンタイムURLは妥当と判定する。
一方、無効フラグを含む確認結果を取得した場合には、ファサードAPI51は、ワンタイムURLは妥当でないと判定し、サービスサーバ40に対して、エラーメッセージを返信する。この場合、サービスサーバ40はユーザ端末10に対して、サービスを利用できないことを示すメッセージを返信する。
ワンタイムURLは妥当と判定したAPI中継サーバ50は、業務APIコール処理を実行する(ステップS2−10)。具体的には、API中継サーバ50のファサードAPI51は、サービスサーバ40からのサービス要求に応じた業務API52を呼び出す。
次に、API中継サーバ50は、サービス依頼処理を実行する(ステップS2−11)。具体的には、API中継サーバ50の業務API52は、銀行サーバ30に対してサービス要求を送信する。
次に、銀行サーバ30は、サービス処理を実行する(ステップS2−12)。具体的には、銀行サーバ30は、サービス要求に基づいて、サービス処理(例えば、口座情報記憶部33を用いた振込処理)を実行する。そして、銀行サーバ30は、処理結果をAPI中継サーバ50に返信する。
次に、API中継サーバ50は、結果取得処理を実行する(ステップS2−13)。具体的には、API中継サーバ50のファサードAPI51は、銀行サーバ30から、サービス処理結果を取得する。
次に、API中継サーバ50は、業務APIコール処理を実行する(ステップS2−14)。具体的には、API中継サーバ50のファサードAPI51は、業務API52を呼び出し、サービス処理結果をサービスサーバ40に返信する。
次に、サービスサーバ40は、処理結果の送信処理を実行する(ステップS2−15)。具体的には、サービスサーバ40は、サービス処理結果に基づいて、サービス要求を更新する。そして、サービスサーバ40は、ユーザ端末10に対して、処理結果を送信する。
次に、ユーザ端末10は、完了表示処理を実行する(ステップS2−16)。具体的には、ユーザ端末10は、サービスサーバ40から取得した処理結果を、表示部に出力する。
本実施形態によれば、以下のような効果を得ることができる。
(1)本実施形態では、管理サーバ20の制御部21は、ワンタイムURLの仮確保処理を実行する(ステップS1−2)。認証完了と判定した場合(ステップS1−8において「YES」の場合)管理サーバ20の制御部21は、ワンタイムURLのユーザとの関連付け処理を実行する(ステップS1−10)。これにより、ユーザ認証に基づいて、ワンタイムURLを付与することができる。
(2)本実施形態では、管理サーバ20の制御部21は、トークン及びワンタイムURLの提供処理を実行する(ステップS1−11)。ユーザ端末10は、リダイレクト処理を実行する(ステップS1−12)。サービスサーバ40は、ワンタイムURLの保存処理を実行する(ステップS1−13)。これにより、サービスサーバ40は、API中継サーバ50にアクセスするためのワンタイムURLを取得することができる。
(3)本実施形態では、サービスサーバ40は、ワンタイムURLの特定処理(ステップS2−5)、ワンタイムURLにアクセス処理(ステップS2−6)を実行する。この場合、API中継サーバ50は、URL照会処理を実行する(ステップS2−7)。ワンタイムURLを用いることにより、外部から、業務API52への攻撃を抑制することができる。
また、上記実施形態は以下のように変更してもよい。
・上記実施形態では、URL記憶部22には、ユーザに付与したワンタイムURLに関するURL管理レコードが記録される。このURL管理レコードには、ワンタイムURL、ステータス、ユーザID、アクセストークンに関するデータが記録される。ここで、ワンタイムURLに利用条件を設定してもよい。利用条件としては、例えば、利用上限金額を用いることができる。この場合、URL管理レコードに、利用条件として利用上限金額、ステータスとして利用金額の累積額を記録する。そして、API中継サーバ50は、ワンタイムURLの妥当性の検証処理(ステップS2−9)において、サービス要求に係る利用金額を管理サーバ20に送信する。この場合、管理サーバ20の制御部21は、ワンタイムURLの確認処理(ステップS2−8)において、URL確認部213は、利用金額を加算した利用金額の累積額を算出する。そして、URL確認部213は、URL記憶部22に記録された利用金額の累積額が利用上限金額に達していないかどうかを確認する。ここで、利用金額の累積額が利用上限金額に達していない場合に、URL確認部213は、URL記憶部22のURL管理レコードにおいて利用金額の累積額を更新し、ワンタイムURLの有効フラグを含めた確認結果を返信する。一方、利用金額の累積額が利用上限金額を超える場合、URL確認部213は、ワンタイムURLの無効フラグを含めた確認結果を返信する。
また、利用条件として、有効期間を用いてもよい。この場合には、URL確認部213は、現在日時を特定し、この現在日時が有効期間に含まれる場合に、URL確認部213は、ワンタイムURLの有効フラグを含めた確認結果を返信する。一方、現在日時が有効期間に含まれない場合、URL確認部213は、ワンタイムURLの無効フラグを含めた確認結果を返信する。そして、URL管理部211は、有効期間を渡過したURL管理レコードを削除する。
また、利用条件として、利用上限回数を用いてもよい。この場合、URL管理レコードに、利用条件として利用上限回数、ステータスとして利用回数を記録する。そして、管理サーバ20の制御部21は、ワンタイムURLの確認処理(ステップS2−8)において、URL確認部213は、利用回数に「1」を加算した現在回数を算出する。そして、URL確認部213は、現在回数が利用上限回数以下の場合に、URL確認部213は、URL記憶部22のURL管理レコードにおいて利用回数を更新し、ワンタイムURLの有効フラグを含めた確認結果を返信する。一方、利用回数が利用上限回数に達した場合、URL確認部213は、ワンタイムURLの無効フラグを含めた確認結果を返信する。そして、URL管理部211は、利用回数が利用上限回数に達したURL管理レコードを削除する。
また、利用条件として、利用可能時間帯を用いてもよい。この場合には、現在時刻が利用可能時間帯に含まれる場合に、URL確認部213は、ワンタイムURLの有効フラグを含めた確認結果を返信する。一方、現在時刻が利用可能時間帯に含まれない場合、URL確認部213は、ワンタイムURLの無効フラグを含めた確認結果を返信する。
また、利用条件として、取引種別を用いてもよい。この場合、管理サーバ20の制御部21は、サービスサーバ40に対して、取引種別毎に異なるワンタイムURLを提供する。
・上記実施形態では、ユーザ端末10は、事前認証開始処理を実行する(ステップS1−1)。ユーザ端末10が、この処理を、定期的に実行するようにしてもよい。この場合には、ワンタイムURLの有効期間を決めておき、有効期間の経過を検知したユーザ端末10が事前認証開始処理を実行する。
・上記実施形態では、管理サーバ20の制御部21は、ワンタイムURLの仮確保処理を実行する(ステップS1−2)。ここでは、ユーザ毎にワンタイムURLをURL記憶部22に記録する。このワンタイムURLは、ユーザ毎に付与する場合に限定されるものではない。例えば、所定の有効期間は同じワンタイムURLを付与してもよい。
・上記実施形態では、管理サーバ20の制御部21は、トークン及びワンタイムURLの提供処理を実行する(ステップS1−11)。これに代えて、ワンタイムURLの特定処理(ステップS2−5)において、サービスサーバ40が管理サーバ20にアクセスし、アクセストークンに関連付けられた有効なワンタイムURLを取得するようにしてもよい。ここで、URL記憶部22に、アクセストークンに関連付けられた有効なワンタイムURLが記録されていない場合には、サービスサーバ40はサービス提供を拒否する。この場合には、サービスサーバ40のユーザ情報記憶部42にワンタイムURLを保持させることなく、ワンタイムURLによりAPI中継サーバ50にアクセスできる。
・上記実施形態では、金融機関が提供するAPIサービスにおいて、ワンタイムURLを用いる。ワンタイムURLの適用対象は、銀行APIに限定されるものではない。
10…ユーザ端末、20…管理サーバ、21…制御部、22…URL記憶部、211…URL管理部、212…ユーザ認証部、213…URL確認部、30…銀行サーバ、32…顧客情報記憶部、33…口座情報記憶部、40…サービスサーバ、42…ユーザ情報記憶部、50…API中継サーバ、51…ファサードAPI、52…業務API。

Claims (4)

  1. ユーザの本人認証を行なうための認証情報及びユーザ識別情報を保持するAPIサービス提供サーバと、ユーザに付与したワンタイムURLを管理する管理サーバと、サービスを提供するAPIを有するAPI中継サーバと、前記サービスを利用するサービスサーバを含むサービス管理システムであって、
    前記管理サーバが、ユーザ端末からユーザの本人認証を行なうための認証情報及びユーザ識別情報を取得し、前記認証情報及びユーザ識別情報を含めた認証依頼を前記APIサービス提供サーバに送信し、
    前記管理サーバが、前記APIサービス提供サーバにおいて前記認証情報を用いたユーザの本人認証に基づいて認証完了結果を取得した場合、前記API中継サーバにアクセスするためのワンタイムURLを発行し、前記ユーザ識別情報に関連付けて前記ワンタイムURL、サービス利用上限をURL記憶部に記録し、
    前記ユーザ識別情報に対応したアクセストークンとともに前記ワンタイムURLを前記サービスサーバに提供し、
    サービス要求を受け付けサービスサーバが、前記アクセストークンを用いて、ユーザの本人認証を行ない、前記アクセストークンに関連付けられたワンタイムURLを用いて、前記API中継サーバに対して、前記APIサービス提供サーバにおけるサービス内容を含めたサービス要求を送信し、
    前記サービス要求を受信した前記API中継サーバが、前記サービス内容を含めた前記ワンタイムURLの妥当性の確認要求を前記管理サーバに送信し、
    前記管理サーバは、前記確認要求のサービス内容が、前記ワンタイムURLに関連付けられたサービス利用上限を超えたと判定した場合、前記サービス要求を拒否する確認結果を、前記API中継サーバを介して前記サービスサーバに返信することを特徴とするサービス管理システム。
  2. 前記管理サーバにおいて、前記ワンタイムURLに関連付けて、有効期間を記録し、
    サービス要求を受け付けたサービスサーバが、ワンタイムURLの確認要求を前記管理サーバに送信し、
    前記管理サーバは、前記ワンタイムURLの有効期間を経過した場合には、前記ワンタイムURLの利用を拒否する確認結果を前記サービスサーバに返信することを特徴とする
    請求項に記載のサービス管理システム。
  3. 前記API中継サーバは、前記管理サーバから前記ワンタイムURLの妥当性の確認結果を取得できた場合に、前記APIサービス提供サーバにアクセスするAPIコールを行なうことを特徴とする請求項1又は2に記載のサービス管理システム。
  4. ユーザの本人認証を行なうための認証情報及びユーザ識別情報を保持するAPIサービス提供サーバと、ユーザに付与したワンタイムURLを管理する管理サーバと、サービスを提供するAPIを有するAPI中継サーバと、前記サービスを利用するサービスサーバを含むサービス管理システムを用いて、サービス提供を管理する方法であって、
    前記管理サーバが、ユーザ端末からユーザの本人認証を行なうための認証情報及びユーザ識別情報を取得し、前記認証情報及びユーザ識別情報を含めた認証依頼を前記APIサービス提供サーバに送信し、
    前記管理サーバが、前記APIサービス提供サーバにおいて前記認証情報を用いたユーザの本人認証に基づいて認証完了結果を取得した場合、前記API中継サーバにアクセスするためのワンタイムURLを発行し、前記ユーザ識別情報に関連付けて前記ワンタイムURL、サービス利用上限をURL記憶部に記録し、
    前記ユーザ識別情報に対応したアクセストークンとともに前記ワンタイムURLを前記サービスサーバに提供し、
    サービス要求を受け付けサービスサーバが、前記アクセストークンを用いて、ユーザの本人認証を行ない、前記アクセストークンに関連付けられたワンタイムURLを用いて、前記API中継サーバに対して、前記APIサービス提供サーバにおけるサービス内容を含めたサービス要求を送信し、
    前記サービス要求を受信した前記API中継サーバが、前記サービス内容を含めた前記ワンタイムURLの妥当性の確認要求を前記管理サーバに送信し、
    前記管理サーバは、前記確認要求のサービス内容が、前記ワンタイムURLに関連付けられたサービス利用上限を超えたと判定した場合、前記サービス要求を拒否する確認結果を、前記API中継サーバを介して前記サービスサーバに返信することを特徴とするサービス管理方法。
JP2017123222A 2017-06-23 2017-06-23 サービス管理システム及びサービス管理方法 Active JP6463803B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017123222A JP6463803B2 (ja) 2017-06-23 2017-06-23 サービス管理システム及びサービス管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017123222A JP6463803B2 (ja) 2017-06-23 2017-06-23 サービス管理システム及びサービス管理方法

Publications (2)

Publication Number Publication Date
JP2019008525A JP2019008525A (ja) 2019-01-17
JP6463803B2 true JP6463803B2 (ja) 2019-02-06

Family

ID=65026017

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017123222A Active JP6463803B2 (ja) 2017-06-23 2017-06-23 サービス管理システム及びサービス管理方法

Country Status (1)

Country Link
JP (1) JP6463803B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7302193B2 (ja) * 2019-02-15 2023-07-04 株式会社リコー 情報処理装置
JP6750063B1 (ja) * 2019-03-29 2020-09-02 みずほ情報総研株式会社 サービス管理システム及びサービス管理方法
JP6663531B1 (ja) * 2019-08-31 2020-03-11 株式会社北洋銀行 電子マネーのチャージ方法及び電子マネー支援システム
JP6795218B1 (ja) * 2019-10-11 2020-12-02 株式会社ライトスタッフ 保険情報管理システムおよび保険情報管理方法、保険情報管理プログラム、並びにそのプログラムを記録したコンピュータ読み取り可能な記録媒体
JP7262378B2 (ja) * 2019-12-05 2023-04-21 株式会社日立製作所 認証認可システムおよび認証認可方法
WO2023277962A1 (en) 2021-06-28 2023-01-05 Dropbox, Inc. Links platform-as-a-service

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6668641B2 (ja) * 2015-08-27 2020-03-18 ブラザー工業株式会社 中継装置及び通信システム

Also Published As

Publication number Publication date
JP2019008525A (ja) 2019-01-17

Similar Documents

Publication Publication Date Title
JP6463803B2 (ja) サービス管理システム及びサービス管理方法
US20210398111A1 (en) Method And System For Transmitting Credentials
US20230230055A1 (en) Processing a payment, by a secure computing system, from a payer to a payee operating a merchant computing system
US10360561B2 (en) System and method for secured communications between a mobile device and a server
US9407622B2 (en) Methods and apparatus for delegated authentication token retrieval
CA2748481C (en) System and method for initiating transactions on a mobile device
US9596237B2 (en) System and method for initiating transactions on a mobile device
JP5850587B1 (ja) 個人情報口座バンキング
RU2438172C2 (ru) Способ и система для осуществления двухфакторной аутентификации при транзакциях, связанных с заказами по почте и телефону
US20150135279A1 (en) Personal identity control
US11868920B2 (en) Authentication platform for pin debit issuers
US20120150748A1 (en) System and method for authenticating transactions through a mobile device
US20150046327A1 (en) Server-based payment system
JP6643374B2 (ja) サービス管理システム及びサービス管理方法
US20160034891A1 (en) Method and system for activating credentials
US20170230351A1 (en) Method and system for authenticating a user
WO2010140876A1 (en) Method, system and secure server for multi-factor transaction authentication
GB2513126A (en) Method and system for creating a unique identifier
US20150066766A1 (en) Secure Generation of a User Account in a Service Server
JP6255070B1 (ja) 銀行サービスシステム及び銀行サービス方法
JP6009521B2 (ja) 利用者特定システム、方法、およびプログラム
WO2016166715A1 (en) Systems and methods for executing payment transactions
KR20080083731A (ko) 소프트 폰을 이용하여 신용카드의 결제를 처리하는 방법 및시스템
MASSOTH et al. PERFORMANCE OF AN NFC-BASED MOBILE AUTHENTICATION AND Payment SERVICE CONCEPT COMPARED WITH TRADITIONAL SOLUTIONS

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181102

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181204

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190104

R150 Certificate of patent or registration of utility model

Ref document number: 6463803

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250