特許 7558443 成りすまし防止システムおよびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-09-19

(45)【発行日】2024-09-30

(54)【発明の名称】成りすまし防止システムおよびプログラム

(51)【国際特許分類】

   G06F 21/31 20130101AFI20240920BHJP

   G06F 21/44 20130101ALI20240920BHJP

【ＦＩ】

G06F21/31

G06F21/44

【請求項の数】 4

(21)【出願番号】P 2024064271

(22)【出願日】2024-04-11

【審査請求日】2024-05-10

(73)【特許権者】

【識別番号】596108508

【氏名又は名称】株式会社大和総研

(74)【代理人】

【識別番号】100114638

【弁理士】

【氏名又は名称】中野 寛也

(72)【発明者】

【氏名】近藤 智朗

(72)【発明者】

【氏名】林 亮輔

(72)【発明者】

【氏名】神戸 梨沙

【審査官】三森 雄介

(56)【参考文献】

【文献】特開２０１７－１４２６１９（ＪＰ，Ａ）

【文献】特表２０２２－５１８６３８（ＪＰ，Ａ）

【文献】特開２０１７－４９９２７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１４／００７５５１６（ＵＳ，Ａ１）

【文献】中国特許出願公開第１１２０８７３６７（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／００－２１／８８

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

社員によるＡＰＩ（Application Programming Interface：アプリケーション・プログラミング・インターフェース）の利用時の他の社員への成りすましを防止する処理を実行するコンピュータにより構成された成りすまし防止システムであって、
ＩＤトークンを発行するオープンＩＤプロバイダシステム内で、各社員を識別する社員ＩＤと、この社員ＩＤを部分的に含んで構成されるオープンＩＤプロバイダ用のユーザ名とを関連付けて記憶するユーザ情報記憶手段と、
社員によるＡＰＩの利用の受付および管理を行うＡＰＩ基盤システム内で、前記社員ＩＤと、各社員に払い出された社員毎のクライアントＩＤおよびクライアントシークレットとを関連付けて記憶するＡＰＩ利用対象者情報記憶手段と、
前記社員ＩＤを用いて社員がログインしたクライアント端末から、認可コード発行リクエストを、ネットワークを介して前記オープンＩＤプロバイダシステムに送信する認可コード発行リクエスト送信手段と、
前記認可コード発行リクエストを受信した前記オープンＩＤプロバイダシステム内で、前記クライアント端末から、前記ログインに用いられた前記社員ＩＤを、ネットワークを介して受信し、認可コードを発行してこの認可コードを前記社員ＩＤと関連付けて認可コード発行情報記憶手段に記憶させるとともに、発行した前記認可コードを、ネットワークを介して前記クライアント端末に送信する認可コード発行手段と、
前記クライアント端末で、前記認可コード発行手段により前記オープンＩＤプロバイダシステムからネットワークを介して送信されてくる認可コードを受信する認可コード受信手段と、
この認可コード受信手段により受信した前記認可コードを含むトークン発行リクエストを、前記クライアント端末からネットワークを介して前記オープンＩＤプロバイダシステムに送信するトークン発行リクエスト送信手段と、
前記トークン発行リクエストを受信した前記オープンＩＤプロバイダシステム内で、前記トークン発行リクエストに含まれる前記認可コードを用いて前記認可コード発行情報記憶手段から前記社員ＩＤを取得し、取得した前記社員ＩＤを用いて前記ユーザ情報記憶手段から前記ユーザ名を取得し、取得した前記ユーザ名を含むＩＤトークンを発行し、発行した前記ＩＤトークンを、ネットワークを介して前記クライアント端末に送信するトークン発行手段と、
前記クライアント端末で、前記トークン発行手段により前記オープンＩＤプロバイダシステムからネットワークを介して送信されてくる前記ＩＤトークンを受信するトークン受信手段と、
前記クライアント端末に搭載されたクライアントアプリケーションで入力を受け付けて前記クライアント端末に記憶されているか、または前記クライアントアプリケーションのプログラム内に記述されているクライアントＩＤおよびクライアントシークレット、並びに、前記トークン受信手段により受信した前記ＩＤトークンを含むＡＰＩリクエストを作成し、前記クライアント端末から、作成した前記ＡＰＩリクエストを、ネットワークを介して前記ＡＰＩ基盤システムに送信するＡＰＩ呼出手段と、
前記ＡＰＩ基盤システム内で、受信した前記ＡＰＩリクエストに設定された前記ＩＤトークンに含まれる前記ユーザ名から前記社員ＩＤを切り取り、切り取った前記社員ＩＤを、前記ＡＰＩリクエストに設定する社員ＩＤ設定手段と、
前記ＡＰＩ基盤システム内で、前記ＡＰＩリクエストに設定された前記クライアントＩＤと関連付けられて前記ＡＰＩ利用対象者情報記憶手段に記憶されている前記社員ＩＤと、前記ＡＰＩリクエストに設定された前記社員ＩＤとが一致しているか否かを判断し、一致していない場合に、他の社員への成りすましが行われていると判断する成りすましチェック手段と
を備えたことを特徴とする成りすまし防止システム。

【請求項2】

前記社員ＩＤ設定手段は、
前記クライアント端末から受信した前記ＡＰＩリクエストに前記ＩＤトークンが設定されていない場合には、認証エラーが発生した旨の情報を、ネットワークを介して前記クライアント端末に送信する処理も実行する構成とされている
ことを特徴とする請求項１に記載の成りすまし防止システム。

【請求項3】

前記ＡＰＩ基盤システムは、
キーＩＤおよびアルゴリズムを記憶するパラメータ記憶手段と、
前記オープンＩＤプロバイダシステムの公開鍵を記憶する公開鍵記憶手段と、
前記パラメータ記憶手段に記憶された前記キーＩＤおよび前記アルゴリズムと、前記ＡＰＩリクエストのヘッダに含まれる前記ＩＤトークン内の前記キーＩＤおよび前記アルゴリズムとが一致しているか否かを検証するとともに、前記ＡＰＩリクエストのヘッダに含まれる前記ＩＤトークン内の署名と、前記公開鍵記憶手段に記憶された前記公開鍵とを用いて、前記ＩＤトークンが前記オープンＩＤプロバイダシステムにより発行されたものであるか否かを検証するトークン検証手段と
を備えたことを特徴とする請求項２に記載の成りすまし防止システム。

【請求項4】

請求項１～３のいずれかに記載の成りすまし防止システムとして、コンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、社員によるＡＰＩ（Application Programming Interface：アプリケーション・プログラミング・インターフェース）の利用時の他の社員への成りすましを防止する処理を実行するコンピュータにより構成された成りすまし防止システムおよびプログラムに係り、例えば、各社員がクライアントアプリケーションを搭載したクライアント端末から業務ＡＰＩを利用してバックエンドシステムの各種のデータにアクセスし、業務処理を行う場合等に利用できる。

【背景技術】

【0002】

従来、社員がＡＰＩを実行する際には、各社員は、クライアントアプリケーションを搭載したクライアント端末（例えば、会社から配布されている２ｉｎ１端末等）に、社員ＩＤおよびパスワードを用いてログインし、クライアントＩＤおよびクライアントシークレットという２つの認証情報を用いて、ゲートウェイサーバを有するＡＰＩ基盤システムを経由してバックエンドシステムの各種のデータにアクセスし、必要な業務処理を行っている。

【0003】

上記のクライアントＩＤおよびクライアントシークレットは、社員によるＡＰＩの実行を可能にするために、ＡＰＩ利用対象者である社員１人１人に、ＡＰＩ基盤システムから払い出され、ＡＰＩ基盤システムに記憶されている。そして、各人に払い出されたクライアントＩＤおよびクライアントシークレットは、各人の管理となっている。従って、各社員は、自分に払い出されたクライアントＩＤおよびクライアントシークレットをリクエストパラメータ（ヘッダ）に設定してＡＰＩのリクエストを行っている。

【0004】

なお、本発明では、後述するように、クライアントＩＤおよびクライアントシークレット以外の情報として、オープンＩＤプロバイダが発行するＩＤトークンを利用してＡＰＩ実行時のクライアントＩＤが実行者本人のものであることのチェックを行うが、ＡＰＩおよびＩＤトークンを利用した処理としては、秘匿性の高い電子投票を実現することができる「電子投票管理方法」（特許文献１参照）や、リライングパーティサーバ上でホスティングされているリソースにモバイル装置からアクセスするための方法を提供する「ネイティブモバイルアプリケーション起点のオープンＩＤコネクト（ＯＩＤＣ）フロー及びセキュリティアサーションマークアップ言語（ＳＡＭＬ）フローのためのシームレスなシングルサインオン（ＳＳＯ）のための方法及びシステム」（特許文献２参照）が知られている。

【0005】

また、ＩＤトークンの記載はないが、ＡＰＩ実行時の社員の成りすましの防止に関連する技術としては、第１サーバ、第３サーバと、第２サーバとが動的共通情報に基づく実行証明情報を生成し、照合することができ、成りすましを防止できる「ネットワーク通信方法及びネットワーク通信システム」（特許文献３参照）、データ放送の受信に利用される受信装置が、不正なデータ放送を受信したとしてもその不正を無効にする技術を提供する「送信装置およびそのプログラム、ならびに、受信装置およびＡＰＩ実行プログラム」（特許文献４参照）、代行処理が行われる際に、代行者が起票した起票伝票の自己承認を抑制することができる代行オペレーションにおける「権限不正使用防止システム」（特許文献５参照）、それぞれ独立して管理されているユーザ情報を統合的に提供することができる「情報提供装置、情報提供方法、情報提供プログラム及び記録媒体、並びにユーザ認証装置、ユーザ認証方法、ユーザ認証プログラム及び記録媒体」（特許文献６参照）が知られている。

【先行技術文献】

【特許文献】

【0006】

【文献】特開２０２２－１０７５５６号公報（段落［００１２］、［００２６］、［００２７］、［００３２］）

【文献】特開２０２０－１２６６０２号公報

【文献】再表２０１６－１５８９０８号公報（段落［００４５］、［００７８］）

【文献】特開２００９－１４７８０８号公報（要約）

【文献】特開２００８－２４３０２３号公報（段落［００２８］）

【文献】特開２００４－３０３２０２号公報（請求項１、段落［０１７０］）

【発明の概要】

【発明が解決しようとする課題】

【0007】

前述したように、ＡＰＩ利用対象者である社員１人１人に払い出されたクライアントＩＤおよびクライアントシークレットは、各人の管理となっている。従って、クライアントＩＤおよびクライアントシークレットが漏洩した場合には、誰でも利用可能な状態となってしまう。

【0008】

このため、悪意のある者が他人のクライアントＩＤおよびクライアントシークレットを入手した場合、他人のクライアントＩＤおよびクライアントシークレットを利用してＡＰＩを実行することで、バックエンドシステムに記憶されている顧客情報などを不正に入手することができ、また、更新系の業務処理を行うＡＰＩの場合は、データを不正に登録・更新・削除することができてしまうという問題があった。

【0009】

本発明の目的は、社員によるＡＰＩ実行時の成りすましを防止することができる成りすまし防止システムおよびプログラムを提供するところにある。

【課題を解決するための手段】

【0010】

