知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-09-19
(45)【発行日】2024-09-30
(54)【発明の名称】トークン検証システムおよびプログラム
(51)【国際特許分類】
G06F 21/62 20130101AFI20240920BHJP
G06F 21/44 20130101ALI20240920BHJP
【ＦＩ】
G06F21/62 318
G06F21/44
【請求項の数】
5
(21)【出願番号】P 2024064308
(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】
前記ＡＰＩ基盤システムは、前記トークン発行手段により前記アクセストークンおよび前記リフレッシュトークンを発行した際に、前記アクセストークンおよび前記リフレッシュトークンのそれぞれについての有効期限および失効フラグを、アクセストークンＩＤ若しくはアクセストークン自体およびリフレッシュトークンＩＤ若しくはリフレッシュトークン自体と関連付けて記憶するトークン情報記憶手段を備え、
前記トークン検証手段は、
前記イントロスペクションＡＰＩリクエストに設定された前記アクセストークンについてのアクセストークンＩＤ若しくはアクセストークン自体と関連付けて前記トークン情報記憶手段に記憶されている前記有効期限および前記失効フラグを用いて、前記アクセストークンの正当性を検証するか、または、前記イントロスペクションＡＰＩリクエストに設定された前記リフレッシュトークンについてのリフレッシュトークンＩＤ若しくはリフレッシュトークン自体と関連付けて前記トークン情報記憶手段に記憶されている前記有効期限および前記失効フラグを用いて、前記リフレッシュトークンの正当性を検証する構成とされている
ことを特徴とする請求項１に記載のトークン検証システム。
【請求項5】
請求項１～４のいずれかに記載のトークン検証システムとして、コンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、インターネット経由の社外アクセスのリクエストに含まれるアクセストークンおよびリフレッシュトークンを検証する処理を実行するコンピュータにより構成されたトークン検証システムおよびプログラムに係り、例えば、社外のエンドユーザが、ＡＰＩ（Application Programming Interface：アプリケーション・プログラミング・インターフェース）を利用してインターナルクラウド環境下に置かれた業務処理システムにアクセスし、業務処理を実行する場合等に利用できる。
【背景技術】
【0002】
従来から、証券・金融システムでは、フィンテック（FinTech）企業等からのインターネット経由での通信（以下、社外アクセスという。）を受け付け、フィンテック企業等と連携した金融サービスを実現するために、証券・金融システムが保有するリソース（顧客情報や、売買取引に関するデータ等）を提供している。
【0003】
図７に示すように、フィンテック企業等と連携する従来のシステム９０では、インターネット９１に、社外コンシューマであるフィンテック企業等のエンドユーザが操作するクライアント端末９２が接続されている。また、インターネット９１には、ルータ９３、ＤＭＺファイアウォール９４を介して、ＤＭＺ（非武装地帯）に配置されたインターネット公開用のゲートウェイサーバ９５が接続されている。
【0004】
さらに、インターネット公開用のゲートウェイサーバ９５には、内部ファイアウォール９６を介して、社内イントラネットや社内ＬＡＮ等の内部ネットワーク９７が接続されている。この内部ネットワーク９７には、社内コンシューマである社内の他のシステム（図７で社外アクセスの対象となっているシステム以外のシステム）のサーバ９８や、社内ユーザが操作する社内の端末９９と、社内用のゲートウェイサーバ１００と、社外アクセスの対象となる銀行・証券会社等の金融業務に係る業務処理システム１０１とが接続されている。
【0005】
このシステム９０の場合、クライアン端末９２からのリクエストは、インターネット９１、ルータ９３、ＤＭＺファイアウォール９４、インターネット公開用のゲートウェイサーバ９５、内部ファイアウォール９６を経由して内部ネットワーク９７に入り、業務処理システム１０１に到達する。
【0006】
一方、社内コンシューマである社内の他のシステムのサーバ９８や社内の端末９９からのリクエストは、内部ネットワーク９７を介して社内用のゲートウェイサーバ１００に至り、そこから内部ネットワーク９７を介して業務処理システム１０１に到達する。
【0007】
従って、このような従来のシステム９０は、セキュリティの観点から、社外コンシューマからの通信を処理するためにＤＭＺ（非武装地帯）に配置したインターネット公開用のゲートウェイサーバ９５と、社内コンシューマからの通信を処理するための社内用のゲートウェイサーバ１００とを設けた構成となっていた。すなわち、従来は、ゲートウェイサーバを、インターネット９１を経由する社外アクセス用と、内部ネットワーク９７を経由するがインターネット９１は経由しない社内アクセス用とに分離した構成をとっていた。
【0008】
そして、このようなＤＭＺ（非武装地帯）の構成を採用し、サイバー攻撃を受けた場合でも不正なリクエストの内部ネットワーク９７への侵入を防ぐことにより、インターナルクラウド内のシステム（内部ネットワーク９７に接続された業務処理システム１０１）の安全性を確保していた。
【0009】
また、社外アクセスに対しては認可プロトコルにOAuth2.0を利用することにより、リクエストの正当性を担保していた。これは、例えば、ＩＢＭ社のＡＰＩコネクト（IBM APIConnect）等の標準機能を利用することにより実現することができる。
【0010】
なお、本発明では、後述するように、イントロスペクションＡＰＩを利用するが、イントロスペクションを行い、かつ、アクセストークンやリフレッシュトークンに関する技術としては、モバイルアプリケーションのための効率的および直観的なデータ・バインディングを行う技術が知られている（特許文献１参照）。
【先行技術文献】
【特許文献】
【0011】
【文献】特表２０１７－５３３５０３号公報（請求項４）
【発明の概要】
【発明が解決しようとする課題】
【0012】
前述したように、図７に示す従来のシステム９０では、社内用のゲートウェイサーバ１００とは別に、社外アクセスの受け口となるインターネット公開用のゲートウェイサーバ９５をＤＭＺ（非武装地帯）上に配備していたので、同じような構成のゲートウェイサーバ（例えば、いずれもＩＢＭ社のＡＰＩコネクト（IBM APIConnect）等を利用して構築されたゲートウェイサーバ）が、２ヶ所に配置される状態であった。このため、システムの構築コストが高くなるという問題があった。従って、従来と同様にセキュリティを十分に確保することができ、かつ、安価に構築することができるシステムの開発が望まれていた。
【0013】
本発明の目的は、セキュリティを十分に確保することができ、かつ、安価に構築することができるトークン検証システムおよびプログラムを提供するところにある。
【課題を解決するための手段】
【0014】
本発明は、インターネット経由の社外アクセスのリクエストに含まれるアクセストークンおよびリフレッシュトークンを検証する処理を実行するコンピュータにより構成されたトークン検証システムであって、
インターナルクラウド環境下に置かれてアクセストークンおよびリフレッシュトークンの発行、並びにＡＰＩ（Application Programming Interface：アプリケーション・プログラミング・インターフェース）の利用の受付を行うＡＰＩ基盤システムと、
パブリッククラウド環境下に置かれて社外アクセスのリクエストを、ＡＰＩ基盤システムに連携するリクエスト連携システムとを備え、
ＡＰＩ基盤システムは、
アクセストークンおよびリフレッシュトークンを発行するトークン発行手段と、
業務処理の実行を要求する業務ＡＰＩリクエストに設定されたアクセストークン、および、アクセストークンの再発行を要求するアクセストークン再発行リクエストに設定されたリフレッシュトークンの正当性を検証するトークン検証手段とを備え、
リクエスト連携システムは、
インターネット経由の社外アクセスのリクエストを受け付けるリクエスト受付サービス手段と、
このリクエスト受付サービス手段により受け付けた社外アクセスのリクエストが業務ＡＰＩリクエストである場合には、業務ＡＰＩリクエストに設定されたアクセストークンを、イントロスペクションＡＰＩリクエストに設定してトークン検証手段に送信するとともに、トークン検証手段からのアクセストークンの検証結果を含むイントロスペクションＡＰＩ応答を受信し、社外アクセスのリクエストがアクセストークン再発行リクエストである場合には、アクセストークン再発行リクエストに設定されたリフレッシュトークンを、イントロスペクションＡＰＩリクエストに設定してトークン検証手段に送信するとともに、トークン検証手段からのリフレッシュトークンの検証結果を含むイントロスペクションＡＰＩ応答を受信するリクエストパラメータチェック手段と、
リクエスト受付サービス手段により受け付けた社外アクセスのリクエストを、ＡＰＩ基盤システムに送信する処理を実行し、この際、リクエストパラメータチェック手段により取得した検証結果が正当なトークンでない旨の情報であった場合には、社外アクセスのリクエストをＡＰＩ基盤システムに送信しないＡＰＩゲートウェイとを備えた
ことを特徴とするものである。
インターナルクラウド環境下に置かれてアクセストークンおよびリフレッシュトークンの発行、並びにＡＰＩ（Application Programming Interface：アプリケーション・プログラミング・インターフェース）の利用の受付を行うＡＰＩ基盤システムと、
パブリッククラウド環境下に置かれて社外アクセスのリクエストを、ＡＰＩ基盤システムに連携するリクエスト連携システムとを備え、
ＡＰＩ基盤システムは、
アクセストークンおよびリフレッシュトークンを発行するトークン発行手段と、
業務処理の実行を要求する業務ＡＰＩリクエストに設定されたアクセストークン、および、アクセストークンの再発行を要求するアクセストークン再発行リクエストに設定されたリフレッシュトークンの正当性を検証するトークン検証手段とを備え、
リクエスト連携システムは、
インターネット経由の社外アクセスのリクエストを受け付けるリクエスト受付サービス手段と、
このリクエスト受付サービス手段により受け付けた社外アクセスのリクエストが業務ＡＰＩリクエストである場合には、業務ＡＰＩリクエストに設定されたアクセストークンを、イントロスペクションＡＰＩリクエストに設定してトークン検証手段に送信するとともに、トークン検証手段からのアクセストークンの検証結果を含むイントロスペクションＡＰＩ応答を受信し、社外アクセスのリクエストがアクセストークン再発行リクエストである場合には、アクセストークン再発行リクエストに設定されたリフレッシュトークンを、イントロスペクションＡＰＩリクエストに設定してトークン検証手段に送信するとともに、トークン検証手段からのリフレッシュトークンの検証結果を含むイントロスペクションＡＰＩ応答を受信するリクエストパラメータチェック手段と、
リクエスト受付サービス手段により受け付けた社外アクセスのリクエストを、ＡＰＩ基盤システムに送信する処理を実行し、この際、リクエストパラメータチェック手段により取得した検証結果が正当なトークンでない旨の情報であった場合には、社外アクセスのリクエストをＡＰＩ基盤システムに送信しないＡＰＩゲートウェイとを備えた
ことを特徴とするものである。
【0015】
このような本発明のトークン検証システムにおいては、社外アクセスのリクエストを受け付けるリクエスト連携システムをパブリッククラウド環境に設け、このリクエスト連携システムのリクエストパラメータチェック手段から、社外アクセスのリクエスト内の検証対象のアクセストークンやリフレッシュトークンを設定したイントロスペクションＡＰＩリクエストを、ＡＰＩ基盤システムのトークン検証手段に送信し、トークン検証手段からのイントロスペクションＡＰＩ応答として、アクセストークンやリフレッシュトークンの正当性の検証結果を受け取るようにした。
【0016】
これにより、社外アクセスのリクエストである業務ＡＰＩリクエストやアクセストークン再発行リクエストをインターナルクラウド環境内に侵入させることなく、これらの業務ＡＰＩリクエストに設定されたアクセストークンの正当性の検証結果や、アクセストークン再発行リクエストに設定されたリフレッシュトークンの正当性の検証結果を、パブリッククラウド環境下に置かれたリクエスト連携システムで取得することが可能となる。
【0017】
従って、パブリッククラウド環境下で取得することができたアクセストークンやリフレッシュトークンの検証結果が、正当なトークンでない旨の情報であった場合には、リクエスト連携システムのＡＰＩゲートウェイにより、それらの正当でないアクセストークンやリフレッシュトークンが設定されていた業務ＡＰＩリクエストやアクセストークン再発行リクエスト、すなわち、セキュリティ上、問題のある社外アクセスのリクエストを、インターナルクラウド環境下に置かれたＡＰＩ基盤システムに送信しないようにすることができる。
【0018】
すなわち、本発明では、ＡＰＩ基盤システムのトークン発行手段によりアクセストークンおよびリフレッシュトークンを発行するので、トークン発行主体は、インターナルクラウド環境下に置かれたＡＰＩ基盤システムである。そして、発行されたトークンの検証は、トークン発行主体でしか行うことができないので、ＡＰＩ基盤システムでトークンの検証を行うことになり、ＡＰＩ基盤システムにトークン検証手段が設けられている。しかし、インターナルクラウド環境下に置かれたＡＰＩ基盤システムでアクセストークンやリフレッシュトークンの正当性の検証を行うとなると、セキュリティ上の問題を含んでいる可能性がある社外アクセスのリクエストである業務ＡＰＩリクエストやアクセストークン再発行リクエストを、インターナルクラウド環境内に侵入させることになってしまう。そこで、本発明では、イントロスペクションＡＰＩを利用し、パブリッククラウド環境下に置かれたリクエスト連携システムから、インターナルクラウド環境下に置かれたＡＰＩ基盤システムのトークン検証手段に対し、社外アクセスのリクエスト自体ではなく、そのリクエストに設定された検証対象のトークンを送信することによりトークンの検証結果を取得し、その検証結果が、正当なトークンでない旨の情報であった場合に、そのリクエスト自体をＡＰＩ基盤システムに送信（連携）しないようにしている。このため、セキュリティ上の問題を含んでいる社外アクセスのリクエスト自体が、インターナルクラウド環境内に侵入することを防ぐことができるので、セキュリティを十分に確保することが可能となっている。
【0019】
また、本発明では、パブリッククラウド環境下に置かれたリクエスト連携システムから、イントロスペクションＡＰＩを利用することにより、インターナルクラウド環境下で行われたトークン検証の結果を取得するので、前述した図７に示した従来のシステム９０のような同様の構成のゲートウェイサーバを、社外アクセス用および社内アクセス用として２ヶ所に配置することを回避することができる。このため、システムの構築コストを低減することが可能となり、これらにより前記目的が達成される。
【0020】
＜リクエスト連携システムに設けられたクライアントＩＤ・クライアントシークレット記憶手段の情報により、クライアントアプリケーションの認証を行う構成＞
【0021】
また、前述したトークン検証システムにおいて、
リクエスト連携システムは、
インターネット経由の社外アクセスのリクエストの送信元のクライアントアプリケーションに対して払い出されたクライアントＩＤおよびクライアントシークレットを記憶するクライアントＩＤ・クライアントシークレット記憶手段を備え、
リクエストパラメータチェック手段は、
社外アクセスのリクエストが業務ＡＰＩリクエストである場合、およびアクセストークン再発行リクエストである場合には、社外アクセスのリクエストに設定されているクライアントＩＤおよびクライアントシークレットの組合せが、クライアントＩＤ・クライアントシークレット記憶手段に記憶されているクライアントＩＤおよびクライアントシークレットの組合せと一致するか否かにより、クライアントアプリケーションを認証する処理も実行する構成とされていることが望ましい。
リクエスト連携システムは、
インターネット経由の社外アクセスのリクエストの送信元のクライアントアプリケーションに対して払い出されたクライアントＩＤおよびクライアントシークレットを記憶するクライアントＩＤ・クライアントシークレット記憶手段を備え、
リクエストパラメータチェック手段は、
社外アクセスのリクエストが業務ＡＰＩリクエストである場合、およびアクセストークン再発行リクエストである場合には、社外アクセスのリクエストに設定されているクライアントＩＤおよびクライアントシークレットの組合せが、クライアントＩＤ・クライアントシークレット記憶手段に記憶されているクライアントＩＤおよびクライアントシークレットの組合せと一致するか否かにより、クライアントアプリケーションを認証する処理も実行する構成とされていることが望ましい。
【0022】
このようにリクエスト連携システムに設けられたクライアントＩＤ・クライアントシークレット記憶手段の情報により、クライアントアプリケーションの認証（そのクライアントアプリケーションから送信されてくるリクエストの認証と考えてもよい。）を行う構成とした場合には、パブリッククラウド環境下に置かれたリクエスト連携システムで、クライアントアプリケーションの認証を行うこともでき、より一層、セキュリティの向上が図られる。
【0023】
＜リクエスト連携システムにパラメータコピー手段を設けた構成＞
【0024】
さらに、上述したリクエスト連携システムに設けられたクライアントＩＤ・クライアントシークレット記憶手段の情報により、クライアントアプリケーションの認証を行う構成とした場合において、
リクエスト連携システムは、
社外アクセスのリクエストがアクセストークン再発行リクエストの場合には、アクセストークン再発行リクエストのボディに設定されているリフレッシュトークンを、アクセストークン再発行リクエストのヘッダにコピーして設定するパラメータコピー手段を備え、
リクエストパラメータチェック手段は、
社外アクセスのリクエストがアクセストークン再発行リクエストである場合には、アクセストークン再発行リクエストのヘッダにコピーして設定されたリフレッシュトークンを、イントロスペクションＡＰＩリクエストに設定してトークン検証手段に送信するとともに、トークン検証手段からのリフレッシュトークンの検証結果を含むイントロスペクションＡＰＩ応答を受信する構成とされていることが望ましい。
リクエスト連携システムは、
社外アクセスのリクエストがアクセストークン再発行リクエストの場合には、アクセストークン再発行リクエストのボディに設定されているリフレッシュトークンを、アクセストークン再発行リクエストのヘッダにコピーして設定するパラメータコピー手段を備え、
リクエストパラメータチェック手段は、
社外アクセスのリクエストがアクセストークン再発行リクエストである場合には、アクセストークン再発行リクエストのヘッダにコピーして設定されたリフレッシュトークンを、イントロスペクションＡＰＩリクエストに設定してトークン検証手段に送信するとともに、トークン検証手段からのリフレッシュトークンの検証結果を含むイントロスペクションＡＰＩ応答を受信する構成とされていることが望ましい。
【0025】
このようにリクエスト連携システムにパラメータコピー手段を設けた構成とした場合には、リクエストパラメータチェック手段によりアクセストークン再発行リクエストのボディに設定されているリフレッシュトークンを読み込むことができない状況であっても、パラメータコピー手段により、アクセストークン再発行リクエストのボディに設定されているリフレッシュトークンが、ヘッダにコピーして設定されるので、リクエストパラメータチェック手段によりリフレッシュトークンを読み込むことができるようになり、イントロスペクションＡＰＩリクエストへのリフレッシュトークンの設定が可能となる。
【0026】
＜トークン検証手段により有効期限および失効フラグを用いてアクセストークンまたはリフレッシュトークンの正当性を検証する構成＞
【0027】
また、前述したトークン検証システムにおいて、
ＡＰＩ基盤システムは、
トークン発行手段によりアクセストークンおよびリフレッシュトークンを発行した際に、アクセストークンおよびリフレッシュトークンのそれぞれについての有効期限および失効フラグを、アクセストークンＩＤ若しくはアクセストークン自体およびリフレッシュトークンＩＤ若しくはリフレッシュトークン自体と関連付けて記憶するトークン情報記憶手段を備え、
トークン検証手段は、
イントロスペクションＡＰＩリクエストに設定されたアクセストークンについてのアクセストークンＩＤ若しくはアクセストークン自体と関連付けてトークン情報記憶手段に記憶されている有効期限および失効フラグを用いて、アクセストークンの正当性を検証するか、または、イントロスペクションＡＰＩリクエストに設定されたリフレッシュトークンについてのリフレッシュトークンＩＤ若しくはリフレッシュトークン自体と関連付けてトークン情報記憶手段に記憶されている有効期限および失効フラグを用いて、リフレッシュトークンの正当性を検証する構成を採用することができる。
ＡＰＩ基盤システムは、
トークン発行手段によりアクセストークンおよびリフレッシュトークンを発行した際に、アクセストークンおよびリフレッシュトークンのそれぞれについての有効期限および失効フラグを、アクセストークンＩＤ若しくはアクセストークン自体およびリフレッシュトークンＩＤ若しくはリフレッシュトークン自体と関連付けて記憶するトークン情報記憶手段を備え、
トークン検証手段は、
イントロスペクションＡＰＩリクエストに設定されたアクセストークンについてのアクセストークンＩＤ若しくはアクセストークン自体と関連付けてトークン情報記憶手段に記憶されている有効期限および失効フラグを用いて、アクセストークンの正当性を検証するか、または、イントロスペクションＡＰＩリクエストに設定されたリフレッシュトークンについてのリフレッシュトークンＩＤ若しくはリフレッシュトークン自体と関連付けてトークン情報記憶手段に記憶されている有効期限および失効フラグを用いて、リフレッシュトークンの正当性を検証する構成を採用することができる。
【0028】
このようにトークン検証手段により有効期限および失効フラグを用いてアクセストークンまたはリフレッシュトークンの正当性を検証する構成とした場合には、トークン発行手段によるアクセストークンおよびリフレッシュトークンの発行時の情報を用いて、インターナルクラウド環境下でそれぞれのトークンの正当性を確実に検証することが可能となる。
【0029】
＜プログラムの発明＞
【0030】
そして、本発明のプログラムは、以上に述べたトークン検証システムとして、コンピュータを機能させるためのものである。
【0031】
なお、上記のプログラムまたはその一部は、例えば、光磁気ディスク（ＭＯ）、コンパクトディスク（ＣＤ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、フレキシブルディスク（ＦＤ）、磁気テープ、読出し専用メモリ（ＲＯＭ）、電気的消去および書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、フラッシュディスク等の記録媒体に記録して保存や流通等させることが可能であるとともに、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等の有線ネットワーク、あるいは無線通信ネットワーク、さらにはこれらの組合せ等の伝送媒体を用いて伝送することが可能であり、また、搬送波に載せて搬送することも可能である。さらに、上記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。
【発明の効果】
【0032】
以上に述べたように本発明によれば、パブリッククラウド環境下に置かれたリクエスト連携システムから、イントロスペクションＡＰＩを利用することにより、インターナルクラウド環境下で行われたトークン検証の結果を取得するので、セキュリティを十分に確保することができ、かつ、トークン検証システムを安価に構築することができるという効果がある。
【図面の簡単な説明】
【0033】
【図1】本発明の一実施形態のトークン検証システムの全体構成図。
【図2】前記実施形態のOAuth認証・認可リクエストからＡＰＩ応答結果受信までの処理の流れ（その１）を示すフローチャートの図。
【図3】前記実施形態のOAuth認証・認可リクエストからＡＰＩ応答結果受信までの処理の流れ（その２）を示すフローチャートの図。
【図4】前記実施形態のリフレッシュトークンによるアクセストークンの再発行処理の流れを示すフローチャートの図。
【図5】前記実施形態の要部であるパブリッククラウド環境下でのリクエスト連携システムによる処理の流れを示すフローチャートの図。
【図6】前記実施形態の別の要部であるインターナルクラウド環境下でのＡＰＩ基盤システムによるトークンの発行および検証処理の説明図。
【図7】従来のシステム構成図。
【発明を実施するための形態】
【0034】
以下に本発明の一実施形態について図面を参照して説明する。図１には、本実施形態のトークン検証システム１０の全体構成が示されている。図２～図４には、トークン検証システム１０によるトークンの検証処理を含む業務ＡＰＩの実行時の流れがフローチャートで示されている。また、図５には、トークン検証システム１０による処理の要部として、パブリッククラウド環境下でのリクエスト連携システム２０による処理の流れがフローチャートで示されている。さらに、図６には、トークン検証システム１０による処理の別の要部として、インターナルクラウド環境下でのＡＰＩ基盤システム３０のゲートウェイサーバ４０によるトークンの発行および検証処理の詳細説明が示されている。
【0035】
＜トークン検証システム１０の全体構成＞
【0036】
図１において、トークン検証システム１０は、インターネット１に接続されたパブリッククラウド環境下に置かれたリクエスト連携システム２０と、このリクエスト連携システム２０と専用線２で接続されるとともに内部ネットワーク３に接続されてインターナルクラウド環境下に置かれたＡＰＩ基盤システム３０と、このＡＰＩ基盤システム３０と内部ネットワーク３で接続されてインターナルクラウド環境下に置かれたバックエンドシステム６０とを備えて構成されている。また、内部ネットワーク３には、社内コンシューマ７０（ここでは、コンシューマを装置として捉えている。）が接続されている。さらに、インターネット１には、社外のエンドユーザ（例えば、フィンテック（FinTech）企業の担当者）が操作するクライアント端末８０が接続されている。
【0037】
ここで、専用線２としては、例えば、アマゾン社（Amazon）のＡＷＳ（Amazon Web Services：アマゾン・ウェブ・サービス）であるダイレクト接続サービス（AWS Direct Connect）で提供される専用線等を採用することができる。
【0038】
また、内部ネットワーク３は、例えば、社内イントラネットや社内ＬＡＮ等であり、有線であるか無線であるか、さらには有線および無線の混在型であるかは問わず、要するに、複数地点（距離の長短は問わない。）間で、ある程度の速度をもって情報を伝送することができるものであればよい。この内部ネットワーク３に接続された各装置は、インターナルクラウド環境下に置かれていることになる。
【0039】
リクエスト連携システム２０は、インターネット１に接続されたパブリッククラウド環境下に置かれ、社外アクセスのリクエスト（社外のエンドユーザが操作するクライアント端末８０からインターネット１を介して送信されてくるリクエスト）を、専用線２を介してＡＰＩ基盤システム３０に連携（送信）するものであり、１台または複数台のコンピュータにより構成され、リクエスト受付サービス手段２１と、パラメータコピー手段２２と、ＡＰＩゲートウェイ２３と、リクエストパラメータチェック手段２４と、クライアントＩＤ・クライアントシークレット記憶手段２５とを含んで構成されている。また、このリクエスト連携システム２０とインターネット１との間には、ＷＥＢアプリケーションファイアウォール２６が設けられている。なお、本実施形態では、リクエスト連携システム２０には、アマゾン社（Amazon）のアマゾンＡＰＩゲートウェイ（Amazon APIGateway）を採用し、従って、パブリッククラウド環境は、アマゾン社（Amazon）のＡＷＳクラウド（AWS Cloud）により構築されているが、これに限定されるものではない。
【0040】
ここで、リクエスト受付サービス手段２１、パラメータコピー手段２２、ＡＰＩゲートウェイ２３、リクエストパラメータチェック手段２４は、リクエスト連携システム２０を構成するコンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段２１～２４の詳細は後述する。
【0041】
また、クライアントＩＤ・クライアントシークレット記憶手段２５としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。このクライアントＩＤ・クライアントシークレット記憶手段２５の詳細は後述する。
【0042】
ＡＰＩ基盤システム３０は、内部ネットワーク３に接続されたインターナルクラウド環境下に置かれ、ＡＰＩの利用の受付および管理を行うものであり、１台または複数台のコンピュータにより構成され、ゲートウェイサーバ４０と、ＡＰＩ管理サーバ５０とを備えている。これらのゲートウェイサーバ４０と、ＡＰＩ管理サーバ５０とが、それぞれ何台のコンピュータにより構成されるか、あるいは同じ１台のコンピュータで構成されるかは任意である。なお、本実施形態では、ＡＰＩ基盤システム３０には、ＩＢＭ社のＡＰＩコネクト（IBM API Connect）を採用しているが、これに限定されるものではない。
【0043】
ゲートウェイサーバ４０は、ＡＰＩリクエストの受付処理を実行するものであり、認証システム誘導手段４１と、認可コード発行手段４２と、トークン発行手段４３と、トークン検証手段４４と、各種の業務ＡＰＩ定義実行手段４５と、ＡＰＩ事後処理手段４６と、トークン情報記憶手段４７と、暗号鍵記憶手段４８とを含んで構成されている。
【0044】
ここで、認証システム誘導手段４１、認可コード発行手段４２、トークン発行手段４３、トークン検証手段４４、業務ＡＰＩ定義実行手段４５、ＡＰＩ事後処理手段４６は、ゲートウェイサーバ４０を構成するコンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段４１～４６の詳細は後述する。
【0045】
また、トークン情報記憶手段４７、暗号鍵記憶手段４８としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。これらの記憶手段４７，４８の詳細は後述する。
【0046】
ＡＰＩ管理サーバ５０は、ＡＰＩの実行に必要なデータの管理処理を実行するものであり、ＡＰＩ利用カタログ記憶手段５１を含んで構成されている。このＡＰＩ利用カタログ記憶手段５１としては、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等の不揮発性メモリを採用することができる。このＡＰＩ利用カタログ記憶手段５１の詳細は後述する。
【0047】
バックエンドシステム６０は、社外のエンドユーザの認証およびそのリクエスト内容の認可を行うユーザ認証システム６１と、ＡＰＩ実行者（ＡＰＩ利用対象者のうちの実際にＡＰＩを利用した者であり、人間だけではなく、システムも含む。）によるＡＰＩリクエストに応じて各種の業務処理を実行する各種の業務処理システム６２とを備えて構成されている。
【0048】
ユーザ認証システム６１は、１台または複数台のコンピュータにより構成され、ユーザ認証手段６１Ａと、認可手段６１Ｂとを含んで構成されている。これらのユーザ認証手段６１Ａ、認可手段６１Ｂは、ユーザ認証システム６１を構成するコンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの各手段６１Ａ，６１Ｂの詳細は後述する。
【0049】
業務処理システム６２は、１台または複数台のコンピュータにより構成され、各種の業務についてのバックエンド業務処理（例えば、顧客情報の参照対応、金融商品等に係る顧客の売買取引データの登録、更新、削除等）を実行する各種の業務処理手段６２Ａを含んで構成されている。これらの業務処理手段６２Ａは、業務処理システム６２を構成するコンピュータの内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラム、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。これらの業務処理手段６２Ａの詳細は後述する。
【0050】
なお、業務処理システム６２は、図示は省略されているが、各種の業務処理手段６２Ａにより各種のバックエンド業務処理を実行するのに必要な各種のデータ（例えば、顧客情報、売買取引に関するデータなど）を記憶する業務処理用データ記憶手段を備えている。
【0051】
社内コンシューマ７０は、本実施形態では、人間ではなく、１台または複数台のコンピュータにより構成された装置として記載され、社内の他のシステムのサーバや、社内ユーザが操作する社内の端末である。なお、ここでいう社内の他のシステムも、社外アクセスのリクエストに応じてバックエンド業務処理を行う業務処理システム６２になり得るため、バックエンドシステム６０に含めてもよいものであるが、説明の便宜上、社外からではなく、社内から業務ＡＰＩリクエストを送信する側のシステムとして、バックエンドシステム６０に含めずに記載している。また、本発明は、社外アクセスのリクエストを処理するものであり、社内コンシューマ７０による社内アクセスのリクエストの処理は関係ないので、社内コンシューマ７０は、２点鎖線で記載されている。社内アクセスのリクエストの処理については、前述した図７に示した従来のシステム９０の場合と同じであることを示すために記載したものである。
【0052】
クライアント端末８０は、コンピュータにより構成され、社外のエンドユーザの操作に基づき、リクエスト連携システム２０に対し、インターネット１を介して各種のリクエストを送信するクライアントアプリケーションにより実現される処理手段８１を備えている。このクライアントアプリケーションは、少なくともリクエスト送信時には、リクエスト連携システム２０から払い出されたクライアントＩＤおよびクライアントシークレットを保持している。保持の形態は、社外のエンドユーザの入力操作を受け付け、入力されたクライアントＩＤおよびクライアントシークレットを、クライアント端末８０に設けられたクライアントＩＤ・クライアントシークレットローカル記憶手段（図示されない不揮発性メモリにより構成される。）に記憶しておく形態でもよく、毎回、社外のエンドユーザの入力操作を受け付ける形態でもよく、クライアントアプリケーションのプログラム内に記述（コーディング）しておく形態でもよい。
【0053】
ここで、処理手段８１は、クライアント端末８０に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラムであるクライアントアプリケーションやこのクライアントアプリケーションによりインポートされる各種のライブラリ、並びに主メモリやキャッシュメモリ等の作業用メモリにより実現される。この処理手段８１の詳細は後述する。
【0054】
＜リクエスト連携システム２０／リクエスト受付サービス手段２１の構成＞
【0055】
リクエスト受付サービス手段２１は、社外のエンドユーザが操作するクライアント端末８０からインターネット１を介して送信されてきてＷＥＢアプリケーションファイアウォール２６を通過した社外アクセスのリクエストを受け付け、受け付けたリクエストの種別を判定し、判定したリクエストの種別に応じ、後続の各処理への移行のための分岐処理を実行するものである。なお、本実施形態では、リクエスト受付サービス手段２１には、一例として、アマゾン社（Amazon）のクラウドフロント（Cloud Front）を採用している。
【0056】
具体的には、リクエスト受付サービス手段２１によるリクエストの種別の判定では、後述する図５に示すように、受け付けたリクエストが、認証・認可リクエスト（後述する図２のステップＳ３の場合）、または認可コード発行リクエスト（後述する図２のステップＳ１３の場合）であるかを判定する。これらの判定は、リクエストのＵＲＬパスを用いて行われ、本実施形態では、一例として、パスが＜/oauth2/authorize＞の場合には、認証・認可リクエストまたは認可コード発行リクエストであると判定し、さらに、リクエストに、確認ＩＤおよび確認コードがない場合には、認証・認可リクエスト（図２のステップＳ３の場合）であると判定し、後述する図２のステップＳ４の処理に移行し、確認ＩＤおよび確認コードがある場合には、認可コード発行リクエスト（図２のステップＳ１３の場合）であると判定し、後述する図２のステップＳ１４の処理に移行する。
【0057】
また、リクエスト受付サービス手段２１は、図５に示すように、受け付けたリクエストが、トークン発行リクエストのうちのアクセストークン発行リクエスト（図３のステップＳ１８の場合）であるかを判定する。この判定は、リクエストのＵＲＬパスおよびリクエストのボディのグラントタイプを用いて行われ、本実施形態では、一例として、パスが＜/oauth2/token＞であり、かつ、ボディのグラントタイプがauthorization_codeである場合には、アクセストークン発行リクエストであると判定し、後述する図３のステップＳ１９の処理に移行する。
【0058】
さらに、リクエスト受付サービス手段２１は、図５に示すように、受け付けたリクエストが、トークン発行リクエストのうちのリフレッシュトークンによるアクセストークン再発行リクエスト（後述する図４のステップＳ５１の場合）であるかを判定する。この判定は、リクエストのＵＲＬパスおよびリクエストのボディのグラントタイプを用いて行われ、本実施形態では、一例として、パスが＜/oauth2/token＞であり、かつ、ボディのグラントタイプがrefresh_tokenである場合には、リフレッシュトークンによるアクセストークン再発行リクエストであると判定し、後述する図４のステップＳ５２の処理に移行する。
【0059】
また、リクエスト受付サービス手段２１は、図５に示すように、受け付けたリクエストが、業務ＡＰＩリクエスト（後述する図３のステップＳ２４、または図４のステップＳ５８の場合）であるかをＵＲＬパスで判定する。業務ＡＰＩリクエストと判定した場合は、後述する図３のステップＳ２５、または図４のステップＳ５９の処理に移行する。
【0060】
＜リクエスト連携システム２０／パラメータコピー手段２２の構成＞
【0061】
パラメータコピー手段２２は、図５に示すように、リクエスト受付サービス手段２１により受け付けた社外アクセスのリクエストが、アクセストークン発行リクエストである場合（図３のステップＳ１８の場合）には、リクエストのボディに設定されているクライアントＩＤおよびクライアントシークレットを、リクエストのヘッダにコピーして設定する処理（後述する図３のステップＳ１９の処理）を実行し、リフレッシュトークンによるアクセストークン再発行リクエストである場合（後述する図４のステップＳ５１の場合）には、リクエストのボディに設定されているリフレッシュトークン、クライアントＩＤおよびクライアントシークレットを、リクエストのヘッダにコピーして設定する処理（後述する図４のステップＳ５２の処理）を実行するものである。いずれの処理も、リクエスト受付サービス手段２１による依頼（指示）を受けて実行し、コピー処理後のトークンをリクエスト受付サービス手段２１に返す。なお、本実施形態では、パラメータコピー手段２２には、一例として、アマゾン社（Amazon）のラムダエッジ（Lambda＠Edge）を採用している。
【0062】
このパラメータコピー手段２２による処理を行うのは、リクエストパラメータチェック手段２４によりクライアントＩＤおよびクライアントシークレットを用いてクライアントアプリケーションの認証を行う際（後述する図３のステップＳ２０および図４のステップＳ５３の処理を行う際）に、リクエストのボディに設定されているクライアントＩＤおよびクライアントシークレットを取得できない場合があり、また、リクエストパラメータチェック手段２４によりリフレッシュトークンの正当性の検証を行う際（後述する図４のステップＳ５４の処理を行う際）に、リクエストのボディに設定されているリフレッシュトークンを取得できない場合があるからである。例えば、リクエストパラメータチェック手段２４として、アマゾン社（Amazon）のラムダオーソライザ（Lambda Authorizer）を採用すると、リクエストのボディの値を取得することができない。
【0063】
なお、上記でコピーの対象とされている情報を、最初からヘッダに設定せずに、ボディに設定しているのは、セキュリティを確保するためである。すなわち、ボディは暗号化されているので、たとえ盗用されても中身の内容を確認することはできないため、外部への漏洩を避けたいパラメータは、一般的にボディに設定するからである。
【0064】
＜リクエスト連携システム２０／ＡＰＩゲートウェイ２３の構成＞
【0065】
ＡＰＩゲートウェイ２３は、リクエスト受付サービス手段２１により受け付けた社外アクセスのリクエストを、専用線２を介してＡＰＩ基盤システム３０に送信する処理を実行するものである。
【0066】
この際、ＡＰＩゲートウェイ２３は、リクエストパラメータチェック手段２４に対し、社外アクセスのリクエストの送信元のクライアント端末８０に搭載されたクライアントアプリケーションの認証を依頼し、リクエストパラメータチェック手段２４による認証結果が失敗であった場合には、その社外アクセスのリクエストをＡＰＩ基盤システム３０に送信せずに、認証エラーが発生した旨を、インターネット１を介してクライアント端末８０に送信する。
【0067】
また、ＡＰＩゲートウェイ２３は、社外アクセスのリクエストにアクセストークンまたはリクエストトークンが含まれている場合（図５に示すように、社外アクセスのリクエストが、業務ＡＰＩリクエストである場合（後述する図３のステップＳ２４、または図４のステップＳ５８の場合）、および、リフレッシュトークンによるアクセストークン再発行リクエストである場合（後述する図４のステップＳ５１の場合））には、リクエストパラメータチェック手段２４に対し、その旨を伝達してイントロスペクションＡＰＩを利用したトークン検証を依頼し、リクエストパラメータチェック手段２４によりイントロスペクションＡＰＩ応答として得られた各トークンの検証結果が正当なトークンでない旨の情報であった場合には、そのトークンを含む社外アクセスのリクエストをＡＰＩ基盤システム３０に送信せずに、認証エラーが発生した旨を、インターネット１を介してクライアント端末８０に送信する。
【0068】
従って、リクエストの送信元のクライアントアプリケーションの認証に失敗した場合や、イントロスペクションＡＰＩ応答として得られた各トークンの正当性の検証結果が正当なトークンでないという結果であった場合には、インターナルクラウド内への社外アクセスのリクエストの侵入を防止できるようになっている。なお、本実施形態では、ＡＰＩゲートウェイ２３には、一例として、アマゾン社（Amazon）のＡＰＩゲートウェイ（APIGateway）を採用している。
【0069】
＜リクエスト連携システム２０／リクエストパラメータチェック手段２４の構成＞
【0070】
リクエストパラメータチェック手段２４は、ＡＰＩゲートウェイ２３からクライアントアプリケーションの認証依頼を受け、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されている情報を用いて、社外アクセスのリクエストの送信元のクライアント端末８０に搭載されたクライアントアプリケーションを認証し（そのクライアントアプリケーションから送信されてくるリクエストを認証すると考えてもよい。）、その認証結果（認証に成功したか、失敗したかの別を示す情報）を、ＡＰＩゲートウェイ２３に返信する処理を実行するものであり、具体的には、以下の処理を実行する。
【0071】
すなわち、リクエストパラメータチェック手段２４は、リクエスト受付サービス手段２１により受け付けた社外アクセスのリクエストが認証・認可リクエストの場合、および認可コード発行リクエストの場合（図５に示すように、後述する図３のステップＳ３，Ｓ１３の場合）には、リクエストのクエリに設定されているクライアントＩＤが、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されているクライアントＩＤの中に存在していることをチェックする処理を実行する。存在していれば、認証成功であり、存在していなければ、認証失敗である。なお、クエリの情報を用いるので、クライアントシークレットは認証に使用しない。
【0072】
また、リクエストパラメータチェック手段２４は、社外アクセスのリクエストがアクセストークン発行リクエストの場合（後述する図３のステップＳ１８の場合）、および、リフレッシュトークンによるアクセストークン再発行リクエストである場合（後述する図４のステップＳ５１の場合）には、リクエストのヘッダに設定されているクライアントＩＤおよびクライアントシークレットの組合せ（事前にパラメータコピー手段２２によりリクエストのボディからヘッダにコピーして設定した組合せ）が、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されているクライアントＩＤおよびクライアントシークレットの組合せと一致するか否かにより、クライアントアプリケーションを認証する処理を実行する。一致していれば、認証成功であり、一致していなければ、認証失敗である。
【0073】
さらに、リクエストパラメータチェック手段２４は、社外アクセスのリクエストが業務ＡＰＩリクエストである場合（後述する図３のステップＳ２４、または図４のステップＳ５８の場合）には、社外アクセスのリクエストのヘッダに設定されているクライアントＩＤおよびクライアントシークレットの組合せが、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されているクライアントＩＤおよびクライアントシークレットの組合せと一致するか否かにより、クライアントアプリケーションを認証する処理を実行する。一致していれば、認証成功であり、一致していなければ、認証失敗である。
【0074】
そして、リクエストパラメータチェック手段２４は、以上のクライアントアプリケーションの認証処理に加え、ＡＰＩゲートウェイ２３からイントロスペクションＡＰＩを利用したトークンの検証依頼を受け、イントロスペクションＡＰＩを利用して得られたトークンの検証結果（検証対象のトークンが正当なものであるか否かの判断結果）を、ＡＰＩゲートウェイ２３に返信する処理を実行するものであり、具体的には、以下の処理を実行する。
【0075】
すなわち、リクエストパラメータチェック手段２４は、リクエスト受付サービス手段２１により受け付けた社外アクセスのリクエストが業務ＡＰＩリクエストである場合（図５に示すように、後述する図３のステップＳ２４、または図４のステップＳ５８の場合）には、業務ＡＰＩリクエストのヘッダに設定されたアクセストークンを、イントロスペクションＡＰＩリクエストのボディに設定して専用線２を介してゲートウェイサーバ４０のトークン検証手段４４に送信するとともに、トークン検証手段４４から専用線２を介して送信されてくるアクセストークンの検証結果を含むイントロスペクションＡＰＩ応答を受信する処理を実行する。この際、イントロスペクションＡＰＩリクエストのボディには、検証対象のアクセストークンの他に、クライアントＩＤおよびクライアントシークレットも設定される。
【0076】
また、リクエストパラメータチェック手段２４は、社外アクセスのリクエストがリフレッシュトークンによるアクセストークン再発行リクエストである場合（図５に示すように、後述する図４のステップＳ５１の場合）には、アクセストークン再発行リクエストのヘッダに設定されたリフレッシュトークン（パラメータコピー手段２２によりボディからヘッダにコピーして設定したもの）を、イントロスペクションＡＰＩリクエストのボディに設定して専用線２を介してトークン検証手段４４に送信するとともに、トークン検証手段４４から専用線２を介して送信されてくるリフレッシュトークンの検証結果を含むイントロスペクションＡＰＩ応答を受信する処理を実行する。この際、イントロスペクションＡＰＩリクエストのボディには、検証対象のリフレッシュトークンの他に、クライアントＩＤおよびクライアントシークレット（パラメータコピー手段２２によりボディからヘッダにコピーして設定したもの）も設定される。
【0077】
なお、社外アクセスのリクエストがアクセストークン発行リクエストである場合（図５に示すように、後述する図３のステップＳ１８の場合）には、検証対象のトークンが存在しないので、イントロスペクションＡＰＩの利用はない。認証・認可リクエストの場合、および認可コード発行リクエストの場合（図５に示すように、後述する図３のステップＳ３，Ｓ１３の場合）も、検証対象のトークンが存在しないので、イントロスペクションＡＰＩの利用はない。
【0078】
また、本実施形態では、リクエストパラメータチェック手段２４には、一例として、アマゾン社（Amazon）のラムダオーソライザ（Lambda Authorizer）を採用している。
【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】
処理手段８１は、クライアント端末８０に搭載されたクライアントアプリケーション（例えば、パイソン（Python）で記述されたアプリケーションや、Ｗｅｂアプリケーション）およびこのクライアントアプリケーションによりインポートされた各種のライブラリ（認可コード発行リクエスト用ライブラリ、トークン発行リクエスト用ライブラリ、ＡＰＩ呼出用ライブラリ）により実現される各種の処理を実行するものである。
【0117】
具体的には、処理手段８１は、認可コード発行リクエストの送信処理、認可コードの受信処理、トークン発行リクエストの送信処理、トークン（アクセストークンおよびリフレッシュトークン）の受信処理、ＡＰＩ呼出処理（業務ＡＰＩリクエストの送信処理）、ＡＰＩ応答の受信処理を実行するものである。
【0118】
【0119】
【0120】
図２において、社外のエンドユーザは、クライアントアプリケーションが搭載されたクライアント端末８０を操作し、業務ＡＰＩにより、バックエンドシステム６０の各種の業務処理システム６２にアクセスし、これらの業務処理システム６２に設けられた各種の業務データベース（不図示）に記憶されている各種のデータを利用して業務処理を実行するサービスの利用を開始する（ステップＳ１）。
【0121】
先ず、クライアント端末８０から、処理手段８１により、Ｏａｕｔｈ２．０仕様の認証・認可リクエスト（クエリにクライアントＩＤを含む。）を、インターネット１を介してリクエスト連携システム２０に送信する（ステップＳ２）。
【0122】
リクエスト連携システム２０では、リクエスト受付サービス手段２１により、クライアント端末８０からの社外アクセスのリクエストを受け付け、受け付けたリクエストの種別の判定を行う。ここでは、例えば、リクエストのパスが＜/oauth2/authorize＞であり、かつ、リクエストに確認ＩＤおよび確認コードが含まれていないので、認証・認可リクエストであると判定される（ステップＳ３）。
【0123】
続いて、この認証・認可リクエストは、ＡＰＩゲートウェイ２３に送られ、ＡＰＩゲートウェイ２３からの依頼を受けて、リクエストパラメータチェック手段２４により、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されている情報を用いて、社外アクセスのリクエストの送信元のクライアント端末８０に搭載されたクライアントアプリケーションを認証し、その認証結果（認証に成功したか、失敗したかの別を示す情報）を、ＡＰＩゲートウェイ２３に返信する。
【0124】
ここでは、リクエストパラメータチェック手段２４は、社外アクセスのリクエストが認証・認可リクエストの場合であるから、リクエストのクエリに設定されているクライアントＩＤが、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されているクライアントＩＤの中に存在していることをチェックする（ステップＳ４）。存在していれば、認証成功であり、存在していなければ、認証失敗である。なお、クエリの情報を用いるので、クライアントシークレットはここでの認証に使用しない。
【0125】
それから、クライアントアプリケーションの認証に成功した場合には、ＡＰＩゲートウェイ２３により、認証・認可リクエストが、専用線２を介してＡＰＩ基盤システム３０のゲートウェイサーバ４０の認証システム誘導手段４１に送信され、さらに認証システム誘導手段４１により、認証・認可リクエストが、内部ネットワーク３を介してバックエンドシステム６０のユーザ認証システム６１のユーザ認証手段６１Ａに送信される（ステップＳ５）。一方、クライアントアプリケーションの認証に失敗した場合には、認証・認可リクエストは、認証システム誘導手段４１に送信されず、ＡＰＩゲートウェイ２３により、認証エラーが発生した旨の情報が、インターネット１を介してクライアント端末８０に送信される。
【0126】
続いて、ユーザ認証システム６１では、ユーザ認証手段６１Ａにより、認証システム誘導手段４１から内部ネットワーク３を介して送信されてくるＯａｕｔｈ２．０仕様の認証・認可リクエスト（クエリにクライアントＩＤを含む。）を受信し、ユーザ認証画面の表示用データを、インターネット１を介してクライアント端末８０に送信する（ステップＳ６）。
【0127】
クライアント端末８０では、処理手段８１により、ユーザ認証手段６１Ａからインターネット１を介して送信されてくるユーザ認証画面の表示用データを受信し、社外のエンドユーザに対し、ユーザ認証画面を表示する。そして、エンドユーザは、表示されたユーザ認証画面上でユーザＩＤおよびパスワードを入力し、処理手段８１は、入力されたユーザＩＤおよびパスワードを、インターネット１を介してユーザ認証手段６１Ａに送信する（ステップＳ７）。
【0128】
ユーザ認証手段６１Ａは、クライアント端末８０からインターネット１を介して送信されてくるユーザＩＤおよびパスワードを受信し、受信したユーザＩＤおよびパスワードを用いて、社外のエンドユーザについてのユーザ認証処理を実行する（ステップＳ８）。そして、ユーザ認証手段６１Ａは、ユーザ認証に成功した場合には、認可手段６１Ｂに処理を移行させる。一方、ユーザ認証に失敗した場合には、認証エラーが発生した旨の情報を、インターネット１を介してクライアント端末８０に送信する。
【0129】
それから、ユーザ認証に成功した場合には、認可手段６１Ｂにより、ユーザ権限認可画面の表示用データを、インターネット１を介してクライアント端末８０に送信する（ステップＳ９）。クライアント端末８０では、処理手段８１により、認可手段６１Ｂからインターネット１を介して送信されてくるユーザ権限認可画面の表示用データを受信し、社外のエンドユーザに対し、ユーザ権限認可画面を表示する。そして、エンドユーザは、表示されたユーザ権限認可画面上でスコープ（認可を得るユーザ権限の範囲）を入力し、処理手段８１は、入力されたスコープを、インターネット１を介して認可手段６１Ｂに送信する（ステップＳ１０）。
【0130】
認可手段６１Ｂは、クライアント端末８０からインターネット１を介して送信されてくるスコープ（認可を得るユーザ権限の範囲）の情報を受信し、受信したスコープの情報を用いて、ユーザの権限の認可処理を実行する（ステップＳ１１）。そして、認可手段６１Ｂは、認可に成功した場合には、確認ＩＤおよび確認コードを発行し、発行した確認ＩＤおよび確認コードを、インターネット１を介してクライアント端末８０に送信する。一方、認可に失敗した場合には、認可エラーが発生した旨の情報を、インターネット１を介してクライアント端末８０に送信する。
【0131】
その後、クライアント端末８０では、処理手段８１により、認可手段６１Ｂからインターネット１を介して送信されてくる確認ＩＤおよび確認コードを受信し、認可コード発行リクエスト（クエリにクライアントＩＤ、確認ＩＤおよび確認コードを含む。）を作成し、インターネット１を介してリクエスト連携システム２０に送信する（ステップＳ１２）。
【0132】
リクエスト連携システム２０では、リクエスト受付サービス手段２１により、クライアント端末８０からの社外アクセスのリクエストを受け付け、受け付けたリクエストの種別の判定を行う。ここでは、例えば、リクエストのパスが＜/oauth2/authorize＞であり、かつ、リクエストに確認ＩＤおよび確認コードが含まれているので、認可コード発行リクエストであると判定される（ステップＳ１３）。
【0133】
続いて、この認可コード発行リクエスト（クエリにクライアントＩＤ、確認ＩＤおよび確認コードを含む。）は、ＡＰＩゲートウェイ２３に送られ、ＡＰＩゲートウェイ２３からの依頼を受けて、リクエストパラメータチェック手段２４により、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されている情報を用いて、社外アクセスのリクエストの送信元のクライアント端末８０に搭載されたクライアントアプリケーションを認証し、その認証結果（認証に成功したか、失敗したかの別を示す情報）を、ＡＰＩゲートウェイ２３に返信する。
【0134】
ここでは、リクエストパラメータチェック手段２４は、社外アクセスのリクエストが認可コード発行リクエストの場合であるから、リクエストのクエリに設定されているクライアントＩＤが、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されているクライアントＩＤの中に存在していることをチェックする（ステップＳ１４）。存在していれば、認証成功であり、存在していなければ、認証失敗である。なお、クエリの情報を用いるので、クライアントシークレットはここでの認証に使用しない。
【0135】
それから、クライアントアプリケーションの認証に成功した場合には、ＡＰＩゲートウェイ２３により、認可コード発行リクエストが、専用線２を介してＡＰＩ基盤システム３０のゲートウェイサーバ４０の認可コード発行手段４２に送信され、認可コード発行手段４２により認可コードが発行され、発行された認可コードが、専用線２、ＡＰＩゲートウェイ２３、およびインターネット１を介してクライアント端末８０に送信される（ステップＳ１５）。
【0136】
図３において、クライアント端末８０では、処理手段８１により、認可コード発行手段４２から送信されてくる認可コードを受信し（ステップＳ１６）、アクセストークン発行リクエスト（ボディに、認可コード、クライアントＩＤおよびクライアントシークレットを含む。）を作成し、作成したアクセストークン発行リクエストを、インターネット１を介してリクエスト連携システム２０に送信する（ステップＳ１７）。
【0137】
リクエスト連携システム２０では、リクエスト受付サービス手段２１により、クライアント端末８０からの社外アクセスのリクエストを受け付け、受け付けたリクエストの種別の判定を行う。ここでは、例えば、リクエストＵＲＬパスが＜/oauth2/token＞であり、かつ、リクエストのボディのグラントタイプがauthorization_codeであるので、アクセストークン発行リクエストであると判定される（ステップＳ１８）。
【0138】
続いて、リクエスト受付サービス手段２１は、受け付けた社外アクセスのリクエストがアクセストークン発行リクエストであると判定したので、パラメータコピー手段２２に対し、コピー処理を行うように依頼（指示）する。パラメータコピー手段２２は、リクエスト受付サービス手段２１から、コピー依頼に係るアクセストークン発行リクエストを受け取り、受け取ったリクエストのボディに設定されているクライアントＩＤおよびクライアントシークレットを、リクエストのヘッダにコピーして設定し、コピー処理後のアクセストークン発行リクエストを、リクエスト受付サービス手段２１に返す（ステップＳ１９）。
【0139】
それから、リクエスト受付サービス手段２１は、コピー処理後のアクセストークン発行リクエスト（ヘッダにクライアントＩＤおよびクライアントシークレットが設定されている状態）を、ＡＰＩゲートウェイ２３に送る。そして、ＡＰＩゲートウェイ２３は、受け取ったコピー処理後のアクセストークン発行リクエストを、リクエストのパラメータのチェックを行うために、リクエストパラメータチェック手段２４に送る。
【0140】
リクエストパラメータチェック手段２４は、ＡＰＩゲートウェイ２３からのパラメータのチェック依頼を受けて、コピー処理後のアクセストークン発行リクエストのヘッダに設定されているクライアントＩＤおよびクライアントシークレットの組合せが、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されているクライアントＩＤおよびクライアントシークレットの組合せと一致するか否かにより、クライアントアプリケーションを認証する処理を実行する（ステップＳ２０）。一致していれば、認証成功であり、一致していなければ、認証失敗である。このクライアントアプリケーションの認証結果は、ＡＰＩゲートウェイ２３に返信される。
【0141】
ＡＰＩゲートウェイ２３は、クライアントアプリケーションの認証成功という認証結果を受け取った場合には、アクセストークン発行リクエストを、専用線２を介してＡＰＩ基盤システム３０のゲートウェイサーバ４０のトークン発行手段４３に送信する。一方、認証失敗という認証結果を受け取った場合には、認証エラーが発生した旨の情報を、インターネット１を介してクライアント端末８０に送信する。これにより、正当でないアクセストークン発行リクエストがインターナルクラウド内に侵入することを防止している。
【0142】
ゲートウェイサーバ４０では、トークン発行手段４３により、ＡＰＩゲートウェイ２３から専用線２を介して送信されてくるアクセストークン発行リクエスト（認可コード、クライアントＩＤおよびクライアントシークレットを含む。）を受信した場合には、アクセストークンおよびリフレッシュトークンを発行し、発行したアクセストークンおよびリフレッシュトークンを暗号鍵記憶手段４８に記憶された暗号鍵を用いて暗号化してから、専用線２、ＡＰＩゲートウェイ２３、およびインターネット１を介してクライアント端末８０に送信する（ステップＳ２１）。
【0143】
この際、トークン発行手段４３は、図６に示すように、発行したアクセストークンおよびリフレッシュトークンの各々についての発行日時、有効期限、失効フラグを、それぞれのトークンのＩＤ（例えば、それぞれのトークンのハッシュ値）またはそれぞれのトークン自体と関連付けてトークン情報記憶手段４７に記憶させる。
【0144】
クライアント端末８０では、処理手段８１により、トークン発行手段４３から、専用線２、ＡＰＩゲートウェイ２３、およびインターネット１を介して送信されてくるアクセストークンおよびリフレッシュトークンを受信し（ステップＳ２２）、業務ＡＰＩリクエスト（ヘッダに、アクセストークン、クライアントＩＤ、クライアントシークレットを含む。）を作成し、作成した業務ＡＰＩリクエストを、インターネット１を介してリクエスト連携システム２０に送信する（ステップＳ２３）。
【0145】
リクエスト連携システム２０では、リクエスト受付サービス手段２１により、クライアント端末８０からの社外アクセスのリクエストを受け付け、受け付けたリクエストの種別の判定を行う。ここでは、リクエストのパスにより、業務ＡＰＩリクエストであると判定される（ステップＳ２４）。
【0146】
続いて、リクエスト受付サービス手段２１は、受け付けた社外アクセスのリクエストが業務ＡＰＩリクエストであると判定したので、その業務ＡＰＩリクエストをＡＰＩゲートウェイ２３に送る。そして、ＡＰＩゲートウェイ２３は、受け取った業務ＡＰＩリクエストを、リクエストのパラメータのチェックを行うために、リクエストパラメータチェック手段２４に送る。
【0147】
リクエストパラメータチェック手段２４は、ＡＰＩゲートウェイ２３からのパラメータのチェック依頼を受けて、先ず、業務ＡＰＩリクエストのヘッダに設定されているクライアントＩＤおよびクライアントシークレットの組合せが、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されているクライアントＩＤおよびクライアントシークレットの組合せと一致するか否かにより、クライアントアプリケーションを認証する処理を実行する（ステップＳ２５）。一致していれば、認証成功であり、一致していなければ、認証失敗である。
【0148】
次に、リクエストパラメータチェック手段２４は、業務ＡＰＩリクエストのヘッダに設定されたアクセストークンを取得し、取得したアクセストークンをイントロスペクションＡＰＩリクエストのボディに設定し、このイントロスペクションＡＰＩリクエストを、専用線２を介してゲートウェイサーバ４０のトークン検証手段４４に送信するとともに、トークン検証手段４４から専用線２を介して送信されてくるアクセストークンの検証結果を含むイントロスペクションＡＰＩ応答を受信する（ステップＳ２６）。なお、ゲートウェイサーバ４０のトークン検証手段４４による検証処理の内容は、トークン検証手段４４の説明で既に詳述しているので、ここでは詳しい説明を省略する。
【0149】
リクエストパラメータチェック手段２４は、上述したステップＳ２５のクライアントアプリケーションの認証処理の結果、および、ステップＳ２６のトークンの検証処理の結果を、ＡＰＩゲートウェイ２３に返す。
【0150】
ＡＰＩゲートウェイ２３は、リクエストパラメータチェック手段２４から受け取ったクライアントアプリケーションの認証処理の結果が、認証成功という結果であり、かつ、トークンの検証処理の結果が、トークンは正当なものであるという結果であった場合には、業務ＡＰＩリクエストを、専用線２を介してＡＰＩ基盤システム３０のゲートウェイサーバ４０の業務ＡＰＩ定義実行手段４５（各種の業務ＡＰＩ定義実行手段４５のうち、業務ＡＰＩリクエストで要求されている業務処理を実行するための業務ＡＰＩ定義実行手段４５）に送信する。一方、ＡＰＩゲートウェイ２３は、クライアントアプリケーションの認証処理の結果が、認証失敗という結果であった場合、または、トークンの検証結果が、トークンは正当なものでないという結果であった場合には、業務ＡＰＩリクエストをＡＰＩ基盤システム３０に送信せずに、認証エラーが発生した旨を、インターネット１を介してクライアント端末８０に送信する。これにより、正当でない業務ＡＰＩリクエストがインターナルクラウド内に侵入することを防止している。
【0151】
ゲートウェイサーバ４０では、業務ＡＰＩ定義実行手段４５により、ＡＰＩゲートウェイ２３から専用線２を介して送信されてくる業務ＡＰＩリクエストを受信した場合には、受信した業務ＡＰＩリクエストの内容に応じて、ＡＰＩ管理サーバ５０のＡＰＩ利用カタログ記憶手段５１から、内部ネットワーク３を介してＡＰＩ実行者（ここではクライアント端末８０を操作する社外のエンドユーザ）が要求している業務についての業務ＡＰＩ定義データ（ヤムルファイル）を取得し、取得した業務ＡＰＩ定義データに従って、内部ネットワーク３を介してＡＰＩ実行者の要求に係る業務処理システム６２の業務処理手段６２Ａの呼出処理を実行する（ステップＳ２７）。
【0152】
業務処理システム６２では、業務処理手段６２Ａにより、ゲートウェイサーバ４０の業務ＡＰＩ定義実行手段４５から内部ネットワーク３を介して送信されてくる業務処理の実行の依頼情報（ＡＰＩ実行者による元の業務ＡＰＩリクエストから生じた２次的なＡＰＩリクエスト）を受信し、業務処理システム６２に設けられた業務データベース（不図示）に記憶された各種のデータ（例えば、顧客情報、売買取引に関するデータ等）を用いてＡＰＩ実行者の要求に係る業務処理を実行し、その業務処理の結果として得られた情報（例えば、顧客情報等）を、内部ネットワーク３を介してゲートウェイサーバ４０のＡＰＩ事後処理手段４６に送信する（ステップＳ２８）。
【0153】
ゲートウェイサーバ４０では、ＡＰＩ事後処理手段４６により、業務処理システム６２の業務処理手段６２Ａから内部ネットワーク３を介して送信されてくる業務処理の結果（ＡＰＩ応答）として得られた情報（例えば、顧客情報等）を受信し、受信した情報を、専用線２、ＡＰＩゲートウェイ２３、およびインターネット１を介してクライアント端末８０に送信する（ステップＳ２９）。
【0154】
クライアント端末８０では、処理手段８１により、ＡＰＩ事後処理手段４６から、専用線２、ＡＰＩゲートウェイ２３、およびインターネット１を介して送信されてくるＡＰＩ応答を受信し、その応答内容をサービス利用結果として画面表示し（ステップＳ３０）、社外のエンドユーザは、このサービス利用結果を確認する（ステップＳ３１）。
【0155】
＜トークン検証システム１０による処理の流れ／リフレッシュトークンによるアクセストークンの再発行処理の流れ：図４＞
【0156】
図４において、クライアント端末８０で、処理手段８１により、アクセストークンの有効期限が過ぎていると判断した場合には、アクセストークン再発行リクエスト（ボディに、リフレッシュトークン、クライアントＩＤおよびクライアントシークレットを含む。）を作成し、作成したアクセストークン再発行リクエストを、インターネット１を介してリクエスト連携システム２０に送信する（ステップＳ５０）。
【0157】
リクエスト連携システム２０では、リクエスト受付サービス手段２１により、クライアント端末８０からの社外アクセスのリクエストを受け付け、受け付けたリクエストの種別の判定を行う。ここでは、例えば、リクエストＵＲＬパスが＜/oauth2/token＞であり、かつ、リクエストのボディのグラントタイプがrefresh_tokenであるので、アクセストークン再発行リクエストであると判定される（ステップＳ５１）。
【0158】
続いて、リクエスト受付サービス手段２１は、受け付けた社外アクセスのリクエストがアクセストークン再発行リクエストであると判定したので、パラメータコピー手段２２に対し、コピー処理を行うように依頼（指示）する。パラメータコピー手段２２は、リクエスト受付サービス手段２１から、コピー依頼に係るアクセストークン再発行リクエストを受け取り、受け取ったリクエストのボディに設定されているリフレッシュトークン、クライアントＩＤおよびクライアントシークレットを、リクエストのヘッダにコピーして設定し、コピー処理後のアクセストークン再発行リクエストを、リクエスト受付サービス手段２１に返す（ステップＳ５２）。
【0159】
それから、リクエスト受付サービス手段２１は、コピー処理後のアクセストークン再発行リクエスト（ヘッダにリフレッシュトークン、クライアントＩＤおよびクライアントシークレットが設定されている状態）を、ＡＰＩゲートウェイ２３に送る。そして、ＡＰＩゲートウェイ２３は、受け取ったコピー処理後のアクセストークン再発行リクエストを、リクエストのパラメータのチェックを行うために、リクエストパラメータチェック手段２４に送る。
【0160】
リクエストパラメータチェック手段２４は、ＡＰＩゲートウェイ２３からのパラメータのチェック依頼を受けて、先ず、コピー処理後のアクセストークン再発行リクエストのヘッダに設定されているクライアントＩＤおよびクライアントシークレットの組合せが、クライアントＩＤ・クライアントシークレット記憶手段２５に記憶されているクライアントＩＤおよびクライアントシークレットの組合せと一致するか否かにより、クライアントアプリケーションを認証する処理を実行する（ステップＳ５３）。一致していれば、認証成功であり、一致していなければ、認証失敗である。
【0161】
次に、リクエストパラメータチェック手段２４は、コピー処理後のアクセストークン再発行リクエストのヘッダに設定されたリフレッシュトークンを取得し、取得したリフレッシュトークンをイントロスペクションＡＰＩリクエストのボディに設定し、このイントロスペクションＡＰＩリクエストを、専用線２を介してゲートウェイサーバ４０のトークン検証手段４４に送信するとともに、トークン検証手段４４から専用線２を介して送信されてくるリフレッシュトークンの検証結果を含むイントロスペクションＡＰＩ応答を受信する（ステップＳ５４）。なお、ゲートウェイサーバ４０のトークン検証手段４４による検証処理の内容は、トークン検証手段４４の説明で既に詳述しているので、ここでは詳しい説明を省略する。
【0162】
リクエストパラメータチェック手段２４は、上述したステップＳ５３のクライアントアプリケーションの認証処理の結果、および、ステップＳ５４のトークンの検証処理の結果を、ＡＰＩゲートウェイ２３に返す。
【0163】
ＡＰＩゲートウェイ２３は、リクエストパラメータチェック手段２４から受け取ったクライアントアプリケーションの認証処理の結果が、認証成功という結果であり、かつ、トークンの検証処理の結果が、トークンは正当なものであるという結果であった場合には、アクセストークン再発行リクエストを、専用線２を介してＡＰＩ基盤システム３０のゲートウェイサーバ４０のトークン発行手段４３に送信する。一方、ＡＰＩゲートウェイ２３は、クライアントアプリケーションの認証処理の結果が、認証失敗という結果であった場合、または、トークンの検証結果が、トークンは正当なものでないという結果であった場合には、アクセストークン再発行リクエストをＡＰＩ基盤システム３０に送信せずに、認証エラーが発生した旨を、インターネット１を介してクライアント端末８０に送信する。これにより、正当でないアクセストークン再発行リクエストがインターナルクラウド内に侵入することを防止している。
【0164】
ゲートウェイサーバ４０では、トークン発行手段４３により、ＡＰＩゲートウェイ２３から専用線２を介して送信されてくるアクセストークン再発行リクエスト（リフレッシュトークン、クライアントＩＤおよびクライアントシークレットを含む。）を受信した場合には、アクセストークンおよびリフレッシュトークンを発行し、発行したアクセストークンおよびリフレッシュトークンを暗号鍵記憶手段４８に記憶された暗号鍵を用いて暗号化してから、専用線２、ＡＰＩゲートウェイ２３、およびインターネット１を介してクライアント端末８０に送信する（ステップＳ５５）。
【0165】
この際、トークン発行手段４３は、図６に示すように、発行したアクセストークンおよびリフレッシュトークンの各々についての発行日時、有効期限、失効フラグを、それぞれのトークンのＩＤ（例えば、それぞれのトークンのハッシュ値）またはそれぞれのトークン自体と関連付けてトークン情報記憶手段４７に記憶させる。
【0166】
その後のステップＳ５６～Ｓ６５の処理（業務ＡＰＩリクエストの処理）は、前述した図３のステップＳ２２～Ｓ３１の処理と同様である。
【0167】
＜リクエスト連携システム２０による処理の流れ：図５＞
【0168】
図５には、リクエスト連携システム２０により受信した社外アクセスのリクエストの種別に応じて、リクエスト連携システム２０で実行される処理の流れが示されている。これは、前述した図２～図４に示されたトークン検証システム１０による全体的な処理の流れの中から、リクエスト連携システム２０により実行される主要な処理（前述したステップＳ３，Ｓ４，Ｓ１３，Ｓ１４，Ｓ１８～Ｓ２０，Ｓ２４～Ｓ２６，Ｓ５１～Ｓ５４，Ｓ５８～Ｓ６０の処理）を抜き出して記載したものである。
【0169】
リクエスト連携システム２０では、リクエスト受付サービス手段２１により、受信した社外アクセスのリクエストについて条件判定を行い（前述したステップＳ３，Ｓ１３，Ｓ１８，Ｓ２４，Ｓ５１，Ｓ５８）、条件判定で得られたリクエストの種別に応じて処理を分岐させる。
【0170】
すなわち、受信した社外アクセスのリクエストが、認証・認可リクエストであると判定された場合（図２のステップＳ３）、および認可コード発行リクエストであると判定された場合（図２のステップＳ１３）には、リクエストパラメータチェック手段２４によるクライアントアプリケーションのチェック処理（図２のステップＳ４，Ｓ１４）を実行し、リクエストに確認ＩＤおよび確認コードがない場合には、認証システム誘導手段４１によるユーザ認証システム６１への誘導処理（図２のステップＳ５）に移行し、リクエストに確認ＩＤおよび確認コードがある場合には、認可コード発行手段４２による認可コード発行処理（図２のステップＳ１５）に移行する。
【0171】
また、受信した社外アクセスのリクエストが、アクセストークン発行リクエストであると判定された場合（図３のステップＳ１８）には、パラメータコピー手段２２によるコピー処理（図３のステップＳ１９）、リクエストパラメータチェック手段２４によるクライアントアプリケーションの認証処理（図３のステップＳ２０）を実行し、トークン発行手段４３によるアクセストークンおよびリフレッシュトークンの発行処理（図３のステップＳ２１）に移行する。
【0172】
さらに、受信した社外アクセスのリクエストが、リフレッシュトークンによるアクセストークン再発行リクエストであると判定された場合（図４のステップＳ５１）には、パラメータコピー手段２２によるコピー処理（図４のステップＳ５２）、リクエストパラメータチェック手段２４によるクライアントアプリケーションの認証処理（図４のステップＳ５３）、リクエストパラメータチェック手段２４によるイントロスペクションＡＰＩを利用したトークンの検証処理（図４のステップＳ５４）を実行し、トークン発行手段４３によるアクセストークンおよびリフレッシュトークンの発行処理（図４のステップＳ５５）に移行する。
【0173】
また、受信した社外アクセスのリクエストが、業務ＡＰＩリクエストであると判定された場合（図３のステップＳ２４、図４のステップＳ５８）には、リクエストパラメータチェック手段２４によるクライアントアプリケーションの認証処理（図３のステップＳ２５、図４のステップＳ５９）、リクエストパラメータチェック手段２４によるイントロスペクションＡＰＩを利用したトークンの検証処理（図３のステップＳ２６、図４のステップＳ６０）を実行し、業務ＡＰＩ定義実行手段４５による業務ＡＰＩ定義実行処理（図３のステップＳ２７、図４のステップＳ６１）に移行する。
【0174】
＜本実施形態の効果＞
【0175】
このような本実施形態によれば、次のような効果がある。すなわち、トークン検証システム１０では、社外アクセスのリクエストを受け付けるリクエスト連携システム２０をパブリッククラウド環境に設け、このリクエスト連携システム２０のリクエストパラメータチェック手段２４から、社外アクセスのリクエスト内の検証対象のアクセストークンやリフレッシュトークンを設定したイントロスペクションＡＰＩリクエストを、ＡＰＩ基盤システム３０のトークン検証手段４４に送信し、トークン検証手段４４からのイントロスペクションＡＰＩ応答として、アクセストークンやリフレッシュトークンの正当性の検証結果を受け取るようにしたので、社外アクセスのリクエストである業務ＡＰＩリクエストやアクセストークン再発行リクエストをインターナルクラウド環境内に侵入させることなく、業務ＡＰＩリクエストに設定されたアクセストークンの正当性の検証結果や、アクセストークン再発行リクエストに設定されたリフレッシュトークンの正当性の検証結果を、パブリッククラウド環境下に置かれたリクエスト連携システム２０で取得することができる。
【0176】
従って、パブリッククラウド環境下で取得することができたアクセストークンやリフレッシュトークンの検証結果が、正当なトークンでない旨の情報であった場合には、リクエスト連携システム２０のＡＰＩゲートウェイ２３により、それらの正当でないアクセストークンやリフレッシュトークンが設定されていた業務ＡＰＩリクエストやアクセストークン再発行リクエスト、すなわち、セキュリティ上、問題のある社外アクセスのリクエストを、インターナルクラウド環境下に置かれたＡＰＩ基盤システム３０に送信しないようにすることができる。
【0177】
すなわち、トークン検証システム１０では、ＡＰＩ基盤システム３０のトークン発行手段４３によりアクセストークンおよびリフレッシュトークンを発行するので、トークン発行主体は、インターナルクラウド環境下に置かれたＡＰＩ基盤システム３０である。そして、発行されたトークンの検証は、トークン発行主体でしか行うことができないので、ＡＰＩ基盤システム３０でトークンの検証を行うことになり、ＡＰＩ基盤システム３０にトークン検証手段４４が設けられている。しかし、インターナルクラウド環境下に置かれたＡＰＩ基盤システム３０でアクセストークンやリフレッシュトークンの正当性の検証を行うとなると、セキュリティ上の問題を含んでいる可能性がある社外アクセスのリクエストである業務ＡＰＩリクエストやアクセストークン再発行リクエストを、インターナルクラウド環境内に侵入させることになってしまう。そこで、トークン検証システム１０では、イントロスペクションＡＰＩを利用し、パブリッククラウド環境下に置かれたリクエスト連携システム２０から、インターナルクラウド環境下に置かれたＡＰＩ基盤システム３０のトークン検証手段４４に対し、社外アクセスのリクエスト自体ではなく、そのリクエストに設定された検証対象のトークンを送信することによりトークンの検証結果を取得し、その検証結果が、正当なトークンでない旨の情報であった場合に、そのリクエスト自体をＡＰＩ基盤システム３０に送信（連携）しないようにしている。このため、セキュリティ上の問題を含んでいる社外アクセスのリクエスト自体が、インターナルクラウド環境内に侵入することを防ぐことができるので、セキュリティを十分に確保することができる。
【0178】
また、トークン検証システム１０では、パブリッククラウド環境下に置かれたリクエスト連携システム２０から、イントロスペクションＡＰＩを利用することにより、インターナルクラウド環境下で行われたトークン検証の結果を取得するので、前述した図７に示した従来のシステム９０のような同様の構成のゲートウェイサーバを、社外アクセス用および社内アクセス用として２ヶ所に配置することを回避することができる。このため、システムの構築コストを低減することができる。
【0179】
また、トークン検証システム１０では、ＯＡｕｔｈ２．０に従ったアクセストークンおよびリフレッシュトークンの払い出しを行うトークン発行手段４３は、インターナルクラウド環境下のＡＰＩ基盤システム３０に設けられているので、すなわち、図７に示した従来システム９０で採用していた標準機能を活用することができるので、社外コンシューマ（本実施形態では、社外のエンドユーザが操作するクライアント端末８０、またはそこに搭載されたクライアントアプリケーション）は、本発明のトークン検証システム１０の構築後において、構築前の従来システム９０で発行されたアクセストークンおよびリフレッシュトークンをそのまま利用することができる。
【0180】
さらに、トークン検証システム１０は、リクエスト連携システム２０に設けられたクライアントＩＤ・クライアントシークレット記憶手段２５の情報により、クライアントアプリケーションの認証（そのクライアントアプリケーションから送信されてくるリクエストの認証と考えてもよい。）を行う構成とされているので、パブリッククラウド環境下に置かれたリクエスト連携システム２０で、クライアントアプリケーションの認証を行うことができ、より一層、セキュリティの向上を図ることができる。
【0181】
また、リクエスト連携システム２０にパラメータコピー手段２２が設けられているので、リクエストパラメータチェック手段２４によりアクセストークン再発行リクエストのボディに設定されているリフレッシュトークンを読み込むことができない状況であっても、パラメータコピー手段２２により、アクセストークン再発行リクエストのボディに設定されているリフレッシュトークンをヘッダにコピーして設定することができる。このため、リクエストパラメータチェック手段２４によりリフレッシュトークンを読み込むことができるようになるので、イントロスペクションＡＰＩリクエストへのリフレッシュトークンの設定を行うことができる。
【0182】
また、トークン検証システム１０は、トークン検証手段４４により、トークン情報記憶手段４７に記憶された有効期限および失効フラグを用いて、アクセストークンまたはリフレッシュトークンの正当性を検証する構成とされているので（図６参照）、トークン発行手段４３によるアクセストークンおよびリフレッシュトークンの発行時の情報を用いて、インターナルクラウド環境下でそれぞれのトークンの正当性を確実に検証することができる。
【0183】
＜変形の形態＞
【0184】
なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。
【0185】
例えば、前記実施形態では、インターネット経由の社外アクセスのリクエストの送信元は、社外のエンドユーザが操作するクライアント端末８０に搭載されたクライアントアプリケーションとなっていたが、これに限定されるものではなく、本発明におけるインターネット経由の社外アクセスのリクエストの送信元は、社外の他のシステム（本発明のトークン検証システム以外のシステム）のサーバに搭載されたクライアントアプリケーションであってもよい。
【産業上の利用可能性】
【0186】
以上のように、本発明のトークン検証システムおよびプログラムは、例えば、社外のエンドユーザが、ＡＰＩを利用してインターナルクラウド環境下に置かれた業務処理システムにアクセスし、業務処理を実行する場合等に用いるのに適している。
【符号の説明】
【0187】
１ インターネット
２ 専用線
３ 内部ネットワーク
１０ トークン検証システム
２０ リクエスト連携システム
２１ リクエスト受付サービス手段
２２ パラメータコピー手段
２３ ＡＰＩゲートウェイ
２４ リクエストパラメータチェック手段
２５ クライアントＩＤ・クライアントシークレット記憶手段
３０ ＡＰＩ基盤システム
４３ トークン発行手段
４４ トークン検証手段
４７ トークン情報記憶手段
２ 専用線
３ 内部ネットワーク
１０ トークン検証システム
２０ リクエスト連携システム
２１ リクエスト受付サービス手段
２２ パラメータコピー手段
２３ ＡＰＩゲートウェイ
２４ リクエストパラメータチェック手段
２５ クライアントＩＤ・クライアントシークレット記憶手段
３０ ＡＰＩ基盤システム
４３ トークン発行手段
４４ トークン検証手段
４７ トークン情報記憶手段
【要約】
【課題】セキュリティを十分に確保することができ、かつ、安価に構築することができるトークン検証システムを提供する。
【解決手段】トークン検証システム１０では、社外アクセスのリクエストを受け付けるリクエスト連携システム２０をパブリッククラウド環境に設け、このリクエスト連携システム２０のリクエストパラメータチェック手段２４から、社外アクセスのリクエスト内の検証対象のアクセストークンやリフレッシュトークンを設定したイントロスペクションＡＰＩリクエストを、ＡＰＩ基盤システム３０のトークン検証手段４４に送信し、トークン検証手段４４からのイントロスペクションＡＰＩ応答として、アクセストークンやリフレッシュトークンの正当性の検証結果を受け取る。
【選択図】図１
【解決手段】トークン検証システム１０では、社外アクセスのリクエストを受け付けるリクエスト連携システム２０をパブリッククラウド環境に設け、このリクエスト連携システム２０のリクエストパラメータチェック手段２４から、社外アクセスのリクエスト内の検証対象のアクセストークンやリフレッシュトークンを設定したイントロスペクションＡＰＩリクエストを、ＡＰＩ基盤システム３０のトークン検証手段４４に送信し、トークン検証手段４４からのイントロスペクションＡＰＩ応答として、アクセストークンやリフレッシュトークンの正当性の検証結果を受け取る。
【選択図】図１
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】