(57)【要約】【課題】WebAPIの利用許諾を容易かつ適切に行う。【解決手段】WebAPI利用許諾システム１は、開発者端末３からの要求に基づいて一時キーを払い出す一時キー払出部２３と、開発者端末３から通知された一時キーの保管先にHTTPS（Hypertext Transfer Protocol Secure）でアクセスするサーバ証明書検証部２５と、サーバ証明書検証部２５により一時キーの存在が確認できた場合に、開発者端末３に認証キーを払い出す認証キー払出部２６とを備える。【選択図】図１
2017004325.tif 000002
【特許請求の範囲】
【請求項１】
端末からの要求に基づいて一時キーを払い出す一時キー払出部と、
前記端末から通知された前記一時キーの保管先にHTTPS（Hypertext Transfer Protocol Secure）でアクセスするサーバ証明書検証部と、
前記サーバ証明書検証部により前記一時キーの存在が確認できた場合に、前記端末に認証キーを払い出す認証キー払出部と、
を備えることを特徴とするWebAPI利用許諾システム。
【請求項２】
前記サーバ証明書検証部が前記一時キーの保管先の証明書が正当でないと判断した場合、前記認証キー払出部による認証キーの払い出しを行わない、
ことを特徴とする請求項１に記載のWebAPI利用許諾システム。
【請求項３】
前記サーバ証明書検証部が前記一時キーの保管先との通信プロトコルが所望のものでないと判断した場合、前記認証キー払出部による認証キーの払い出しを行わない、
ことを特徴とする請求項２に記載のWebAPI利用許諾システム。
【請求項４】
前記サーバ証明書検証部が前記一時キーの保管先との通信の暗号方式が所望のものでないと判断した場合、前記認証キー払出部による認証キーの払い出しを行わない、
ことを特徴とする請求項２に記載のWebAPI利用許諾システム。
【請求項５】
前記サーバ証明書検証部が前記一時キーの保管先の証明書に登記情報が含まれていないと判断した場合、前記認証キー払出部による認証キーの払い出しを行わない、
ことを特徴とする請求項２に記載のWebAPI利用許諾システム。
【請求項６】
端末からの要求に基づいて認証キーを払い出す認証キー払出部と、
前記端末から通知された前記認証キーの保管先にHTTPSでアクセスするサーバ証明書検証部と、
前記サーバ証明書検証部により前記認証キーの存在が確認できた場合に、前記認証キーを有効化する認証キー有効化部と、
を備えることを特徴とするWebAPI利用許諾システム。
【請求項７】
サーバが、
端末からの要求に基づいて一時キーを払い出すステップと、
前記端末から通知された前記一時キーの保管先にHTTPSでアクセスするステップと、
前記一時キーの存在が確認できた場合に、前記端末に認証キーを払い出すステップと、
を実行することを特徴とするWebAPI利用許諾方法。
【請求項８】
コンピュータに、
端末からの要求に基づいて一時キーを払い出す手順、
前記端末から通知された前記一時キーの保管先にHTTPSでアクセスする手順、
前記一時キーの存在が確認できた場合に、前記端末に認証キーを払い出す手順、
を実行させるためのWebAPI利用許諾プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、提供者が公開したWebAPI（Web Application Program Interface）を他の開発者に利用していただく際に、他の開発者の利用申請を効率的に審査してWebAPIの利用を許諾するWebAPI利用許諾システム、WebAPI利用許諾方法、およびWebAPI利用許諾プログラムに関する。
【背景技術】
【０００２】
近年のネットワークの高速化とウェブブラウザの普及により、インターネットを経由して所定の処理を提供するWebAPIが広く普及している。このWebAPIは、インターネット経由で或るサーバ上にあるプログラムや管理データなどを、他のサーバや端末などから呼び出して利用するための手順やデータ形式などを定めた規約であり、コンピュータプログラムの機能を呼び出して利用するための規約であるAPI（Application Program Interface）に擬えて命名されている。
【０００３】
開発者は、WebAPIを活用することによって、容易にエンドユーザ向けアプリケーションを開発することができる。またWebAPIの提供者は、このWebAPIを活用したアプリケーションにより、自社のサービスやコンテンツを容易に訴求することができる。
【０００４】
このWebAPIは、プログラムから利用されることを前提として作られているため、極めて短い周期に大量のアクセスを実行されるなど、不正に利用されるおそれがある。そこで、WebAPIは、利用の際には認証キーを必須とすることが多い。この認証キーにより、WebAPIを呼び出している開発者を容易に特定し、不正利用を発見することが可能となる。
【０００５】
提供者が、開発者である他社にWebAPIを公開する場合、非特許文献１に記載のように開発者向けのWebAPIポータルサイトにて利用規約などを提示し、不正な使用を法的に抑止すると共に、本人確認などを行って認証キーを払い出すことが多い。ここでWebAPIの提供者は、作業者が介在することなく機械的にWebAPIの利用を許諾し、認証キーを払い出す場合がある。しかし、使い捨てのメールアドレスでユーザ登録されるなど、悪意者による不正利用を完全に防ぐことはできないという問題がある。
【０００６】
そこで、個人情報や金銭などを扱うWebAPIの場合には、開発者に公的証明書などを提出させて手作業で本人確認を行う場合がある。非特許文献１に記載のポータルサイトには、「あらかじめパートナー審査が必要なAPIもございます。」と記載されている。この認証キーの払い出しの概念について、図１０に示す。
【０００７】
図１０は、手作業によるWebAPI認証を示すシーケンス図である。
Ａ社開発者６は、WebAPIの使用にあたり、WebAPI提供者７にWebAPIの利用申請を行う（シーケンスＱ１００）。WebAPI提供者７は、この利用申請を審査し（シーケンスＱ１０１）、この審査に合格したならば認証キーを払い出す（シーケンスＱ１０２）。これによりＡ社開発者６は、WebAPIを使用することができる。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】「ドコモAPIを使ったアプリを開発しよう」、［online］、２０１５年、NTT DOCOMO, INC.、［平成２７年６月４日検索］、インターネット<URL:https://dev.smt.docomo.ne.jp/?p=about.api>
【発明の概要】
【発明が解決しようとする課題】
【０００９】
課金など重要な通信を行うWebAPIについては、開発者に対してHTTPS（Hypertext Transfer Protocol Secure）などのセキュリティ対策がされている環境での利用を求めたい。しかし利用許諾を行う際に、利用者側のWebAPIの運用環境をチェックすることは困難である。
また、申込者の本人性確認のため、公的証明書などの提示を求めることは非効率的である。
【００１０】
そこで、本発明は、WebAPI利用許諾システム、WebAPI利用許諾方法、およびWebAPI利用許諾プログラムにて、WebAPIの利用許諾を容易かつ適切に行うことを課題とする。
【課題を解決するための手段】
【００１１】
前記課題を解決するため、請求項１に記載の発明では、端末からの要求に基づいて一時キーを払い出す一時キー払出部と、前記端末から通知された前記一時キーの保管先にHTTPS（Hypertext Transfer Protocol Secure）でアクセスするサーバ証明書検証部と、前記サーバ証明書検証部により前記一時キーの存在が確認できた場合に、前記端末に認証キーを払い出す認証キー払出部と、を備えることを特徴とするWebAPI利用許諾システムとした。
【００１２】
このようにすることで、HTTPSのサーバ証明書における認証局の審査結果を援用して、この開発者を検証し、検証できた開発者端末に対して認証キーを払い出すことができる。
【００１３】
請求項２に記載の発明では、前記サーバ証明書検証部が前記一時キーの保管先の証明書が正当でないと判断した場合、前記認証キー払出部による認証キーの払い出しを行わない、ことを特徴とする請求項１に記載のWebAPI利用許諾システムとした。
【００１４】
このようにすることで、この開発者がHTTPSサーバにアクセス可能であることを検証し、検証できた開発者端末に限って認証キーを払い出すことができる。
【００１５】
請求項３に記載の発明では、前記サーバ証明書検証部が前記一時キーの保管先との通信プロトコルが所望のものでないと判断した場合、前記認証キー払出部による認証キーの払い出しを行わない、ことを特徴とする請求項２に記載のWebAPI利用許諾システムとした。
【００１６】
このようにすることで、この開発者のWebサーバの通信プロトコルが所望の暗号強度を有するか否かを検証し、検証できた開発者端末に限って認証キーを払い出すことができる。
【００１７】
請求項４に記載の発明では、前記サーバ証明書検証部が前記一時キーの保管先との通信の暗号方式が所望のものでないと判断した場合、前記認証キー払出部による認証キーの払い出しを行わない、ことを特徴とする請求項２に記載のWebAPI利用許諾システムとした。
【００１８】
このようにすることで、この開発者のWebサーバの暗号方式が所望の暗号強度を有するか否かを検証し、検証できた開発者端末に限って認証キーを払い出すことができる。
【００１９】
請求項５に記載の発明では、前記サーバ証明書検証部が前記一時キーの保管先の証明書に登記情報が含まれていないと判断した場合、前記認証キー払出部による認証キーの払い出しを行わない、ことを特徴とする請求項２に記載のWebAPI利用許諾システムとした。
【００２０】
このようにすることで、この開発者が現実の登記情報を有するか否かを検証し、検証できた開発者端末に限って認証キーを払い出すことができる。
【００２１】
請求項６に記載の発明では、端末からの要求に基づいて認証キーを払い出す認証キー払出部と、前記端末から通知された前記認証キーの保管先にHTTPSでアクセスするサーバ証明書検証部と、前記サーバ証明書検証部により前記認証キーの存在が確認できた場合に、前記認証キーを有効化する認証キー有効化部と、を備えることを特徴とするWebAPI利用許諾システムとした。
【００２２】
このようにすることで、無効化した認証キーを払い出したのちに有効化することができる。
【００２３】
請求項７に記載の発明では、サーバが、端末からの要求に基づいて一時キーを払い出すステップと、前記端末から通知された前記一時キーの保管先にHTTPSでアクセスするステップと、前記一時キーの存在が確認できた場合に、前記端末に認証キーを払い出すステップと、を実行することを特徴とするWebAPI利用許諾方法とした。
【００２４】
請求項８に記載の発明では、コンピュータに、端末からの要求に基づいて一時キーを払い出す手順、前記端末から通知された前記一時キーの保管先にHTTPSでアクセスする手順、前記一時キーの存在が確認できた場合に、前記端末に認証キーを払い出す手順、を実行させるためのWebAPI利用許諾プログラムとした。
【００２５】
このようにすることで、HTTPSのサーバ証明書における認証局の審査結果を援用して、この開発者を検証し、検証できた開発者端末に対して認証キーを払い出すことができる。
【発明の効果】
【００２６】
本発明によれば、WebAPIの利用許諾を容易かつ適切に行うことかできる。
【図面の簡単な説明】
【００２７】
【図１】第１の実施形態における利用許諾システムの構成図である。
【図２】開発者情報格納部の構成を示す図である。
【図３】第１の実施形態の認証処理を示すシーケンス図である。
【図４】X.509公開鍵証明書の構成を示す図である。
【図５】第１の実施形態の認証処理を示すフローチャートである。
【図６】第２の実施形態における利用許諾システムの構成図である。
【図７】開発者情報格納部の構成を示す図である。
【図８】第２の実施形態の認証処理を示すシーケンス図である。
【図９】第２の実施形態の認証を示すフローチャートである。
【図１０】手作業によるWebAPIの認証を示すシーケンス図である。
【発明を実施するための形態】
【００２８】
次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
（第１の実施形態）
第１の実施形態のWebAPI利用許諾システム１は、開発者の審査に暗号化通信の証明書を用いることで、効率的に開発者の信頼性を確認するものである。
【００２９】
図１は、第１の実施形態におけるWebAPI利用許諾システム１の構成図である。
WebAPI利用許諾システム１は、API提供者サーバ２と、認証局５とを含んで構成される。このAPI提供者サーバ２は、開発者情報受付部２１と、キー情報生成部２２と、一時キー払出部２３と、格納情報受付部２４と、サーバ証明書検証部２５と、認証キー払出部２６と、開発者情報格納部２７とを含んで構成される。
認証局５は、Ａ社などに対してX.509公開鍵証明書（デジタル公開鍵証明書）を発行する機関である。ここではHTTPSサーバ４に対してX.509公開鍵証明書が発行される。
【００３０】
開発者情報受付部２１は、開発者端末３から開発者が入力したメールアドレス等の情報を受け付ける。キー情報生成部２２は、この開発者に対して一時キーと認証キーを生成し、開発者情報と共に開発者情報格納部２７に格納する。一時キー払出部２３は、開発者端末３に対して一時キーを払い出す。この一時キーは、単に各開発者を識別する一時的なキーであり、WebAPIの認証キーとして使用することはできない。開発者は、この一時キーを自社のHTTPSサーバ４に格納する。
【００３１】
格納情報受付部２４は、開発者端末３から一時キーの格納情報を受け付ける。サーバ証明書検証部２５は、この一時キーの格納先のサーバ証明書が正規であることを検証すると共に、開発者情報格納部２７を参照して、この一時キーがこの開発者に払い出したものと同一か否かを検証する。認証キー払出部２６は、サーバ証明書が正しく検証され、かつ一時キーがこの開発者に払い出したものと同一であったならば、開発者が正当であることが検証できたものとして、正規の認証キーを開発者端末３に払い出す。なお開発者情報格納部２７は、後記する図２にて説明する。
【００３２】
図２は、開発者情報格納部２７の構成を示す図である。
開発者情報格納部２７は、開発者メールアドレス欄２７ａ、開発者サーバアドレス欄２７ｂ、一時キー欄２７ｃ、認証キー欄２７ｄの各欄を含んで構成されたデータベースであり、開発者ごとにレコードが生成される。
開発者メールアドレス欄２７ａは、WebAPIの利用を申請した開発者のメールアドレスを格納する欄である。開発者サーバアドレス欄２７ｂは、開発者が一時キーを格納したサーバのURL（Uniform Resource Locator）を格納する欄である。
一時キー欄２７ｃは、開発者に払い出す一時キーを格納する欄である。認証キー欄２７ｄは、開発者に払い出す認証キーを格納する欄である。
この開発者情報格納部２７により、開発者と、この開発者に払い出した認証キーとの関係を知ることができる。よって不正にWebAPIが使用されたときに、この不正な使用に係る開発者を特定し、この開発者によるWebAPIの使用を差し止めることができる。
【００３３】
図３は、第１の実施形態の認証処理を示すシーケンス図であり、適宜図１と図２とを参照して説明する。
Ａ社は、認証局５に対して予めX.509公開鍵証明書を申請し（シーケンスＱ１０）、認証局５は、Ａ社に対してX.509公開鍵証明書を発行する（シーケンスＱ１１）。これによりＡ社HTTPSサーバ４は、HTTPSでのアクセスを受け付けることが可能となる。このX.509公開鍵証明書は、Ａ社が認証局５から認証されたことを証明するものであり、HTTPSの通信路の暗号化に用いるものである。なお、図面ではX.509公開鍵証明書を、単に「証明書」と記載し、かつ、後記する図４で詳細に説明する。
【００３４】
Ａ社の開発者は、開発者端末３によりAPI提供者サーバ２に利用申請を行う（シーケンスＱ２０）。API提供者サーバ２は、開発者情報受付部２１（図１参照）により利用申請を受け付け、キー情報生成部２２（図１参照）により一時キーと認証キーとを生成し、開発者情報格納部２７（図２参照）に格納する。
API提供者サーバ２は、一時キー払出部２３（図１参照）により、この開発者端末３に一時キーを払い出す（シーケンスＱ２１）。この一時キーは、認証キーとして使用できない。Ａ社の開発者は、この一時キーをＡ社のHTTPSサーバ４に格納し（シーケンスＱ３０）、その後API提供者サーバ２に対して一時キーの格納通知を行う（シーケンスＱ４０）。この格納通知には、一時キーの格納先であるHTTPSサーバ４のURLが含まれる。API提供者サーバ２は、格納情報受付部２４（図１参照）により、この一時キーの格納先を受け付ける。
【００３５】
API提供者サーバ２は、サーバ証明書検証部２５（図１参照）により、このHTTPSサーバ４に対してHTTPSでアクセスし（シーケンスＱ４１）、HTTPSサーバ４からX.509公開鍵証明書を取得する（シーケンスＱ４２）。
【００３６】
API提供者サーバ２は、認証用の公開鍵によりX.509公開鍵証明書を検証する（シーケンスＱ４３）。API提供者サーバ２は、事前に認証用の公開鍵を認証局５から入手しているため、この時点での通信は発生しない。API提供者サーバ２は、X.509公開鍵証明書により、Ａ社が信頼できる組織であることを検証できる。
【００３７】
API提供者サーバ２は、X.509公開鍵証明書が検証できたならば、乱数を発生させて証明書の鍵で暗号化し（シーケンスＱ４４）、暗号化した乱数をHTTPSサーバ４に送信する（シーケンスＱ４５）。このHTTPSサーバ４は、受信した暗号化乱数を証明書の鍵で復号し（シーケンスＱ４６）、復号した乱数に基づき共通鍵を作成する（シーケンスＱ４７）。API提供者サーバ２は、自身が発生した乱数に基づき共通鍵を作成する（シーケンスＱ４８）。
次いでHTTPSサーバ４は、API提供者サーバ２に一時キーを送信する（シーケンスＱ４９）。API提供者サーバ２は、受信した一時キーと開発者情報格納部２７（図１参照）に格納された一時キーとを照合して確認し（シーケンスＱ５０）、一時キーが一致したならば、認証キー払出部２６（図１参照）により開発者端末３に対して認証キーを払い出す（シーケンスＱ５１）。この一時キーの一致により、Ａ社の開発者がＡ社のHTTPSサーバ４を操作する権限を持っていることを確認でき、よってＡ社の正規の開発者であることが確認できる。
【００３８】
図４は、X.509公開鍵証明書８の構成を示す図であり、適宜図１を参照して説明する。
X.509公開鍵証明書８は、バージョン８０、シリアル番号８１、署名アルゴリズム８２、発行者８３、有効期間８４、サブジェクト８５、公開鍵アルゴリズム８６、公開鍵８７、署名アルゴリズム８８、署名値８９の各パラメータを含んで構成される。ここでX.509とは、電子鍵証明書および証明書失効リスト（CRL）の標準仕様のことをいい、図４では、X.509v3デジタル証明書の構造を示している。
バージョン８０は、このX.509公開鍵証明書８のバージョンを示すパラメータであり、例えば“V1”である。シリアル番号８１は、認証局５（図１参照）が一意に発行した番号であり、例えば２０オクテットまでの数値である。
署名アルゴリズム８２は、認証局５がX.509証明書に署名するときに利用したアルゴリズムであり、例えば“SHA1 RSA”である。発行者８３は、認証局５の名称である。
【００３９】
有効期間８４は、このX.509公開鍵証明書が有効である開始日時と終了日時の組み合わせである。サブジェクト８５は、このX.509公開鍵証明書による証明を受ける人（主体者）の名前である。
公開鍵アルゴリズム８６は、この主体者の公開鍵アルゴリズムであり、例えば“RSA”である。公開鍵８７は、この主体者の公開鍵である。
署名アルゴリズム８８は、署名アルゴリズム８２と同じものが記述される。署名アルゴリズム８８には、署名作成のためのハッシュ関数と公開鍵暗号方式の二つのアルゴリズムが明記される。署名値８９は、認証局５がこの証明書に署名した値である。ここでは、バージョン８０から公開鍵８７までを、署名アルゴリズム８８に記載のアルゴリズムでハッシュ値を算出する。そして，そのハッシュ値に対して，同じく署名アルゴリズム８８に記載の公開鍵暗号方式を使って主体者の個人鍵で暗号化したものが、署名値８９となる。
【００４０】
図５は、第１の実施形態の認証処理を示すフローチャートであり、適宜図１から図４を参照して説明する。
この認証処理では、図３のシーケンスＱ４０〜Ｑ５１までのうち、API提供者サーバ２（図１参照）が主体となる処理を説明している。
最初、API提供者サーバ２は、格納情報受付部２４（図１参照）により一時キーの格納通知を開発者端末３（図１参照）から受信し（ステップＳ１０）、サーバ証明書検証部２５（図１参照）により格納先であるHTTPSサーバ４（図１参照）にHTTPSでアクセスする（ステップＳ１１）。
【００４１】
API提供者サーバ２は、HTTPSサーバ４からX.509公開鍵証明書８を受信すると（ステップＳ１２）、サーバ証明書検証部２５により、このX.509公開鍵証明書８（図４参照）が正規の証明書か否かを判断し（ステップＳ１３）、正規の証明書でなかったならば（ステップＳ１３→Ｎｏ）異常終了する。これによりWebAPIの提供者は、開発者が所属する組織が認証局５（図１参照）から認証されていることを確認できる。
【００４２】
次いでAPI提供者サーバ２は、サーバ証明書検証部２５により、HTTPSサーバ４との通信が所望の暗号とプロトコルとをサポートするか否かを判断し（ステップＳ１４）、所望の暗号とプロトコルとをサポートしないならば（ステップＳ１４→Ｎｏ）、異常終了する。これによりWebAPIの提供者は、HTTPSサーバ４が所望の暗号強度を有していることを容易に確認できる。このHTTPSサーバ４は、開発者がWebサーバとして用いるものと推定されるため、WebAPIを使用したアプリケーションが所望の暗号強度のHTTPSで運用されることを推定できる。
【００４３】
更にAPI提供者サーバ２は、サーバ証明書検証部２５により、X.509公開鍵証明書８に登記情報が有るか否かを判断し（ステップＳ１５）、登記情報が無いならば（ステップＳ１５→Ｎｏ）、異常終了する。これによりWebAPIの提供者は、このX.509公開鍵証明書８が発行された開発者が実在の登記情報を有することを容易に確認できる。
API提供者サーバ２は、乱数を生成して、X.509公開鍵証明書８の公開鍵８７で暗号化し（ステップＳ１６）、暗号化した乱数をHTTPSサーバ４に送信し（ステップＳ１７）、乱数から共通鍵を作成する（ステップＳ１８）。これにより、HTTPSにより通信路が暗号化される。
次いでAPI提供者サーバ２は、共通鍵暗号方式で暗号化されたHTTPSの通信路を介して一時キーを受信し（ステップＳ１９）、受信した一時キーと開発者情報格納部２７の一時キー欄２７ｃ（図２参照）に格納された一時キーとを照合して確認し（ステップＳ２０）、一時キーが確認できなかったならば（ステップＳ２０→Ｎｏ）、異常終了する。
API提供者サーバ２は、一時キーが確認できたならば（ステップＳ２０→Ｙｅｓ）、開発者がHTTPSサーバ４を操作する権限を持っていることを確認できるので、認証キー払出部２６（図１参照）により開発者端末３に対して認証キーを払い出す（ステップＳ２１）。
【００４４】
第１の実施形態によれば、WebAPIの利用許諾において、WebAPIがセキュリティの低い環境で利用されることを防ぐことができる。更にWebAPIの利用許諾における本人性の確認作業を効率化することが可能となる。
【００４５】
（第２の実施形態）
第１の実施形態のWebAPI利用許諾システム１は、開発者に一時キーを払い出し、開発者を検証した後に正規の認証キーを払い出している。これに対して第２の実施形態のWebAPI利用許諾システム１Ａは、無効な認証キーを払い出し、開発者を検証した後にこの認証キーを有効化するものである。
【００４６】
図６は、第２の実施形態におけるWebAPI利用許諾システム１Ａの構成図である。図１に示す第１の実施形態のWebAPI利用許諾システム１と同一の要素には同一の符号を付与している。
WebAPI利用許諾システム１Ａは、第１の実施形態とは異なるAPI提供者サーバ２Ａを備え、このAPI提供者サーバ２Ａは、第１の実施形態とは異なる開発者情報格納部２７Ａを備え、一時キー払出部２３に代えて無効キー払出部２８を備え、認証キー払出部２６に代えて認証キー有効化部２９を備えている。これら以外は、図１に示す第１の実施形態と同様に構成されている。
【００４７】
無効キー払出部２８は、開発者端末３に対して無効な認証キーを払い出す。この無効な認証キーは、WebAPIの有効な認証キーとしては使用することはできない。開発者は、この無効な認証キーを自社のHTTPSサーバ４に格納する。
認証キー有効化部２９は、開発者が正当であることが検証できたものとして、無効な認証キーを有効化するものである。開発者情報格納部２７Ａについては、図７にて詳細に説明する。
【００４８】
図７は、開発者情報格納部２７Ａの構成を示す図である。
開発者情報格納部２７Ａは、開発者メールアドレス欄２７ａ、開発者サーバアドレス欄２７ｂ、認証キー欄２７ｄ、有効化欄２７ｅの各欄を含んで構成されたデータベースであり、開発者ごとにレコードが生成される。
開発者メールアドレス欄２７ａと開発者サーバアドレス欄２７ｂは、第１の実施形態と同様である。
認証キー欄２７ｄは開発者に払い出す無効化した認証キーを格納する欄であり、有効化欄２７ｅは、この認証キー欄２７ｄが有効化されているか否かを示す情報を格納する欄である。例えば有効化欄２７ｅに“０”が格納されているとき、認証キー欄２７ｄの認証キーが有効化されておらず、 “１”が格納されているときには認証キーが有効化されている。
この開発者情報格納部２７Ａにより、開発者と、この開発者に払い出した認証キーとの関係を知ることができる。よって不正にWebAPIが使用されたときに、この不正な使用に係る開発者を特定し、この開発者によるWebAPIの使用を差し止めることができる。
【００４９】
図８は、第２の実施形態の認証処理を示すシーケンス図であり、適宜図６や図７を参照して説明する。
シーケンスＱ１０，Ｑ１１は、図３の認証処理と同様であり、Ａ社のHTTPSサーバ４は、HTTPSでのアクセスを受け付けることが可能となる。
【００５０】
Ａ社の開発者は、開発者端末３によりAPI提供者サーバ２Ａに利用申請を行い（シーケンスＱ６０）、API提供者サーバ２Ａは、開発者情報受付部２１（図６参照）により利用申請を受け付け、キー情報生成部２２（図６参照）により認証キーを生成し、開発者情報格納部２７Ａに格納する。
API提供者サーバ２Ａは、無効キー払出部２８（図６参照）により、この開発者端末３に認証キーを払い出す（シーケンスＱ６１）。この認証キーは、払い出し当初は無効化されており使用できない。Ａ社の開発者は、無効化された認証キーをＡ社のHTTPSサーバ４に格納し（シーケンスＱ７０）、その後API提供者サーバ２Ａに対して認証キーの格納通知を行う（シーケンスＱ８０）。この格納通知には、認証キーの格納先であるHTTPSサーバ４のURLが含まれる。
【００５１】
API提供者サーバ２Ａは、サーバ証明書検証部２５（図６参照）により、このHTTPSサーバ４に対してHTTPSでアクセスして（シーケンスＱ８１）、HTTPSサーバ４からX.509公開鍵証明書を取得する（シーケンスＱ８２）。API提供者サーバ２Ａは、認証用の公開鍵によりX.509公開鍵証明書を検証する（シーケンスＱ８３）。API提供者サーバ２Ａは、事前に認証用の公開鍵を認証局５から入手しているため、この時点での通信は発生しない。API提供者サーバ２Ａは、このX.509公開鍵証明書により、Ａ社が信頼できる組織であることを検証できる。
【００５２】
API提供者サーバ２Ａは、X.509公開鍵証明書が検証できたならば、乱数を発生させて証明書の鍵で暗号化し（シーケンスＱ８４）、暗号化した乱数をHTTPSサーバ４に送信する（シーケンスＱ８５）。このHTTPSサーバ４は、受信した暗号化乱数を証明書の鍵で復号し（シーケンスＱ８６）、復号した乱数に基づき共通鍵を作成する（シーケンスＱ８７）。API提供者サーバ２Ａは、自身が発生した乱数に基づき共通鍵を作成する（シーケンスＱ８８）。
次いでHTTPSサーバ４は、API提供者サーバ２Ａに無効化された認証キーを送信する（シーケンスＱ８９）。API提供者サーバ２Ａは、受信した認証キーと開発者情報格納部２７Ａの認証キー欄２７ｄ（図７参照）に格納された認証キーとを照合して確認し（シーケンスＱ９０）、認証キーが一致したならば、この認証キーを有効化する（シーケンスＱ９１）。この認証キーの一致により、Ａ社の開発者がＡ社のHTTPSサーバ４を操作する権限を持っていることを確認でき、よってＡ社の正規の開発者であることが確認できる。
【００５３】
図９は、第２の実施形態の認証を示すフローチャートであり、適宜図４または図６から図８を参照して説明する。
この認証処理では、図８のシーケンスＱ８０〜Ｑ９１までのうち、API提供者サーバ２Ａ（図６参照）が主体となる処理を説明している。
最初、API提供者サーバ２Ａは、格納情報受付部２４（図６参照）により認証キーの格納通知を開発者端末３（図６参照）から受信し（ステップＳ３０）、サーバ証明書検証部２５（図６参照）により格納先であるHTTPSサーバ４（図６参照）にHTTPSでアクセスする（ステップＳ３１）。
【００５４】
API提供者サーバ２Ａは、HTTPSサーバ４からX.509公開鍵証明書８を受信すると（ステップＳ３２）、サーバ証明書検証部２５により、このX.509公開鍵証明書８（図４参照）が正規の証明書か否かを判断し（ステップＳ３３）、正規の証明書でなかったならば（ステップＳ３３→Ｎｏ）異常終了する。これによりWebAPIの提供者は、開発者が所属する組織が認証局５（図６参照）から認証されていることを確認できる。
【００５５】
次いでAPI提供者サーバ２Ａは、サーバ証明書検証部２５により、HTTPSサーバ４との通信が所望の暗号とプロトコルとをサポートするか否かを判断し（ステップＳ３４）、所望の暗号とプロトコルとをサポートしないならば（ステップＳ３４→Ｎｏ）、異常終了する。これによりWebAPIの提供者は、HTTPSサーバ４が所望の暗号強度を有していることを容易に確認できる。このHTTPSサーバ４は、開発者がWebサーバとして用いるものと推定されるため、WebAPIを使用したアプリケーションが所望の暗号強度のHTTPSで運用されることを推定できる。
【００５６】
更にAPI提供者サーバ２Ａは、サーバ証明書検証部２５により、X.509公開鍵証明書８に登記情報が有るか否かを判断し（ステップＳ３５）、登記情報が無いならば（ステップＳ３５→Ｎｏ）、異常終了する。これによりWebAPIの提供者は、このX.509公開鍵証明書８が発行された開発者は、実在する登記情報を有することを容易に確認できる。
API提供者サーバ２Ａは、乱数を生成して、X.509公開鍵証明書８の公開鍵８７（図４参照）で暗号化し（ステップＳ３６）、暗号化した乱数をHTTPSサーバ４に送信し（ステップＳ３７）、乱数から共通鍵を作成する（ステップＳ３８）。これにより、HTTPSにより通信路が暗号化される。
API提供者サーバ２Ａは、共通鍵暗号方式で暗号化されたHTTPSの通信路を介して認証キーを受信し（ステップＳ３９）、受信した認証キーと開発者情報格納部２７Ａの認証キー欄２７ｄ（図７参照）に格納された認証キーとを照合して確認し（ステップＳ４０）、認証キーが確認できなかったならば（ステップＳ４０→Ｎｏ）、異常終了する。
API提供者サーバ２Ａは、認証キーが確認できたならば（ステップＳ４０→Ｙｅｓ）、開発者がHTTPSサーバ４を操作する権限を持っていることを確認できるので、認証キー有効化部２９（図６参照）により、この認証キーを有効化する（ステップＳ４１）。
【００５７】
第２の実施形態によれば、WebAPIの利用許諾において、WebAPIがセキュリティの低い環境で利用されることを防ぐことができる。更にWebAPIの利用許諾における本人性の確認作業を効率化することが可能となる。
【００５８】
（変形例）
上記した実施の形態に係るWebAPI利用許諾システムは、前記したような処理を実行させるプログラムによって実現することができ、そのプログラムをコンピュータによる読み取り可能な記録媒体（ＣＤ−ＲＯＭ等）に記憶して提供することが可能である。また、そのプログラムを、インターネット等のネットワークを通して提供することも可能である。
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）〜（ｄ）のようなものがある。
（ａ）  WebAPIの提供方法は、一時キーや無効化した認証キーの払い出しに限られない。例えば所定の有効期間を有する認証キーを払い出したのち、開発者のHTTPSサーバの証明書が検証でき、かつ、この認証キーが確認できたならば、この認証キーの有効期間を延長してもよい。
（ｂ）  API提供者サーバへの格納通知は、開発者端末からの送信に限られず、任意の装置からの送信であってもよい。
（ｃ）  API提供者サーバは更に、開発者端末のメールアドレスのドメイン名と、HTTPSサーバのURLのドメイン名との一致を確認し、これらが一致しない場合には開発者に対して認証キーの払い出しを行わないように構成してもよい。これにより、成り済ましによる不正な利用申請に対して認証キーを払い出さないようにすることができる。
（ｄ）  WebAPIの提供者は、開発者が一時キーを格納したHTTPSサーバのURLのドメイン名を記憶し、この開発者によるWebAPIのアクセスは、このHTTPSサーバのURLに限定してもよい。これにより、WebAPIの利用を、セキュリティ対策済みの環境に限定することができる。
【符号の説明】
【００５９】
１、１Ａ  WebAPI利用許諾システム
２，２Ａ  API提供者サーバ
２１  開発者情報受付部
２２  キー情報生成部
２３  一時キー払出部
２４  格納情報受付部
２５  サーバ証明書検証部
２６  認証キー払出部
２７，２７Ａ  開発者情報格納部
２８  無効キー払出部  （認証キー払出部）
２９  認証キー有効化部
３  開発者端末
４  HTTPSサーバ
５  認証局
８  X.509公開鍵証明書
【図１】
2017004325.tif 000003
【図２】
2017004325.tif 000004
【図３】
2017004325.tif 000005
【図４】
2017004325.tif 000006
【図５】
2017004325.tif 000007
【図６】
2017004325.tif 000008
【図７】
2017004325.tif 000009
【図８】
2017004325.tif 000010
【図９】
2017004325.tif 000011
【図１０】
2017004325.tif 000012