本発明は、社員によるＡＰＩ（Application Programming Interface：アプリケーション・プログラミング・インターフェース）の利用時の他の社員への成りすましを防止する処理を実行するコンピュータにより構成された成りすまし防止システムであって、
ＩＤトークンを発行するオープンＩＤプロバイダシステム内で、各社員を識別する社員ＩＤと、この社員ＩＤを部分的に含んで構成されるオープンＩＤプロバイダ用のユーザ名とを関連付けて記憶するユーザ情報記憶手段と、
社員によるＡＰＩの利用の受付および管理を行うＡＰＩ基盤システム内で、社員ＩＤと、各社員に払い出された社員毎のクライアントＩＤおよびクライアントシークレットとを関連付けて記憶するＡＰＩ利用対象者情報記憶手段と、
社員ＩＤを用いて社員がログインしたクライアント端末から、認可コード発行リクエストを、ネットワークを介してオープンＩＤプロバイダシステムに送信する認可コード発行リクエスト送信手段と、
認可コード発行リクエストを受信したオープンＩＤプロバイダシステム内で、クライアント端末から、ログインに用いられた社員ＩＤを、ネットワークを介して受信し、認可コードを発行してこの認可コードを社員ＩＤと関連付けて認可コード発行情報記憶手段に記憶させるとともに、発行した認可コードを、ネットワークを介してクライアント端末に送信する認可コード発行手段と、
クライアント端末で、認可コード発行手段によりオープンＩＤプロバイダシステムからネットワークを介して送信されてくる認可コードを受信する認可コード受信手段と、
この認可コード受信手段により受信した認可コードを含むトークン発行リクエストを、クライアント端末からネットワークを介してオープンＩＤプロバイダシステムに送信するトークン発行リクエスト送信手段と、
トークン発行リクエストを受信したオープンＩＤプロバイダシステム内で、トークン発行リクエストに含まれる認可コードを用いて認可コード発行情報記憶手段から社員ＩＤを取得し、取得した社員ＩＤを用いてユーザ情報記憶手段からユーザ名を取得し、取得したユーザ名を含むＩＤトークンを発行し、発行したＩＤトークンを、ネットワークを介してクライアント端末に送信するトークン発行手段と、
クライアント端末で、トークン発行手段によりオープンＩＤプロバイダシステムからネットワークを介して送信されてくるＩＤトークンを受信するトークン受信手段と、
クライアント端末に搭載されたクライアントアプリケーションで入力を受け付けてクライアント端末に記憶されているか、またはクライアントアプリケーションのプログラム内に記述されているクライアントＩＤおよびクライアントシークレット、並びに、トークン受信手段により受信したＩＤトークンを含むＡＰＩリクエストを作成し、クライアント端末から、作成したＡＰＩリクエストを、ネットワークを介してＡＰＩ基盤システムに送信するＡＰＩ呼出手段と、
ＡＰＩ基盤システム内で、受信したＡＰＩリクエストに設定されたＩＤトークンに含まれるユーザ名から社員ＩＤを切り取り、切り取った社員ＩＤを、ＡＰＩリクエストに設定する社員ＩＤ設定手段と、
ＡＰＩ基盤システム内で、ＡＰＩリクエストに設定されたクライアントＩＤと関連付けられてＡＰＩ利用対象者情報記憶手段に記憶されている社員ＩＤと、ＡＰＩリクエストに設定された社員ＩＤとが一致しているか否かを判断し、一致していない場合に、他の社員への成りすましが行われていると判断する成りすましチェック手段と
を備えたことを特徴とするものである。

【0011】

このような本発明の成りすまし防止システムにおいては、ＩＤトークンの発行のための仕様であるオープンＩＤコネクト（OpenID Connect）の活用により、クライアントＩＤおよびクライアントシークレット以外の情報として、オープンＩＤプロバイダシステムで発行されるＩＤトークンを利用してＡＰＩ実行時のクライアントＩＤが実行者本人のものであることのチェック（社員による成りすましチェック）を行う。

【0012】

すなわち、オープンＩＤプロバイダシステムに設けられたトークン発行手段により、クライアント端末からのトークン発行リクエストを受信した場合に、受信したトークン発行リクエストに含まれる認可コードを用いて認可コード発行情報記憶手段から社員ＩＤを取得し、取得した社員ＩＤを用いてユーザ情報記憶手段からユーザ名（社員ＩＤを部分的に含んで構成されるオープンＩＤプロバイダ用のユーザ名）を取得し、取得したユーザ名を含むＩＤトークンを発行し、発行したＩＤトークンをクライアント端末に送信する。

【0013】

社員がＡＰＩを実行する際には、自分がログインしたクライアント端末で、ＡＰＩ呼出手段により、クライアントＩＤおよびクライアントシークレット、並びにＩＤトークンを含むＡＰＩリクエストを作成し、作成したＡＰＩリクエストを、クライアント端末からＡＰＩ基盤システムに送信する。

【0014】

ＡＰＩ基盤システムでは、社員ＩＤ設定手段により、クライアント端末から受信したＡＰＩリクエストに設定されたＩＤトークンに含まれるオープンＩＤプロバイダ用のユーザ名（このユーザ名は、社員ＩＤを部分的に含んでいる。）から社員ＩＤを切り取り、切り取った社員ＩＤを、ＡＰＩリクエストに設定する。

【0015】

そして、ＡＰＩ基盤システム内で、成りすましチェック手段により、ＡＰＩリクエストに設定されたクライアントＩＤと関連付けられてＡＰＩ利用対象者情報記憶手段に記憶されている社員ＩＤと、ＡＰＩリクエストに設定された社員ＩＤ（オープンＩＤプロバイダ用のユーザ名から切り取った社員ＩＤ）とが一致しているか否かを判断し、一致していない場合に、他の社員への成りすましが行われていると判断する。

【0016】

このため、他の社員への成りすましを行う不正行為者である社員が、自分（不正行為者自身）の社員ＩＤと、不正に入手した他の社員のクライアントＩＤおよびクライアントシークレットとを使ってＡＰＩを実行しようとしても、成りすましチェック手段により、その不正行為が発覚することになる。つまり、ＡＰＩリクエストに設定された社員ＩＤは、端末ログインを行った不正行為者自身の社員ＩＤであり、一方、不正に入手した他の社員のクライアントＩＤと関連付けられてＡＰＩ利用対象者情報記憶手段に記憶されている社員ＩＤは、他の社員の社員ＩＤであるから、一致しないので、成りすましの行為を見つけることができる。

【0017】

よって、不正行為者である社員が、バックエンドシステムに記憶されている顧客情報などを不正に入手することを防止することが可能となり、また、更新系の業務処理を行うＡＰＩの場合は、不正行為者である社員が、データを不正に登録・更新・削除することを防止することが可能となり、これらにより前記目的が達成される。

【0018】

＜ＡＰＩリクエストにＩＤトークンが設定されていない場合に、認証エラーをクライアント端末に送信する構成＞

【0019】

また、前述した成りすまし防止システムにおいて、
社員ＩＤ設定手段は、
クライアント端末から受信したＡＰＩリクエストにＩＤトークンが設定されていない場合には、認証エラーが発生した旨の情報を、ネットワークを介してクライアント端末に送信する処理も実行する構成とされていることが望ましい。

【0020】

このようにＡＰＩリクエストにＩＤトークンが設定されていない場合に、認証エラーをクライアント端末に送信する構成とした場合には、成りすましチェック手段による処理に必要な情報が欠落しているので、成りすましチェック手段による処理に進む前に、不正なＡＰＩの実行を防ぐことが可能となる。

【0021】

＜トークン検証を行う構成＞

【0022】

さらに、上述したＡＰＩリクエストにＩＤトークンが設定されていない場合に、認証エラーをクライアント端末に送信する構成とした場合において、
ＡＰＩ基盤システムは、
キーＩＤおよびアルゴリズムを記憶するパラメータ記憶手段と、
オープンＩＤプロバイダシステムの公開鍵を記憶する公開鍵記憶手段と、
パラメータ記憶手段に記憶されたキーＩＤおよびアルゴリズムと、ＡＰＩリクエストのヘッダに含まれるＩＤトークン内のキーＩＤおよびアルゴリズムとが一致しているか否かを検証するとともに、ＡＰＩリクエストのヘッダに含まれるＩＤトークン内の署名と、公開鍵記憶手段に記憶された公開鍵とを用いて、ＩＤトークンがオープンＩＤプロバイダシステムにより発行されたものであるか否かを検証するトークン検証手段と
を備えた構成とすることが望ましい。

【0023】

このようにトークン検証を行う構成とした場合には、ＩＤトークンがオープンＩＤプロバイダシステムにより発行されたものであるか否かを検証することが可能となり、より一層、セキュリティ機能を向上させることができる。

【0024】

＜プログラムの発明＞

【0025】

そして、本発明のプログラムは、以上に述べた成りすまし防止システムとして、コンピュータを機能させるためのものである。

【0026】

なお、上記のプログラムまたはその一部は、例えば、光磁気ディスク（ＭＯ）、コンパクトディスク（ＣＤ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、フレキシブルディスク（ＦＤ）、磁気テープ、読出し専用メモリ（ＲＯＭ）、電気的消去および書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、フラッシュディスク等の記録媒体に記録して保存や流通等させることが可能であるとともに、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等の有線ネットワーク、あるいは無線通信ネットワーク、さらにはこれらの組合せ等の伝送媒体を用いて伝送することが可能であり、また、搬送波に載せて搬送することも可能である。さらに、上記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。

【発明の効果】

【0027】

以上に述べたように本発明によれば、オープンＩＤコネクト（OpenID Connect）の活用により、クライアントＩＤおよびクライアントシークレット以外の情報として、オープンＩＤプロバイダシステムで発行されるＩＤトークンを利用してＡＰＩ実行時のクライアントＩＤが実行者本人のものであることのチェックを行うので、社員によるＡＰＩ実行時の成りすましを防止することができるという効果がある。

【図面の簡単な説明】

【0028】

【図1】本発明の一実施形態の成りすまし防止システムの全体構成図。

【図2】前記実施形態の成りすまし防止システムの別の全体構成図。

【図3】前記実施形態の成りすまし防止システムの要部を示す構成図。

【図4】前記実施形態の社員によるＡＰＩ実行時の成りすまし防止処理の流れ（その１）.を示すフローチャートの図。

【図5】前記実施形態の社員によるＡＰＩ実行時の成りすまし防止処理の流れ（その２）.を示すフローチャートの図。

【発明を実施するための形態】

【0029】

以下に本発明の一実施形態について図面を参照して説明する。図１および図２には、本実施形態の成りすまし防止システム１０の全体構成が示されている。図３には、成りすまし防止システム１０の要部の構成が示され、図４および図５には、社員によるＡＰＩ実行時の成りすまし防止処理の流れがフローチャートで示されている。

【0030】

＜成りすまし防止システム１０の全体構成＞

【0031】

図１および図２において、成りすまし防止システム１０は、オープンＩＤプロバイダ（OpenID provider）が管理するオープンＩＤプロバイダシステム２０と、ＡＰＩ利用対象者（各社員や、社内の各部署、社内の各システム等）によるＡＰＩの利用の受付および管理を行うＡＰＩ基盤システム３０と、各社員が操作する多数のクライアント端末６０とを備えて構成されている。また、ネットワーク１には、ＡＰＩ利用対象者としての各社員によるＡＰＩの実行に伴って各種の業務処理を実行するバックエンドシステム８０が接続されている。さらに、図示は省略されているが、バックエンドシステム８０のデータを利用するＡＰＩ利用対象者としての他のシステムもネットワーク１に接続されている。

【0032】

ここで、ネットワーク１は、例えばイントラネットやＬＡＮ等により構成された社内の内部ネットワークであるが、有線であるか無線であるか、さらには有線および無線の混在型であるかは問わず、要するに、複数地点（距離の長短は問わない。）間で、ある程度の速度をもって情報を伝送することができるものであればよい。

【0033】

オープンＩＤプロバイダシステム２０は、１台または複数台のコンピュータにより構成され、ＩＤトークンの発行のための仕様であるオープンＩＤコネクト（OpenID Connect）に従った各種の処理を実行する処理手段２０Ａを備え、この処理手段２０Ａは、ログイン処理手段２１と、認可コード発行手段２２と、トークン発行手段２３とを含んで構成されている。また、オープンＩＤプロバイダシステム２０は、処理手段２０Ａによる各種の処理を実行するのに必要な各種のデータを記憶するために、ユーザ情報記憶手段２４と、アプリケーション一覧記憶手段２５と、認可コード発行情報記憶手段２６とを備えている。

【0034】

ここで、処理手段２０Ａに含まれる各手段２１～２３は、オープンＩＤプロバイダシステム２０を構成するコンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段２１～２３の詳細は後述する。

【0035】

また、ユーザ情報記憶手段２４、アプリケーション一覧記憶手段２５、認可コード発行情報記憶手段２６としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。これらの記憶手段２４～２６の詳細は後述する。

【0036】

なお、本実施形態では、オープンＩＤプロバイダシステム２０として、ＡｚｕｒｅＡＤを採用しているが、これに限定されるものではなく、いずれのオープンＩＤプロバイダでも、ＩＤトークンの発行のための仕様であるオープンＩＤコネクト（OpenID Connect）に従った各種の処理を実行することができるので、本発明に適用することができる。

【0037】

ＡＰＩ基盤システム３０は、１台または複数台のコンピュータにより構成され、ゲートウェイサーバ４０と、ＡＰＩ管理サーバ５０とを備えている。これらのゲートウェイサーバ４０と、ＡＰＩ管理サーバ５０とが、それぞれ何台のコンピュータにより構成されるか、あるいは同じ１台のコンピュータで構成されるかは任意である。なお、本実施形態では、ＡＰＩ基盤システム３０には、ＩＢＭ社のＡＰＩコネクト（IBM API Connect）を採用しているが、これに限定されるものではない。

【0038】

ゲートウェイサーバ４０は、ＡＰＩリクエストの受付処理を実行する処理手段４０Ａを備え、この処理手段４０Ａは、プリフロー処理手段４１と、ＡＰＩ定義実行手段４２と、ポストフロー処理手段４３とを含んで構成されている。そして、プリフロー処理手段４１は、ＵＲＬマッチング手段４１Ａと、社員ＩＤ設定手段４１Ｂと、トークン検証手段４１Ｃと、「成りすましチェック手段」を構成する成りすましチェックＡＰＩ呼出手段４１Ｄと、リクエスト構文・サイズチェック手段４１Ｅとを含んで構成されている。また、ＡＰＩ定義実行手段４２は、各種の業務ＡＰＩ定義実行手段４２Ａと、「成りすましチェック手段」を構成する成りすましチェックＡＰＩ実行手段４２Ｂとを含んで構成されている。さらに、ポストフロー処理手段４３は、各種のＡＰＩ事後処理手段４３Ａを含んで構成されている。また、ゲートウェイサーバ４０は、処理手段４０Ａによる各種の処理を実行するのに必要な各種のデータを記憶するために、公開鍵記憶手段４４と、パラメータ記憶手段４５とを備えている。

【0039】

ここで、処理手段４０Ａに含まれる各手段４１（４１Ａ，４１Ｂ，４１Ｃ，４１Ｄ，４１Ｅ），４２（４２Ａ，４２Ｂ），４３（４３Ａ）は、ゲートウェイサーバ４０を構成するコンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段４１（４１Ａ，４１Ｂ，４１Ｃ，４１Ｄ，４１Ｅ），４２（４２Ａ，４２Ｂ），４３（４３Ａ）の詳細は後述する。

【0040】

また、公開鍵記憶手段４４、パラメータ記憶手段４５としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。これらの記憶手段４４，４５の詳細は後述する。

【0041】

ＡＰＩ管理サーバ５０は、ＡＰＩ定義データ送信手段５１と、ＡＰＩ社員利用カタログ記憶手段５２と、ＡＰＩ利用対象者情報送信手段５３と、ＡＰＩ利用対象者情報記憶手段５４とを備えて構成されている。

【0042】

ここで、ＡＰＩ定義データ送信手段５１、ＡＰＩ利用対象者情報送信手段５３は、ＡＰＩ管理サーバ５０を構成するコンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段５１，５３の詳細は後述する。

【0043】

また、ＡＰＩ社員利用カタログ記憶手段５２、ＡＰＩ利用対象者情報記憶手段５４としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。これらの記憶手段５２，５４の詳細は後述する。

【0044】

クライアント端末６０は、コンピュータまたはモバイル機器により構成されている。例えば、各社員に配布されている２ｉｎ１端末等であり、オープンＩＤプロバイダシステム２０（本実施形態では、一例として、ＡｚｕｒｅＡＤ）により端末ログイン認証を行うことができるものであればよい。

【0045】

このクライアント端末６０は、図１に示すように、ＡＰＩの呼出および応答受信を含む各種の処理を実行する処理手段６０Ａを備え、この処理手段６０Ａは、端末ログイン手段６１と、クライアントＩＤ・クライアントシークレット入力受付手段６２と、認可コード発行リクエスト送信手段６３と、認可コード受信手段６４と、トークン発行リクエスト送信手段６５と、トークン受信手段６６と、ＡＰＩ呼出手段６７と、ＡＰＩ応答受信手段６８とを含んで構成されている。また、クライアント端末６０は、処理手段６０Ａによる各種の処理を実行するのに必要な各種のデータを記憶するために、クライアントＩＤ・クライアントシークレット記憶手段７０と、ログイン社員ＩＤ・パスワード記憶手段７１とを備えている。

【0046】

また、クライアント端末６０には、図２に示すように、ＡＰＩの呼出および応答受信を行うクライアントアプリケーション６０Ｂが搭載され、このクライアントアプリケーション６０Ｂには、パイソン（Python）で記述されたアプリケーション６０Ｃと、Ｗｅｂアプリケーション６０Ｄとがある。また、クライアント端末６０には、クライアントアプリケーション６０Ｂによりインポートされるライブラリ６０Ｅが記憶され、このライブラリ６０Ｅには、認可コード発行リクエスト用ライブラリ６０Ｆと、トークン発行リクエスト用ライブラリ６０Ｇと、ＡＰＩ呼出用ライブラリ６０Ｈとがある。これらのライブラリは、オープンＩＤプロバイダシステム２０（本実施形態では、一例として、ＡｚｕｒｅＡＤ）でログイン認証可能な端末での動作を前提としている。

【0047】

ここで、処理手段６０Ａ（図１参照）に含まれる各手段６１～６８は、クライアント端末６０を構成するコンピュータまたはモバイル機器の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム（図２に示したクライアントアプリケーション６０Ｂ、およびクライアントアプリケーション６０Ｂによりインポートされた各種のライブラリ６０Ｅを含む。）、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段６１～６８の詳細は後述する。

【0048】

また、クライアントＩＤ・クライアントシークレット記憶手段７０としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。但し、クライアントＩＤおよびクライアントシークレットは、社員１人１人に払い出されるので、各社員は、自分が操作するクライアント端末６０に搭載されるクライアントアプリケーション６０Ｂのプログラムの中に、自分に払い出されたクライアントＩＤおよびクライアントシークレットを記述（コーディング）しておいてもよい。この記憶手段７０の詳細は後述する。

【0049】

さらに、ログイン社員ＩＤ・パスワード記憶手段７１は、各社員がログインを行った際に入力した社員ＩＤおよびパスワードを一時的に記憶するものであるから、主メモリ（揮発性メモリ）でよいが、不揮発性メモリとしてもよい。この記憶手段７１の詳細は後述する。

【0050】

バックエンドシステム８０は、ＡＰＩ実行者（各社員を含むＡＰＩ利用対象者のうちの実際にＡＰＩを利用した者であり、人間だけではなく、システムも含む。）によるＡＰＩリクエストに応じて各種の業務処理を実行するものであり、１台または複数台のコンピュータにより構成され、各種（図３に示す業務α，β，γ，…）のバックエンド業務処理（例えば、顧客情報の参照対応、金融商品等に係る顧客の売買取引データの登録、更新、削除等）を実行する各種のバックエンド業務処理手段８１と、これらの各種のバックエンド業務処理を実行するのに必要な各種のデータ（顧客情報、売買情報など）を記憶するバックエンド業務処理用データ記憶手段８２とを備えている。

【0051】

ここで、バックエンド業務処理手段８１は、バックエンドシステム８０を構成するコンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。また、バックエンド業務処理用データ記憶手段８２は、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリで実現される。

【0052】

＜オープンＩＤプロバイダシステム２０／処理手段２０Ａ／ログイン処理手段２１の構成＞

【0053】

ログイン処理手段２１は、各社員によるクライアント端末６０でのログイン認証の処理を実行するものである。具体的には、ログイン処理手段２１は、クライアント端末６０で入力されてネットワーク１を介して送信されてくる社員ＩＤおよびパスワード（図２参照）を受信し、受信した社員ＩＤに対応付けてユーザ情報記憶手段２４（図２参照）に記憶されているパスワードと、受信したパスワードとが一致するか否かにより、ログイン認証を行い、一致しない場合には、ログイン認証エラーを、ネットワーク１を介してクライアント端末６０に送信する。

【0054】

＜オープンＩＤプロバイダシステム２０／処理手段２０Ａ／認可コード発行手段２２の構成＞

【0055】

認可コード発行手段２２は、認可コード発行リクエスト送信手段６３によりクライアント端末６０からネットワーク１を介して送信されてくる認可コード発行リクエスト（クライアント端末６０に搭載されたクライアントアプリケーション６０Ｂ（図２参照）を識別するアプリケーションＩＤを含む。）を受信し、クライアント端末６０に対し、端末ログインに用いられた社員ＩＤおよびパスワードの送信要求（取得要求）を、ネットワーク１を介してクライアント端末６０に送信し、クライアント端末６０からネットワーク１を介して送信されてくる社員ＩＤおよびパスワードを受信し、認可コードを発行してこの認可コードを、受信した社員ＩＤと関連付けて認可コード発行情報記憶手段２６に記憶させるとともに、発行した認可コードを、ネットワーク１を介してクライアント端末６０に送信する処理を実行するものである。

【0056】

＜オープンＩＤプロバイダシステム２０／処理手段２０Ａ／トークン発行手段２３の構成＞

【0057】

トークン発行手段２３は、トークン発行リクエスト送信手段６５によりクライアント端末６０からネットワーク１を介して送信されてくるトークン発行リクエスト（認可コード、アプリケーションＩＤ、アプリケーション用シークレットを含む。）を受信し、受信したトークン発行リクエストに含まれるアプリケーションＩＤと対応付けてアプリケーション一覧記憶手段２５に記憶されているアプリケーション用シークレットと、受信したトークン発行リクエストに含まれるアプリケーション用シークレットとが一致しているか否かにより、クライアントアプリケーションが正しいか否かの検証を行い、さらに、受信したトークン発行リクエストに含まれる認可コードを用いて認可コード発行情報記憶手段２６から社員ＩＤを取得し、取得した社員ＩＤを用いてユーザ情報記憶手段２４からユーザ名を取得し、取得したユーザ名を含むＩＤトークン、およびアクセストークンを発行し、発行したＩＤトークンおよびアクセストークンを、ネットワーク１を介してクライアント端末６０に送信する処理を実行するものである。なお、ＩＤトークンは、本発明で効果的に利用される本発明の特徴に係るものであるが、アクセストークンは、本発明の内容に直接関係するものではない。

【0058】

＜オープンＩＤプロバイダシステム２０／ユーザ情報記憶手段２４、アプリケーション一覧記憶手段２５、認可コード発行情報記憶手段２６の構成＞

【0059】

ユーザ情報記憶手段２４は、図２に示すように、社員を識別する社員ＩＤ（例えば、AXXXXXXX）、オープンＩＤプロバイダ用のユーザ名（例えば、[e-mail]であり、部分的に社員ＩＤを含んでいる。）、表示名（本実施形態では、社員の氏名にしている。）、電子メールアドレス、社員が所属する会社名、従業員ＩＤ（社員ＩＤとは異なるもの）、パスワード等を対応付けて記憶するものである。

【0060】

アプリケーション一覧記憶手段２５は、図２に示すように、クライアントアプリケーション毎に、アプリケーションＩＤと、アプリケーション用シークレットとを対応付けて記憶するものである。クライアントアプリケーションには、複数種類のアプリケーションＸ，Ｙ，…がある。

【0061】

認可コード発行情報記憶手段２６は、図２に示すように、発行した認可コードと、社員ＩＤとを対応付けて記憶するものである。

【0062】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／処理手段４０Ａ／プリフロー処理手段４１／ＵＲＬマッチング手段４１Ａの構成＞

【0063】

プリフロー処理手段４１のＵＲＬマッチング手段４１Ａは、ＡＰＩ呼出手段６７によりクライアント端末６０からネットワーク１を介して送信されてくるＡＰＩリクエスト（ヘッダに、クライアントＩＤ、クライアントシークレット、ＩＤトークンが設定されている。）を受信し、ＵＲＬマッチング処理を実行するものである。

【0064】

具体的には、ＵＲＬマッチング手段４１Ａは、受信したＡＰＩリクエストに含まれるＡＰＩのパス（ＵＲＬ）が、ＡＰＩ社員利用カタログのパスであり、かつ、ＨＴＴＰメソッドがＯＰＴＩＯＮＳ以外であるという条件を満たすか否かのチェックを行う。ここで、ＡＰＩ社員利用カタログのパスは、ＡＰＩ社員利用カタログ記憶手段５２に記憶されたデータ（図３に示すように、製品と呼ばれている。）を使用する場合のパスであり、ＵＲＬマッチング手段４１Ａを実現するプログラム内に記述（コーディング）されている。カタログには、ＡＰＩ社員利用カタログ以外のカタログもあるので、そのようなカタログのパスの場合には上記の条件を満たさないことになる。また、ＯＰＴＩＯＮＳ以外というのは、ＧＥＴ、ＰＯＳＴ等のことである。

【0065】

そして、ＵＲＬマッチング手段４１Ａは、上記の条件を満たす場合には、社員ＩＤ設定手段４１Ｂに処理を移行させる。一方、上記の条件を満たさない場合には、リクエスト構文・サイズチェック手段４１Ｅに処理を移行させる。

【0066】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／処理手段４０Ａ／プリフロー処理手段４１／社員ＩＤ設定手段４１Ｂの構成＞

【0067】

プリフロー処理手段４１の社員ＩＤ設定手段４１Ｂは、先ず、クライアント端末６０から受信したＡＰＩリクエストのヘッダにＩＤトークンが設定されていない場合には、認証エラーが発生した旨の情報を、ネットワーク１を介してクライアント端末６０に送信し、次に、ＡＰＩリクエストに含まれるＩＤトークン内のユーザ名から社員ＩＤを切り取り（本実施形態では、図２に示すように、＠の前の部分を切り取る。）、切り取った社員ＩＤを、ＡＰＩリクエストのヘッダに設定する処理を実行するものである。

【0068】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／処理手段４０Ａ／プリフロー処理手段４１／トークン検証手段４１Ｃの構成＞

【0069】

プリフロー処理手段４１のトークン検証手段４１Ｃは、オープンＩＤプロバイダから受け取っている公開鍵およびパラメータ（キーＩＤ、アルゴリズム）を用いて、ＡＰＩリクエストに含まれるＩＤトークンが、オープンＩＤプロバイダシステム２０で発行されたものであるか否かを検証する処理（ＩＤトークンの改ざん検知処理）を実行するものである。

【0070】

具体的には、トークン検証手段４１Ｃは、先ず、ＩＤトークンを、オープンＩＤプロバイダシステム２０でのエンコードで使用されている定義（例えば、base64url）でデコードし、ＩＤトークンのヘッダに含まれている２つのパラメータ（キーＩＤ、アルゴリズム）を、ＪＳＯＮ形式のデータとして内容を把握できる状態にする。ここで、キーＩＤの値は、ＩＤトークンのＪＳＯＮウェブ署名（ＪＷＳ）をセキュア化するために使用されたキーを示す。また、アルゴリズムは、署名のアルゴリズムである。なお、ＩＤトークンには、ヘッダ、ペイロード、署名の各部がある。

【0071】

そして、トークン検証手段４１Ｃは、パラメータ記憶手段４５（図１、図２参照）に記憶されたキーＩＤおよびアルゴリズムと、ＡＰＩリクエストのヘッダに含まれるＩＤトークン内のキーＩＤおよびアルゴリズム（デコードされた状態のキーＩＤおよびアルゴリズム）とが一致しているか否かを検証するとともに、ＡＰＩリクエストのヘッダに含まれるＩＤトークン内の署名（デコードされた状態の署名）と、公開鍵記憶手段４４（図１、図２参照）に記憶された公開鍵とを用いて、ＩＤトークンがオープンＩＤプロバイダシステム２０により発行されたものであるか否かを検証する。

【0072】

また、トークン検証手段４１Ｃは、ＩＤトークンがオープンＩＤプロバイダシステム２０により発行されたものでないと判断した場合には、認証エラーが発生した旨の情報を、ネットワーク１を介してクライアント端末６０に送信する。

【0073】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／処理手段４０Ａ／プリフロー処理手段４１／成りすましチェックＡＰＩ呼出手段４１Ｄの構成：図３＞

【0074】

プリフロー処理手段４１の成りすましチェックＡＰＩ呼出手段４１Ｄは、ＡＰＩ定義実行手段４２の成りすましチェックＡＰＩ実行手段４２Ｂとともに、本発明における「成りすましチェック手段」（請求項に記載された「成りすましチェック手段」）を構成するものである。

【0075】

具体的には、成りすましチェックＡＰＩ呼出手段４１Ｄは、先ず、図３に示すように、成りすましチェックＡＰＩ実行手段４２Ｂに対し、成りすましチェックＡＰＩの呼出処理、すなわち、成りすましチェックＡＰＩリクエスト（ヘッダに、クライアントＩＤ、クライアントシークレット、ユーザ名から切り取った社員ＩＤを設定する。）の送信処理を行うとともに、成りすましチェックＡＰＩ実行手段４２Ｂから送信（返信）されてくる成りすましチェックＡＰＩ応答の受信処理を行う。この際、成りすましチェックＡＰＩリクエストは、元のＡＰＩリクエスト（クライアント端末６０からのＡＰＩリクエスト）のヘッダに設定されているクライアントＩＤに関連付けてＡＰＩ利用対象者情報記憶手段５４に記憶されているＡＰＩ利用対象者ＩＤ（社員ＩＤ）を取得するために実行する。つまり、この場合、成りすましチェックＡＰＩ実行手段４２Ｂから返ってくる成りすましチェックＡＰＩ応答は、ＡＰＩ利用対象者ＩＤ（社員ＩＤ）である。

【0076】

そして、成りすましチェックＡＰＩ呼出手段４１Ｄは、元のＡＰＩリクエスト（クライアント端末６０からのＡＰＩリクエスト）のヘッダに設定されているクライアントＩＤに関連付けてＡＰＩ利用対象者情報記憶手段５４に記憶されているＡＰＩ利用対象者ＩＤ（社員ＩＤ）、つまり、成りすましチェックＡＰＩ実行手段４２Ｂから返ってきた成りすましチェックＡＰＩ応答として得られた社員ＩＤと、元のＡＰＩリクエストのヘッダに設定されている社員ＩＤ（社員ＩＤ設定手段４１ＢによりＩＤトークン内のユーザ名から切り取った社員ＩＤ）とが一致しているか否かにより（一致していることを確認し）、ＡＰＩ実行者が成りすましを行っていないことを検証する。

【0077】

また、成りすましチェックＡＰＩ呼出手段４１Ｄは、ＡＰＩ実行者が成りすましを行っていると判断した場合（一致しなかった場合）には、認証エラーが発生した旨の情報を、ネットワーク１を介してクライアント端末６０に送信する。

【0078】

なお、社員ＩＤとクライアントＩＤとの対応関係が、２系統で得られるが、それらの２系統で得られる対応関係が一致していることを検証できればよい。すなわち、第１の系統として、社員ＩＤ設定手段４１Ｂにより元のＡＰＩリクエスト（クライアント端末６０からのＡＰＩリクエスト）のヘッダに設定されたＩＤトークン内のユーザ名から切り取った社員ＩＤと、元のＡＰＩリクエスト（クライアント端末６０からのＡＰＩリクエスト）のヘッダに設定されたクライアントＩＤとの対応関係が得られる。また、第２の系統として、ＡＰＩ利用対象者情報記憶手段５４に記憶されているＡＰＩ利用対象者情報としてのＡＰＩ利用対象者ＩＤ（社員ＩＤ）と、クライアントＩＤとの対応関係が得られる。

【0079】

従って、成りすましチェックＡＰＩ呼出手段４１Ｄは、成りすましチェックＡＰＩ実行手段４２Ｂから返ってくる成りすましチェックＡＰＩ応答として、社員ＩＤではなく、クライアントＩＤが得られるような、成りすましチェックＡＰＩリクエストを行うようにしてもよい。すなわち、社員ＩＤ設定手段４１Ｂにより元のＡＰＩリクエスト（クライアント端末６０からのＡＰＩリクエスト）のヘッダに設定されたＩＤトークン内のユーザ名から切り取った社員ＩＤに関連付けてＡＰＩ利用対象者情報記憶手段５４に記憶されているクライアントＩＤを取得するために、成りすましチェックＡＰＩリクエストを行ってもよい。この場合、成りすましチェックＡＰＩ呼出手段４１Ｄは、社員ＩＤ設定手段４１Ｂにより元のＡＰＩリクエスト（クライアント端末６０からのＡＰＩリクエスト）のヘッダに設定されたＩＤトークン内のユーザ名から切り取った社員ＩＤに関連付けてＡＰＩ利用対象者情報記憶手段５４に記憶されているクライアントＩＤ、つまり、成りすましチェックＡＰＩ実行手段４２Ｂから返ってきた成りすましチェックＡＰＩ応答として得られたクライアントＩＤと、元のＡＰＩリクエスト（クライアント端末６０からのＡＰＩリクエスト）のヘッダに設定されたクライアントＩＤとが一致しているか否かにより（一致していることを確認し）、ＡＰＩ実行者が成りすましを行っていないことを検証することになる。

【0080】

２系統で得られる社員ＩＤとクライアントＩＤとの対応関係の一致を検証すればよいので、社員ＩＤの一致を確認するか、クライアントＩＤの一致を確認するかは等価である。このため、本発明における「成りすましチェック手段」（請求項に記載された「成りすましチェック手段」）では、社員ＩＤの一致を中心とした記載表現になっているが、クライアントＩＤの一致を確認する場合も、本発明の請求項の記載内容に含まれる。

【0081】

また、成りすましチェックＡＰＩ呼出手段４１Ｄと、成りすましチェックＡＰＩ実行手段４２Ｂとの処理の分担は、以上に述べた分担内容に限定されるものではなく、例えば、以上の説明では、成りすましチェックＡＰＩ呼出手段４１Ｄが、社員ＩＤの一致（またはクライアントＩＤの一致）を検証することになっているが、成りすましチェックＡＰＩ実行手段４２Ｂが社員ＩＤの一致（またはクライアントＩＤの一致）を検証し、その検証結果（一致したか否か）を、成りすましチェックＡＰＩ応答として、成りすましチェックＡＰＩ呼出手段４１Ｄに返すようにしてもよい。

【0082】

よって、成りすましチェックＡＰＩリクエストのヘッダに含める情報は、上述したように、元のＡＰＩリクエストに設定されているクライアントＩＤ、クライアントシークレット、ユーザ名から切り取った社員ＩＤの全部としているが、成りすましチェックＡＰＩ呼出手段４１Ｄと、成りすましチェックＡＰＩ実行手段４２Ｂとの処理の分担の仕方によっては、一部（クライアントＩＤ、ユーザ名から切り取った社員ＩＤのいずれか）としてもよい。

【0083】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／処理手段４０Ａ／プリフロー処理手段４１／リクエスト構文・サイズチェック手段４１Ｅの構成＞

【0084】

プリフロー処理手段４１のリクエスト構文・サイズチェック手段４１Ｅは、クライアント端末６０から受け取ったＡＰＩリクエストについての構文のチェックおよびサイズのチェックを実行するものである。

【0085】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／処理手段４０Ａ／ＡＰＩ定義実行手段４２／業務ＡＰＩ定義実行手段４２Ａの構成＞

【0086】

ＡＰＩ定義実行手段４２における各種の業務ＡＰＩ定義実行手段４２Ａは、リクエスト構文・サイズチェック手段４１Ｅによる処理を経たＡＰＩリクエストに従って、ＡＰＩ管理サーバ５０のＡＰＩ社員利用カタログ記憶手段５２から、ＡＰＩ実行者が要求している業務（図３に示す業務α，β，γ，…のいずれか）についての業務ＡＰＩ定義データ（ヤムルファイル）５２Ａを取得し、取得した業務ＡＰＩ定義データ５２Ａに従って、ＡＰＩ実行者の要求に係る業務処理（ＡＰＩリクエストに設定されている。）を実行するものである。

【0087】

この際、業務ＡＰＩ定義データ（ヤムルファイル）５２Ａには、図３に示すように、業務ＡＰＩ定義実行手段４２Ａにより実行される複数の処理（図３の例では、処理１，２，３，…と記載されている。）が定義され、その中にバックエンドの業務（業務α，β，γ，…のいずれか）の業務処理の呼出が含まれているので、業務ＡＰＩ定義実行手段４２Ａは、バックエンドシステム８０に対し、ネットワーク１を介してＡＰＩ実行者の要求に係る業務処理の呼出を行う。これにより、図３に示すように、バックエンド業務処理手段８１による業務処理（図１に示すバックエンド業務処理用データ記憶手段８２に記憶されたデータを使用する業務処理）が実行され、その業務処理の結果として得られた情報（例えば、顧客情報等）が、バックエンド業務処理手段８１により、バックエンドシステム８０からネットワーク１を介してゲートウェイサーバ４０のポストフロー処理手段４３のＡＰＩ事後処理手段４３Ａに送信され、さらにＡＰＩ事後処理手段４３Ａにより、ネットワーク１を介してクライアント端末６０に送信される。

【0088】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／処理手段４０Ａ／ＡＰＩ定義実行手段４２／成りすましチェックＡＰＩ実行手段４２Ｂの構成：図３＞

【0089】

ＡＰＩ定義実行手段４２の成りすましチェックＡＰＩ実行手段４２Ｂは、プリフロー処理手段４１の成りすましチェックＡＰＩ呼出手段４１Ｄとともに、本発明における「成りすましチェック手段」（請求項に記載された「成りすましチェック手段」）を構成するものである。

【0090】

具体的には、成りすましチェックＡＰＩ実行手段４２Ｂは、図３に示すように、成りすましチェックＡＰＩ呼出手段４１Ｄからの成りすましチェックＡＰＩリクエストを受信し、ＡＰＩ社員利用カタログ記憶手段５２にヤムルファイルとして記憶された成りすましチェックＡＰＩ定義データ５２Ｂに従った処理を実行する。この際、成りすましチェックＡＰＩ実行手段４２Ｂは、ＡＰＩ定義データ送信手段５１（図１参照）に対して成りすましチェックＡＰＩ定義データ５２Ｂの取得要求を送信し、ＡＰＩ定義データ送信手段５１から送信されてくる成りすましチェックＡＰＩ定義データ５２Ｂを受信する。受信したヤムルファイルの成りすましチェックＡＰＩ定義データ５２Ｂには、成りすましチェックＡＰＩ実行手段４２Ｂにより実行される複数の処理（図３では、処理１，２，３，…と記載されている。）が定義され、その中にＡＰＩ利用対象者情の取得という処理が含まれているので、成りすましチェックＡＰＩ実行手段４２Ｂは、ＡＰＩ管理サーバ５０にアクセスし、ＡＰＩ利用対象者情報送信手段５３（図１参照）から送信されてくるＡＰＩ利用対象者情報（成りすましチェックＡＰＩリクエストによる取得要求に係る社員ＩＤ若しくはクライアントＩＤ、または、社員ＩＤおよびクライアントＩＤ）を受信し、受信したＡＰＩ利用対象者情報を、成りすましチェックＡＰＩ呼出手段４１Ｄに送信する。

【0091】

なお、成りすましチェックＡＰＩ呼出手段４１Ｄの説明で既に述べたように、成りすましチェックＡＰＩ実行手段４２Ｂが社員ＩＤの一致（またはクライアントＩＤの一致）を検証してもよいので、その場合には、その検証結果（一致したか否か）を、成りすましチェックＡＰＩ応答として、成りすましチェックＡＰＩ呼出手段４１Ｄに送信することになる。

【0092】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／処理手段４０Ａ／ポストフロー処理手段４３／ＡＰＩ事後処理手段４３Ａの構成＞

【0093】

ポストフロー処理手段４３における各種のＡＰＩ事後処理手段４３Ａは、バックエンドシステム８０からネットワーク１を介して送信されてくる各種（業務α，β，γ，…）の業務処理（バックエンド業務処理手段８１による処理）の結果として得られた情報（例えば、顧客情報等）を受信し、ネットワーク１を介してクライアント端末６０に送信する処理を実行するものである。

【0094】

＜ＡＰＩ基盤システム３０／ゲートウェイサーバ４０／公開鍵記憶手段４４、パラメータ記憶手段４５の構成＞

【0095】

公開鍵記憶手段４４は、トークン検証手段４１Ｃによるトークン検証処理で使用するために、オープンＩＤプロバイダシステム２０から受け取っているオープンＩＤプロバイダの公開鍵を記憶するものである。

【0096】

パラメータ記憶手段４５は、トークン検証手段４１Ｃによるトークン検証処理で使用するために、オープンＩＤプロバイダシステム２０で発行されるＩＤトークンで採用しているパラメータ（キーＩＤおよびアルゴリズムを含む。）を記憶するものである。

【0097】

＜ＡＰＩ基盤システム３０／ＡＰＩ管理サーバ５０／ＡＰＩ定義データ送信手段５１、ＡＰＩ社員利用カタログ記憶手段５２の構成＞

【0098】

ＡＰＩ定義データ送信手段５１（図１参照、但し、図２および図３では記載を省略している。）は、ＡＰＩ定義実行手段４２の各種（業務α，β，γ，…）の業務ＡＰＩ定義実行手段４２Ａからの該当する業務ＡＰＩ定義データ（ヤムルファイル）５２Ａの取得要求に応じ、該当する業務ＡＰＩ定義データ５２Ａ（ＡＰＩ実行者である社員について用意されている業務α，β，γ，…のいずれかの業務ＡＰＩ定義データ５２Ａ）を、ＡＰＩ社員利用カタログ記憶手段５２から取得し、業務ＡＰＩ定義実行手段４２Ａに送信する処理を実行するものである。なお、ＡＰＩで実行しようとしている業務（業務α，β，γ，…のいずれか）は、クライアント端末６０から受け取るＡＰＩリクエストに設定されている。また、ＡＰＩ実行者である社員（社員Ａ，Ｂ，…のいずれか）は、ＡＰＩリクエストに設定されている社員ＩＤで特定される。

【0099】

また、ＡＰＩ定義データ送信手段５１は、ＡＰＩ定義実行手段４２の成りすましチェックＡＰＩ実行手段４２Ｂからの成りすましチェックＡＰＩ定義データ（ヤムルファイル）５２Ｂの取得要求に応じ、成りすましチェックＡＰＩ定義データ５２Ｂを、ＡＰＩ社員利用カタログ記憶手段５２から取得し、成りすましチェックＡＰＩ実行手段４２Ｂに送信する処理も実行する。

【0100】

ＡＰＩ社員利用カタログ記憶手段５２（図１、図２、図３参照）は、ＡＰＩ利用対象者（各社員、各部署、各システム等）が利用可能な製品（ＡＰＩ社員利用製品）と呼ばれるデータを、ＡＰＩ利用対象者毎に記憶するものである。図３の例では、社員Ａ用、社員Ｂ用、Ｊ部Ｋ課用、…のＡＰＩ社員利用製品が用意されている。

【0101】

各ＡＰＩ社員利用製品には、ＡＰＩ利用対象者（各社員、各部署、各システム等）が利用できる業務α，β，γ，…の業務ＡＰＩ定義データ５２Ａ、および成りすましチェックＡＰＩ定義データ５２Ｂがあり、いずれもヤムルファイルで記憶されている。

【0102】

＜ＡＰＩ基盤システム３０／ＡＰＩ管理サーバ５０／ＡＰＩ利用対象者情報送信手段５３、ＡＰＩ利用対象者情報記憶手段５４の構成＞

【0103】

ＡＰＩ利用対象者情報送信手段５３（図１参照、但し、図２および図３では記載を省略している。）は、ＡＰＩ定義実行手段４２の成りすましチェックＡＰＩ実行手段４２ＢからのＡＰＩ利用対象者情報の取得要求に応じ、成りすましチェックＡＰＩ実行手段４２Ｂから送信されてきたクライアントＩＤに関連付けてＡＰＩ利用対象者情報記憶手段５４に記憶されているＡＰＩ利用対象者ＩＤ（社員ＩＤ）を、成りすましチェックＡＰＩ実行手段４２Ｂに送信する処理を実行するものである。

【0104】

また、ＡＰＩ利用対象者情報送信手段５３は、成りすましチェックＡＰＩ実行手段４２Ｂから送信されてきた社員ＩＤに関連付けてＡＰＩ利用対象者情報記憶手段５４に記憶されているクライアントＩＤを、成りすましチェックＡＰＩ実行手段４２Ｂに送信する処理を実行してもよく、あるいは、成りすましチェックＡＰＩ実行手段４２Ｂから送信されてきた社員ＩＤ若しくはクライアントＩＤを含む社員ＩＤとクライアントＩＤとの組合せをＡＰＩ利用対象者情報記憶手段５４から抽出し、抽出した社員ＩＤとクライアントＩＤとの組合せ（正しい組合せ）を、成りすましチェックＡＰＩ実行手段４２Ｂに送信する処理を実行してもよい。

【0105】

ＡＰＩ利用対象者情報記憶手段５４（図１、図２、図３参照）は、ＡＰＩ利用対象者情報として、ＡＰＩ利用対象者ＩＤ（社員ＩＤ）と対応付けて、その社員ＩＤの社員に払い出したクライアントＩＤおよびクライアントシークレットを記憶するものである。

【0106】

＜クライアント端末６０／処理手段６０Ａ／端末ログイン手段６１の構成＞

【0107】

端末ログイン手段６１は、図２に示すように、社員による端末ログインのための社員ＩＤおよびパスワードの入力を受け付け、受け付けた社員ＩＤおよびパスワードを、ネットワーク１を介してオープンＩＤプロバイダシステム２０に送信する処理を実行するものである。そして、端末ログイン手段６１は、オープンＩＤプロバイダシステム２０でのログイン処理手段２１による認証処理が成功した場合には、ログインに使用された社員ＩＤおよびパスワードを、一時的にログイン社員ＩＤ・パスワード記憶手段７１に記憶させる。一方、ログイン処理手段２１による認証処理が失敗した場合には、オープンＩＤプロバイダシステム２０からネットワーク１を介して送信されてくるログイン認証エラーの情報を受信し、その旨をクライアント端末６０に画面表示する。

【0108】

＜クライアント端末６０／処理手段６０Ａ／クライアントＩＤ・クライアントシークレット入力受付手段６２の構成＞

【0109】

クライアントＩＤ・クライアントシークレット入力受付手段６２は、クライアントアプリケーション６０Ｂ（図２参照）により実現され、社員によるクライアントＩＤおよびクライアントシークレットの入力を受け付け、受け付けたクライアントＩＤおよびクライアントシークレットを、クライアントＩＤ・クライアントシークレット記憶手段７０に記憶させる。このクライアントＩＤおよびクライアントシークレットは、社員１人１人に対し、ＡＰＩ基盤システム３０から払い出されたものである。なお、各社員は、自分に払い出されたクライアントＩＤおよびクライアントシークレットを、自分が操作するクライアント端末６０に搭載されるクライアントアプリケーション６０Ｂのプログラムの中に記述（コーディイング）しておいてもよい。

【0110】

＜クライアント端末６０／処理手段６０Ａ／認可コード発行リクエスト送信手段６３の構成＞

【0111】

認可コード発行リクエスト送信手段６３は、認可コード発行リクエスト用ライブラリ６０Ｆをインポートしたクライアントアプリケーション６０Ｂ（図２参照）により実現され、社員ＩＤおよびパスワードを用いて社員がログインしたクライアント端末６０から、認可コード発行リクエスト（クライアントアプリケーション６０ＢについてのアプリケーションＩＤを含む。）を、ネットワーク１を介してオープンＩＤプロバイダシステム２０に送信する処理を実行するものである。このアプリケーションＩＤは、クライアントアプリケーション６０Ｂのプログラムの中に記述されている。

【0112】

なお、本願でいうクライアントアプリケーションについてのアプリケーションＩＤおよびアプリケーション用シークレットは、クライアントアプリケーションを識別するために、オープンＩＤプロバイダシステム２０で発行されたものであるが、一般的には、クライアントＩＤおよびクライアントシークレットとも称される。しかし、本願では、ＡＰＩ基盤システム３０から各社員に払い出したクライアントＩＤおよびクライアントシークレットもあることから、これらと呼び名の区別を付けて混乱を避けるために、アプリケーションＩＤおよびアプリケーション用シークレットと呼んでいる。

【0113】

＜クライアント端末６０／処理手段６０Ａ／認可コード受信手段６４の構成＞

【0114】

認可コード受信手段６４は、認可コード発行手段２２によりオープンＩＤプロバイダシステム２０からネットワーク１を介して送信されてくる認可コードを受信する処理を実行するものである。

【0115】

＜クライアント端末６０／処理手段６０Ａ／トークン発行リクエスト送信手段６５の構成＞

【0116】

トークン発行リクエスト送信手段６５は、トークン発行リクエスト用ライブラリ６０Ｇをインポートしたクライアントアプリケーション６０Ｂ（図２参照）により実現され、認可コード受信手段６４により受信した認可コード、並びに、アプリケーションＩＤおよびアプリケーション用シークレットを含むトークン発行リクエストを、クライアント端末６０からネットワーク１を介してオープンＩＤプロバイダシステム２０に送信する処理を実行するものである。なお、アプリケーションＩＤおよびアプリケーション用シークレットは、クライアントアプリケーション６０Ｂのプログラムの中に記述されている。

【0117】

＜クライアント端末６０／処理手段６０Ａ／トークン受信手段６６の構成＞

【0118】

トークン受信手段６６は、トークン発行手段２３によりオープンＩＤプロバイダシステム２０からネットワーク１を介して送信されてくるＩＤトークン（社員ＩＤを部分的に含んでいるユーザ名を含む。）およびアクセストークンを受信する処理を実行するものである。

【0119】

＜クライアント端末６０／処理手段６０Ａ／ＡＰＩ呼出手段６７の構成＞

【0120】

ＡＰＩ呼出手段６７は、ＡＰＩ呼出用ライブラリ６０Ｈをインポートしたクライアントアプリケーション６０Ｂ（図２参照）により実現され、クライアントＩＤ・クライアントシークレット入力受付手段６２により受け付けてクライアントＩＤ・クライアントシークレット記憶手段７０に記憶されているか、またはクライアントアプリケーション６０Ｂ（図２参照）のプログラム内に記述されているクライアントＩＤおよびクライアントシークレット、並びに、トークン受信手段６６により受信したＩＤトークン（社員ＩＤを部分的に含んでいるユーザ名を含む。）を含むＡＰＩリクエストを作成し、クライアント端末６０から、作成したＡＰＩリクエストを、ネットワーク１を介してＡＰＩ基盤システム３０のゲートウェイサーバ４０に送信する処理を実行するものである。

【0121】

また、ＡＰＩ呼出手段６７は、ゲートウェイサーバ４０からネットワーク１を介して認証エラーが発生した旨の情報が送信されてきた場合には、それを受信し、その旨をクライアント端末６０に画面表示する。

【0122】

＜クライアント端末６０／処理手段６０Ａ／ＡＰＩ応答受信手段６８の構成＞

【0123】

ＡＰＩ応答受信手段６８は、ＡＰＩ基盤システム３０のポストフロー処理手段４３のＡＰＩ事後処理手段４３Ａからネットワーク１を介して送信されてくるＡＰＩ応答（上記のＡＰＩ呼出手段６７によるＡＰＩリクエストで要求した業務処理に係る内容を示すデータ）を受信する処理を実行するものである。

【0124】

＜クライアント端末６０／処理手段６０Ａ／クライアントＩＤ・クライアントシークレット記憶手段７０、ログイン社員ＩＤ・パスワード記憶手段７１の構成＞

【0125】

クライアントＩＤ・クライアントシークレット記憶手段７０は、クライアントＩＤ・クライアントシークレット入力受付手段６２により社員からの入力を受け付けたクライアントＩＤおよびクライアントシークレットを記憶するものである。但し、クライアントＩＤおよびクライアントシークレットは、クライアントアプリケーション６０Ｂ（図２参照）のプログラムの中に記述（コーディング）しておいてもよい。

【0126】

ログイン社員ＩＤ・パスワード記憶手段７１は、社員により端末ログイン時に使用された社員ＩＤおよびパスワードを一時的に記憶するものである。

【0127】

＜社員によるＡＰＩ実行時の成りすまし防止処理の流れ：図４、図５＞

【0128】

このような本実施形態においては、図４および図５に示すように、以下のようにして、成りすまし防止システム１０により、社員によるＡＰＩ実行時の成りすまし防止処理が行われる。

【0129】

図４において、先ず、ＡＰＩ実行者である社員は、クライアント端末６０で、ログインのために、社員ＩＤおよびパスワードを入力する（ステップＳ１）。この入力は、端末ログイン手段６１により受け付けられ、入力された社員ＩＤおよびパスワードが、ネットワーク１を介してオープンＩＤプロバイダシステム２０に送信される。オープンＩＤプロバイダシステム２０では、ログイン処理手段２１により、ユーザ情報記憶手段２４に記憶された情報を用いてログインのための認証処理が行われる（ステップＳ２）。この認証結果は、ログイン処理手段２１により、ネットワーク１を介してクライアント端末６０に送信され、ログイン認証が成功した場合には、端末ログイン手段６１により、端末ログインに使用された社員ＩＤおよびパスワードが、ログイン社員ＩＤ・パスワード記憶手段７１に一時的に記憶される。

【0130】

続いて、クライアントＩＤ・クライアントシークレット入力受付手段６２により、ＡＰＩ実行者である社員によるクライアントＩＤおよびクライアントシークレットの入力を受け付け、受け付けたクライアントＩＤおよびクライアントシークレットを、クライアントＩＤ・クライアントシークレット記憶手段７０に記憶させる（ステップＳ３）。なお、クライアントＩＤおよびクライアントシークレットが、クライアントアプリケーション６０Ｂ（図２参照）のプログラム内に記述（コーディイング）されている場合は、この入力を行う必要はない。

【0131】

それから、認可コード発行リクエスト送信手段６３により、クライアント端末６０から、認可コード発行リクエスト（クライアントアプリケーション６０Ｂ（図２参照）についてのアプリケーションＩＤを含む。）を、ネットワーク１を介してオープンＩＤプロバイダシステム２０に送信する（ステップＳ４）。

【0132】

オープンＩＤプロバイダシステム２０では、認可コード発行手段２２により、クライアント端末６０からネットワーク１を介して送信されてくる認可コード発行リクエスト（クライアント端末６０に搭載されたクライアントアプリケーション６０Ｂ（図２参照）を識別するアプリケーションＩＤを含む。）を受信し（ステップＳ５）、端末ログインに用いられた社員ＩＤおよびパスワードの送信要求（取得要求）を、ネットワーク１を介してクライアント端末６０に送信する（ステップＳ６）。

【0133】

クライアント端末６０では、認可コード発行リクエスト送信手段６３により、社員ＩＤおよびパスワードの送信要求（取得要求）を受信し（ステップＳ７）、ログイン社員ＩＤ・パスワード記憶手段７１に一時的に記憶されているログイン時に使用した社員ＩＤおよびパスワードを、ネットワーク１を介してオープンＩＤプロバイダシステム２０に送信する（ステップＳ８）。

【0134】

オープンＩＤプロバイダシステム２０では、認可コード発行手段２２により、社員ＩＤおよびパスワードを受信し（ステップＳ９）、認可コードを発行してこの認可コードを、受信した社員ＩＤと関連付けて認可コード発行情報記憶手段２６に記憶させるとともに、発行した認可コードを、ネットワーク１を介してクライアント端末６０に送信する（ステップＳ１０）。クライアント端末６０では、認可コード受信手段６４により、オープンＩＤプロバイダシステム２０から送信されてくる認可コードを受信する（ステップＳ１１）。

【0135】

続いて、トークン発行リクエスト送信手段６５により、受信した認可コード、並びに、アプリケーションＩＤおよびアプリケーション用シークレットを含むトークン発行リクエストを、クライアント端末６０からネットワーク１を介してオープンＩＤプロバイダシステム２０に送信する（ステップＳ１２）。

【0136】

オープンＩＤプロバイダシステム２０では、トークン発行手段２３により、クライアント端末６０から送信されてくるトークン発行リクエスト（認可コード、アプリケーションＩＤ、アプリケーション用シークレットを含む。）を受信し（ステップＳ１３）、受信したトークン発行リクエストに含まれるアプリケーションＩＤと対応付けてアプリケーション一覧記憶手段２５に記憶されているアプリケーション用シークレットと、受信したトークン発行リクエストに含まれるアプリケーション用シークレットとが一致しているか否かにより、クライアントアプリケーションが正しいか否かの検証を行う（ステップＳ１４）。さらに、トークン発行手段２３により、受信したトークン発行リクエストに含まれる認可コードを用いて認可コード発行情報記憶手段２６から社員ＩＤを取得し、取得した社員ＩＤを用いてユーザ情報記憶手段２４からユーザ名を取得し、取得したユーザ名を含むＩＤトークン、およびアクセストークンを発行し、発行したＩＤトークンおよびアクセストークンを、ネットワーク１を介してクライアント端末６０に送信する（ステップＳ１４）。

【0137】

クライアント端末６０では、トークン受信手段６６により、オープンＩＤプロバイダシステム２０から送信されてくるＩＤトークン（社員ＩＤを部分的に含んでいるユーザ名を含む。）およびアクセストークンを受信する（ステップＳ１５）。

【0138】

その後、クライアント端末６０で、ＡＰＩ呼出手段６７により、クライアントＩＤ・クライアントシークレット入力受付手段６２により受け付けてクライアントＩＤ・クライアントシークレット記憶手段７０に記憶されているか、またはクライアントアプリケーション６０Ｂ（図２参照）のプログラム内に記述されているクライアントＩＤおよびクライアントシークレット、並びに、トークン受信手段６６により受信したＩＤトークン（社員ＩＤを部分的に含んでいるユーザ名を含む。）を含むＡＰＩリクエストを作成し、作成したＡＰＩリクエストを、ネットワーク１を介してＡＰＩ基盤システム３０のゲートウェイサーバ４０に送信する（ステップＳ１６）。

【0139】

ＡＰＩ基盤システム３０のゲートウェイサーバ４０では、プリフロー処理手段４１のＵＲＬマッチング手段４１Ａにより、クライアント端末６０から送信されてくるＡＰＩリクエスト（ヘッダに、クライアントＩＤ、クライアントシークレット、ＩＤトークンが設定されている。）を受信し（図４のステップＳ１７）、図１５に示すＵＲＬマッチング処理を実行する。

【0140】

図１５において、のＵＲＬマッチング手段４１Ａは、受信したＡＰＩリクエストに含まれるＡＰＩのパス（ＵＲＬ）が、ＡＰＩ社員利用カタログのパスであり、かつ、ＨＴＴＰメソッドがＯＰＴＩＯＮＳ以外であるという条件を満たすか否かのチェックを行う（図１５のステップＳ１８）。

【0141】

ここで、ＵＲＬマッチング手段４１Ａにより上記の条件を満たすと判断した場合（ステップＳ１９）には、社員ＩＤ設定手段４１Ｂによる処理（ステップＳ２０）に移行する。一方、上記の条件を満たさないと判断した場合（ステップＳ１９）には、リクエスト構文・サイズチェック手段４１Ｅによる処理（ステップＳ３２）に移行する。

【0142】

そして、上記の条件を満たすと判断した場合（ステップＳ１９）には、社員ＩＤ設定手段４１Ｂにより、先ず、クライアント端末６０から受信したＡＰＩリクエストのヘッダにＩＤトークンが設定されているか否かを判断し（ステップＳ２０）、設定されていない場合には、認証エラーが発生した旨の情報を、ネットワーク１を介してクライアント端末６０に送信する（ステップＳ２１）。クライアント端末６０では、ＡＰＩ呼出手段６７により、ゲートウェイサーバ４０から送信されてくる認証エラーが発生した旨の情報を受信した場合には、その旨の情報をクライアント端末６０に画面表示する（ステップＳ２２）。

【0143】

次に、受信したＡＰＩリクエストにＩＤトークンが設定されていると判断した場合（ステップＳ２０）には、社員ＩＤ設定手段４１Ｂにより、ＡＰＩリクエストに含まれるＩＤトークン内のユーザ名から社員ＩＤを切り取り（本実施形態では、図２に示すように、＠の前の部分を切り取る。）、切り取った社員ＩＤを、ＡＰＩリクエストのヘッダに設定する（ステップＳ２３）。

【0144】

続いて、トークン検証手段４１Ｃにより、オープンＩＤプロバイダから受け取っている公開鍵およびパラメータ（キーＩＤ、アルゴリズム）を用いて、ＡＰＩリクエストに含まれるＩＤトークンが、オープンＩＤプロバイダシステム２０で発行されたものであるか否かを検証する処理（ＩＤトークンの改ざん検知処理）を実行する（ステップＳ２４）。

【0145】

具体的には、トークン検証手段４１Ｃにより、ＩＤトークンをデコードし、パラメータ記憶手段４５（図１、図２参照）に記憶されたキーＩＤおよびアルゴリズムと、ＡＰＩリクエストのヘッダに含まれるＩＤトークン内のキーＩＤおよびアルゴリズム（デコードされた状態のキーＩＤおよびアルゴリズム）とが一致しているか否かを検証する（ステップＳ２４）。また、ＡＰＩリクエストのヘッダに含まれるＩＤトークン内の署名（デコードされた状態の署名）と、公開鍵記憶手段４４（図１、図２参照）に記憶された公開鍵とを用いて、ＩＤトークンがオープンＩＤプロバイダシステム２０により発行されたものであるか否かを検証する（ステップＳ２４）。

【0146】

そして、トークン検証手段４１Ｃにより、ＩＤトークンがオープンＩＤプロバイダシステム２０により発行されたものでないと判断した場合（ステップＳ２５）には、認証エラーが発生した旨の情報を、ネットワーク１を介してクライアント端末６０に送信する（ステップＳ２６）。クライアント端末６０では、ＡＰＩ呼出手段６７により、ゲートウェイサーバ４０から送信されてくる認証エラーが発生した旨の情報を受信した場合には、その旨の情報をクライアント端末６０に画面表示する（ステップＳ２７）。

【0147】

それから、ＩＤトークンがオープンＩＤプロバイダシステム２０により発行されたものであると判断した場合（ステップＳ２５）には、プリフロー処理手段４１の成りすましチェックＡＰＩ呼出手段４１Ｄ、およびＡＰＩ定義実行手段４２の成りすましチェックＡＰＩ実行手段４２Ｂにより、成りすましチェックＡＰＩを実行して成りすましチェック処理を実行する（ステップＳ２８）。これらの成りすましチェックＡＰＩ呼出手段４１Ｄおよび成りすましチェックＡＰＩ実行手段４２Ｂの各々の処理内容は、各々の構成の説明で既に詳述しているので、ここでは詳しい説明を省略する。

【0148】

具体的には、これらの各手段４１Ｄ，４２Ｂによる成りすましチェック処理では、元のＡＰＩリクエスト（クライアント端末６０からのＡＰＩリクエスト）のヘッダに設定されているクライアントＩＤに関連付けてＡＰＩ利用対象者情報記憶手段５４に記憶されているＡＰＩ利用対象者ＩＤ（社員ＩＤ）と、元のＡＰＩリクエストのヘッダに設定されている社員ＩＤ（社員ＩＤ設定手段４１ＢによりＩＤトークン内のユーザ名から切り取った社員ＩＤ）とが一致しているか否かにより（一致していることを確認し）、ＡＰＩ実行者が成りすましを行っていないことを検証する（ステップＳ２８）。

【0149】

また、成りすましチェックＡＰＩ呼出手段４１Ｄにより、上記の比較検証で一致しているか否かを判断し（ステップＳ２９）、ＡＰＩ実行者が成りすましを行っていると判断した場合（一致しなかった場合）には、認証エラーが発生した旨の情報を、ネットワーク１を介してクライアント端末６０に送信する（ステップＳ３０）。クライアント端末６０では、ＡＰＩ呼出手段６７により、ゲートウェイサーバ４０から送信されてくる認証エラーが発生した旨の情報を受信した場合には、その旨の情報をクライアント端末６０に画面表示する（ステップＳ３１）。

【0150】

続いて、リクエスト構文・サイズチェック手段４１Ｅにより、クライアント端末６０から受け取ったＡＰＩリクエストについての構文のチェックおよびサイズのチェックを実行する（ステップＳ３２）。

【0151】

その後、ＡＰＩ定義実行手段４２の業務ＡＰＩ定義実行手段４２Ａにより、ＡＰＩ社員利用カタログ記憶手段５２に記憶されている、ＡＰＩ実行者である社員の要求に係る業務（図３に示す業務α，β，γ，…のいずれか）の業務ＡＰＩ定義データ（ヤムルファイル）５２Ａに従って、バックエンドシステム８０のバックエンド業務処理手段８１に対し、ネットワーク１を介して業務ＡＰＩの呼出（業務ＡＰＩリクエストの送信）を行い、バックエンド業務処理用データ記憶手段８２（図１参照）に記憶されたデータを用いた業務処理を実行させることにより、業務ＡＰＩを実行する（ステップＳ３３）。

【0152】

続いて、ポストフロー処理手段４３のＡＰＩ事後処理手段４３Ａにより、バックエンドシステム８０のバックエンド業務処理手段８１からネットワーク１を介して送信されてくる業務ＡＰＩ応答（バックエンド業務処理手段８１による業務処理の結果として得られた情報）を受信し、受信した業務ＡＰＩ応答（業務処理結果）を、ネットワーク１を介してクライアント端末６０に送信する（ステップＳ３３）。クライアント端末６０では、ＡＰＩ応答受信手段６８により、ゲートウェイサーバ４０からの業務処理結果を受信する（ステップＳ３４）。これにより、社員による一連のＡＰＩ実行に関する処理が終了する。

【0153】

＜社員Ｂが社員Ａに成りすます不正行為を防止する処理の流れ＞

【0154】

社員Ｂが社員Ａに成りすます不正行為を行い、ＡＰＩを実行した場合において、その成りすましを防止する処理の流れは、以下の通りである。

【0155】

図４のステップＳ１において、不正行為者である社員Ｂは、自分（社員Ｂ）の社員ＩＤおよびパスワードを用いて、自分が操作するクライアント端末６０にログインする。オープンＩＤプロバイダシステム２０のログイン処理手段２１によるログイン認証（図４のステップＳ２）は、社員ＩＤおよびパスワードの組合せが正しいので（社員Ｂの組合せとして正しいので）、成功する。

【0156】

図４のステップＳ３において、不正行為者である社員Ｂは、不正な方法で知り得た他人（社員Ａ）のクライアントＩＤおよびクライアントシークレットを入力し、自分（社員Ｂ）が操作するクライアント端末６０のクライアントＩＤ・クライアントシークレット記憶手段７０に記憶させるか、または自分（社員Ｂ）が操作するクライアント端末６０に搭載されるクライアントアプリケーション６０Ｂ（図２参照）に記述されているクライアントＩＤおよびクライアントシークレットを、他人（社員Ａ）のクライアントＩＤおよびクライアントシークレットに書き換える。

【0157】

図４のステップＳ４において、認可コード発行リクエストに、アプリケーションＩＤを含めるが、このアプリケーションＩＤは、自分（社員Ｂ）が操作するクライアント端末６０に搭載されるクライアントアプリケーション６０ＢについてのアプリケーションＩＤである。

【0158】

図４のステップＳ８において、ログイン社員ＩＤ・パスワード記憶手段７１に記憶されている端末ログイン時に使用した社員ＩＤおよびパスワードが、オープンＩＤプロバイダシステム２０に送信されるが、この社員ＩＤおよびパスワードは、不正行為者である社員Ｂの社員ＩＤおよびパスワードである。

【0159】

図４のステップＳ１０において、発行した認可コードと、社員ＩＤとの対応関係が、認可コード発行情報記憶手段２６に記憶されるが、このときの社員ＩＤは、不正行為者である社員Ｂの社員ＩＤである。

【0160】

図４のステップＳ１２において、トークン発行リクエストに、認可コード、アプリケーションＩＤ、アプリケーション用シークレットを含めるが、このときのアプリケーションＩＤおよびアプリケーション用シークレットは、不正行為者である社員Ｂが操作するクライアント端末６０に搭載されるクライアントアプリケーション６０ＢについてのアプリケーションＩＤおよびアプリケーション用シークレットである。

【0161】

図４のステップＳ１４において、アプリケーションＩＤおよびアプリケーション用シークレットを用いてクライアントが正しいか否かの検証を行うが、この際、アプリケーション一覧記憶手段２５に記憶されているアプリケーションＩＤおよびアプリケーション用シークレットの組合せを用いる。アプリケーションＩＤおよびアプリケーション用シークレットの組合せは、正しいので（社員Ｂが操作するクライアント端末６０に搭載されるクライアントアプリケーション６０Ｂについての組合せとして正しいので）、この検証で不正は検知されない。

【0162】

また、図４のステップＳ１４では、トークン発行リクエストに含まれる認可コード用いて認可コード発行情報記憶手段２６から社員ＩＤを取得するが、このときに取得される社員ＩＤは、不正行為者である社員Ｂの社員ＩＤである。さらに、取得した社員ＩＤ（社員Ｂの社員ＩＤ）を用いてユーザ情報記憶手段２４からオープンＩＤプロバイダ用のユーザ名を取得するが、このときのユーザ名は、社員Ｂのユーザ名であり、社員Ｂの社員ＩＤを部分的に含んでいる。そして、そのユーザ名（社員Ｂの社員ＩＤを部分的に含む。）を含むＩＤトークンおよびアクセストークンを発行する。

【0163】

図４のステップＳ１６において、ＡＰＩリクエストのヘッダに、クライアントＩＤ、クライアントシークレット、ＩＤトークンを設定するが、このときのクライアントＩＤおよびクライアントシークレットは、不正な方法で知り得た他人（社員Ａ）のクライアントＩＤおよびクライアントシークレットである。また、ＩＤトークンには、社員Ｂのユーザ名が含まれ、そのユーザ名には、社員Ｂの社員ＩＤが部分的に含まれている。

【0164】

図５のステップＳ２３において、ＡＰＩリクエストに含まれるＩＤトークン内のユーザ名（社員Ｂのユーザ名）から社員ＩＤ（社員Ｂの社員ＩＤ）を切り取り、切り取った社員ＩＤ（社員Ｂの社員ＩＤ）を、ＡＰＩリクエストのヘッダに設定する。これにより、ＡＰＩリクエストのヘッダには、不正行為者である社員Ｂの社員ＩＤと、不正な方法で知り得た他人（社員Ａ）のクライアントＩＤおよびクライアントシークレットとが設定されている状態となる。

【0165】

図５のステップＳ２４において、オープンＩＤプロバイダから受け取っている公開鍵およびパラメータ（キーＩＤ、アルゴリズム）を用いて、ＡＰＩリクエストに含まれるＩＤトークンの検証が行われるが、不正行為者である社員Ｂが、ＩＤトークンの改ざんを行っていなければ、ここでのＩＤトークンの改ざん検知処理では、不正は検知されない。

【0166】

図５のステップＳ２８における成りすましチェック処理では、ＡＰＩリクエストのヘッダに設定されているクライアントＩＤ（不正な方法で知り得た他人（社員Ａ）のクライアントＩＤ）に関連付けてＡＰＩ利用対象者情報記憶手段５４に記憶されているＡＰＩ利用対象者ＩＤ（社員Ａの社員ＩＤ）と、ＡＰＩリクエストのヘッダに設定されている社員ＩＤ（ＩＤトークン内の社員Ｂのユーザ名から切り取った社員Ｂの社員ＩＤ）とは一致しないので、ここで初めて、成りすましが行われていると判断される。

【0167】

＜本実施形態の効果＞

【0168】

このような本実施形態によれば、次のような効果がある。すなわち、成りすまし防止システム１０では、ＩＤトークンの発行のための仕様であるオープンＩＤコネクト（OpenID Connect）の活用により、クライアントＩＤおよびクライアントシークレット以外の情報として、オープンＩＤプロバイダシステム２０で発行されるＩＤトークンを利用してＡＰＩ実行時のクライアントＩＤが実行者本人のものであることのチェック（社員による成りすましチェック）を行うことができる。

【0169】

なお、オープンＩＤプロバイダシステム２０でＩＤトークンを発行することは、オープンＩＤコネクト（OpenID Connect）の仕様に従った既存の処理であるが、発行されたＩＤトークンを利用して社員による成りすましの防止処理を行うことや、そのための情報をＩＤトークンに設定することは、本発明に固有の特徴である。

【0170】

すなわち、オープンＩＤプロバイダシステム２０に設けられたトークン発行手段２３により、クライアント端末６０からのトークン発行リクエストを受信した場合に、受信したトークン発行リクエストに含まれる認可コードを用いて認可コード発行情報記憶手段２６から社員ＩＤを取得し、取得した社員ＩＤを用いてユーザ情報記憶手段２４からユーザ名（社員ＩＤを部分的に含んで構成されるオープンＩＤプロバイダ用のユーザ名）を取得し、取得したユーザ名を含むＩＤトークンを発行し、発行したＩＤトークンをクライアント端末６０に送信するので、ＩＤトークン内に、成りすましが行われているか否かの検証に必要な情報を設定することができる。

【0171】

また、社員がＡＰＩを実行する際には、自分がログインしたクライアント端末６０で、ＡＰＩ呼出手段６７により、クライアントＩＤおよびクライアントシークレット、並びにＩＤトークンを含むＡＰＩリクエストを作成し、作成したＡＰＩリクエストを、クライアント端末６０からＡＰＩ基盤システム３０に送信するので、ＡＰＩリクエスト内に、成りすましが行われているか否かの検証に必要な情報を設定することができる。

【0172】

さらに、ＡＰＩ基盤システム３０では、社員ＩＤ設定手段４１Ｂにより、クライアント端末６０から受信したＡＰＩリクエストに設定されたＩＤトークンに含まれるオープンＩＤプロバイダ用のユーザ名（このユーザ名は、社員ＩＤを部分的に含んでいる。）から社員ＩＤを切り取り、切り取った社員ＩＤを、ＡＰＩリクエストに設定するので、ＡＰＩリクエスト内に含まれる情報を、成りすましが行われているか否かの検証に使用しやすい状態に整備することができる。

【0173】

そして、ＡＰＩ基盤システム３０内で、成りすましチェック手段を構成するプリフロー処理手段４１の成りすましチェックＡＰＩ呼出手段４１Ｄ、およびＡＰＩ定義実行手段４２の成りすましチェックＡＰＩ実行手段４２Ｂにより、ＡＰＩリクエストに設定されたクライアントＩＤと関連付けられてＡＰＩ利用対象者情報記憶手段５４に記憶されている社員ＩＤと、ＡＰＩリクエストに設定された社員ＩＤ（オープンＩＤプロバイダ用のユーザ名から切り取った社員ＩＤ）とが一致しているか否かを判断し、一致していない場合に、他の社員への成りすましが行われていると判断することができる。

【0174】

このため、他の社員への成りすましを行う不正行為者である社員が、自分（不正行為者自身）の社員ＩＤと、不正に入手した他の社員のクライアントＩＤおよびクライアントシークレットとを使ってＡＰＩを実行しようとしても、成りすましチェック手段により、その不正行為が発覚することになる。つまり、ＡＰＩリクエストに設定された社員ＩＤは、端末ログインを行った不正行為者自身の社員ＩＤであり、一方、不正に入手した他の社員のクライアントＩＤと関連付けられてＡＰＩ利用対象者情報記憶手段に記憶されている社員ＩＤは、他の社員の社員ＩＤであるから、一致しないので、成りすましの行為を見つけることができる。

【0175】

よって、不正行為者である社員が、バックエンドシステム８０に記憶されている顧客情報などを不正に入手することを防止することができ、また、更新系の業務処理を行うＡＰＩの場合は、不正行為者である社員が、データを不正に登録・更新・削除することを防止することができる。

【0176】

また、クライアントＩＤおよびクライアントシークレットを払い出したＡＰＩ利用対象者が増加した場合でも、成りすましを防止するための追加メンテナンスは不要である。

【0177】

また、社員ＩＤ設定手段４１Ｂは、ＡＰＩリクエストにＩＤトークンが設定されていない場合には、認証エラーをクライアント端末６０に送信する構成とされているので、成りすましチェックＡＰＩ呼出手段４１Ｄおよび成りすましチェックＡＰＩ実行手段４２Ｂによる成りすましチェック処理に必要な情報が欠落していることを判断することができ、欠落している場合に、成りすましチェック処理に進む前に、不正なＡＰＩの実行を防ぐことができる。

【0178】

さらに、成りすまし防止システム１０は、トークン検証手段４１Ｃを備えているので、ＩＤトークンがオープンＩＤプロバイダシステム２０により発行されたものであるか否かを検証することができるため、より一層、セキュリティ機能を向上させることができる。

【0179】

＜変形の形態＞

【0180】

なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。

【0181】

例えば、前記実施形態では、社員ＩＤ設定手段４１Ｂは、図２に示されたユーザ情報記憶手段２４のように、オープンＩＤプロバイダ用のユーザ名におけるアットマークの前の部分の全部を、社員ＩＤに相当する部分として切り取っていたが、切り取る部分（すなわち、社員ＩＤに相当する部分）は、この位置に限定されるものではなく、ユーザ名に社員ＩＤが含まれていてその部分を切り取るようになっていればよい。

【0182】

また、前記実施形態では、プリフロー処理手段４１の成りすましチェックＡＰＩ呼出手段４１Ｄが、ＡＰＩ定義実行手段４２の成りすましチェックＡＰＩ実行手段４２Ｂとの間で、成りすましチェックＡＰＩリクエストの送信、成りすましチェックＡＰＩ応答の受信を行う構成とされていたが、本発明における「成りすましチェック手段」（請求項に記載された「成りすましチェック手段」）は、このような構成に限定されるものではなく、成りすましチェックＡＰＩを使用しない構成（プリフロー処理手段４１に、成りすましチェックＡＰＩ実行手段４２Ｂの機能を含む「成りすましチェック手段」を設ける構成）としてもよい。

【産業上の利用可能性】

【0183】

以上のように、本発明の成りすまし防止システムおよびプログラムは、例えば、各社員がクライアントアプリケーションを搭載したクライアント端末から業務ＡＰＩを利用してバックエンドシステムの各種のデータにアクセスし、業務処理を行う場合等に用いるのに適している。

【符号の説明】

【0184】

１ ネットワーク
１０ 成りすまし防止システム
２０ オープンＩＤプロバイダシステム
２２ 認可コード発行手段
２３ トークン発行手段
２４ ユーザ情報記憶手段
２５ アプリケーション一覧記憶手段
２６ 認可コード発行情報記憶手段
３０ ＡＰＩ基盤システム
４０ ゲートウェイサーバ
４１Ｂ 社員ＩＤ設定手段
４１Ｃ トークン検証手段
４１Ｄ 「成りすましチェック手段」を構成する成りすましチェックＡＰＩ呼出手段
４２Ｂ 「成りすましチェック手段」を構成する成りすましチェックＡＰＩ実行手段
４４ 公開鍵記憶手段
４５ パラメータ記憶手段
５０ ＡＰＩ管理サーバ
５４ ＡＰＩ利用対象者情報記憶手段
６０ クライアント端末
６３ 認可コード発行リクエスト送信手段
６４ 認可コード受信手段
６５ トークン発行リクエスト送信手段
６６ トークン受信手段
６７ ＡＰＩ呼出手段
８０ バックエンドシステム

【要約】

【課題】社員によるＡＰＩ実行時の成りすましを防止することができる成りすまし防止システムを提供する。
【解決手段】成りすまし防止システム１０では、オープンＩＤプロバイダシステム２０で、社員ＩＤを部分的に含んで構成されるユーザ名を含むＩＤトークンを発行し、クライアント端末６０で、クライアントＩＤ、ＩＤトークン等を含むＡＰＩリクエストを作成してＡＰＩ基盤システム３０に送信し、ＡＰＩ基盤システム３０で、ＩＤトークンに含まれるユーザ名から社員ＩＤを切り取ってこれをＡＰＩリクエストに設定し、成りすましチェック手段（４１Ｄ、４２Ｂ）により、ＡＰＩ利用対象者情報記憶手段５４を用いて、ＡＰＩリクエスト内のクライアントＩＤと社員ＩＤとが対応しているか否かを判断する。
【選択図】図１

【図1】

【図2】

【図3】

【図4】

【図5】