図面 (/)

この項目の情報は公開日時点(2021年3月11日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題

セキュアAPフローを提供する。

解決手段

一方法が、アプリケーションプログラミングインターフェース(API)に対する入力データを取得するステップと、APIに対する入力データをAPIのプロバイダ公開鍵を使用して暗号化するステップとを含み得る。当該方法は、APIを呼び出すAPIリクエストをAPI管理サーバに送信するステップであり、APIリクエストは、APIに対するAPIコールと暗号化された入力データとを含む、ステップをさらに含み得る。APIリクエストは、API管理サーバがAPIコールに基づきAPI管理サービスを実行できるが暗号化された入力データを公開鍵で復号できないフォーマットであり得る。

概要

背景

APIは、二次的なシステムからの1つ以上のプログラミング機能へのアクセス許可するために使用される。例えば、クライアントデバイス上で動作しているプログラムが、動作中にAPIを呼び出すことがあり、APIリクエストをAPIプロバイダに送信することがある。APIプロバイダはAPIリクエストを処理し、レスポンスを送信することができる。頻繁に使用されるAPIの一例がFACEBOOK(登録商標ログインAPIであり、第三者はこれを介し、関連づけられたAPIコールと共にFACEBOOK(登録商標)ログインAPIプロバイダにそのログインクレデンシャルを送信することによりユーザを確認し、該APIプロバイダはAPIコールを処理し、レスポンスを送信する。

概要

セキュアAPIフローを提供する。 一方法が、アプリケーションプログラミングインターフェース(API)に対する入力データを取得するステップと、APIに対する入力データをAPIのプロバイダの公開鍵を使用して暗号化するステップとを含み得る。当該方法は、APIを呼び出すAPIリクエストをAPI管理サーバに送信するステップであり、APIリクエストは、APIに対するAPIコールと暗号化された入力データとを含む、ステップをさらに含み得る。APIリクエストは、API管理サーバがAPIコールに基づきAPI管理サービスを実行できるが暗号化された入力データを公開鍵で復号できないフォーマットであり得る。

目的

例えば、API管理サービスは、クレデンシャル収集し、かつ/あるいは複数の異なるAPIプロバイダからの複数のAPIへのアクセスを提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

アプリケーションプログラミングインターフェースAPI)に対する入力データを取得するステップと、前記APIに対する前記入力データを前記APIのプロバイダ公開鍵を使用して暗号化するステップと、前記APIを呼び出すAPIリクエストをAPI管理サーバに送信するステップであり、前記APIリクエストは、前記APIに対するAPIコールと前記暗号化された入力データとを含み、前記APIリクエストは、前記API管理サーバが前記APIコールに基づきAPI管理サービスを実行できるが前記暗号化された入力データを前記公開鍵で復号できないフォーマットである、ステップと、を含む方法。

請求項2

前記API管理サーバから前記APIリクエストに対するレスポンスを受信するステップであり、前記APIリクエストに対する前記レスポンスは、前記入力データに基づく前記APIの出力を含み、前記出力は、クライアントの公開鍵を使用して前記APIプロバイダにより暗号化される、ステップをさらに含む請求項1に記載の方法。

請求項3

前記APIリクエストに対する前記レスポンスを前記クライアントの秘密鍵を使用して復号するステップをさらに含む請求項2に記載の方法。

請求項4

前記APIリクエストは、クライアント識別子とAPIプロバイダ識別子とAPI管理承認構造とを含む暗号化されていないデータコンポーネントをさらに含む、請求項1に記載の方法。

請求項5

開発者データを前記APIリクエストの一部であるように暗号化するステップであり、前記開発者データは、前記入力データを取得する前に開発者により提供される、ステップをさらに含む請求項1に記載の方法。

請求項6

前記プロバイダの前記公開鍵は、前記APIリクエストを生成するコンピュータプログラム内に埋め込まれ、それにより、前記入力データの前記暗号化はユーザ入力なしに生じる、請求項1に記載の方法。

請求項7

前記API管理サービスは、トラフィック制御管理ポリシー実施、及びセキュリティポリシー実施のうち少なくとも1つを含む、請求項1に記載の方法。

請求項8

プロセッサに動作を実行させるコンピュータプログラムであって、前記動作は、アプリケーションプログラミングインターフェース(API)に対する入力データを取得することと、前記APIに対する前記入力データを前記APIのプロバイダの公開鍵を使用して暗号化することと、通信コンポーネントに、前記APIを呼び出すAPIリクエストをAPI管理サーバに送信するように指示することであり、前記APIリクエストは、前記APIに対するAPIコールと前記暗号化された入力データとを含み、前記APIリクエストは、前記API管理サーバが前記APIコールに基づきAPI管理サービスを実行できるが前記暗号化された入力データを前記公開鍵で復号できないフォーマットである、ことと、を含む、コンピュータプログラム。

請求項9

前記動作は、前記API管理サーバから前記APIリクエストに対するレスポンスを受信することであり、前記APIリクエストに対する前記レスポンスは、前記入力データに基づく前記APIの出力を含み、前記出力は、クライアントの公開鍵を使用して前記APIプロバイダにより暗号化される、ことをさらに含む、請求項8に記載のコンピュータプログラム。

請求項10

ステムであって、1つ以上のプロセッサと、前記1つ以上のプロセッサにより実行されることに応答して当該システムに動作を実行させる命令を含む1つ以上の非一時的コンピュータ読取可能媒体と、を含み、前記動作は、アプリケーションプログラミングインターフェース(API)に対する入力データを取得することと、前記APIに対する前記入力データを前記APIのプロバイダの公開鍵を使用して暗号化することと、通信コンポーネントに、前記APIを呼び出すAPIリクエストをAPI管理サーバに送信するように指示することであり、前記APIリクエストは、前記APIに対するAPIコールと前記暗号化された入力データとを含み、前記APIリクエストは、前記API管理サーバが前記APIコールに基づきAPI管理サービスを実行できるが前記暗号化された入力データを前記公開鍵で復号できないフォーマットである、ことと、を含む、システム。

技術分野

0001

本開示の実施形態は、セキュアアプリケーションプログラミングインターフェースAPI)フローに関する。

背景技術

0002

APIは、二次的なシステムからの1つ以上のプログラミング機能へのアクセス許可するために使用される。例えば、クライアントデバイス上で動作しているプログラムが、動作中にAPIを呼び出すことがあり、APIリクエストをAPIプロバイダに送信することがある。APIプロバイダはAPIリクエストを処理し、レスポンスを送信することができる。頻繁に使用されるAPIの一例がFACEBOOK(登録商標ログインAPIであり、第三者はこれを介し、関連づけられたAPIコールと共にFACEBOOK(登録商標)ログインAPIプロバイダにそのログインクレデンシャルを送信することによりユーザを確認し、該APIプロバイダはAPIコールを処理し、レスポンスを送信する。

0003

本開示の1つ以上の実施形態は、アプリケーションプログラミングインターフェース(API)に対する入力データを取得するステップと、APIに対する入力データをAPIのプロバイダの公開鍵を使用して暗号化するステップとを含む方法を含み得る。当該方法は、APIを呼び出すAPIリクエストをAPI管理サーバに送信するステップであり、APIリクエストは、APIに対するAPIコールと暗号化された入力データとを含む、ステップをさらに含み得る。APIリクエストは、API管理サーバがAPIコールに基づきAPI管理サービスを実行できるが暗号化された入力データを公開鍵で復号できないフォーマットであり得る。

0004

実施形態の目的及び利点は、少なくとも特許請求の範囲において特に指し示された要素、特徴、及び組み合わせにより実現され、達成される。

0005

前述の一般的な説明及び以下の詳細な説明の双方が単に例であり、説明的であり、限定でないことが理解されるべきである。

図面の簡単な説明

0006

例示的な実施形態が、添付図面の使用を通してさらなる特定性及び詳細と共に記載され、説明される。
API管理サービスを通したセキュアAPIフローに使用され得る一例示的なシステムを示す図である。
セキュアAPIフローで使用される一例示的なAPIリクエストを示す。
セキュアAPIフローで使用される一例示的なAPIリクエストの一代替図を示す。
図4図5A、及び図5Bは、セキュアAPIフローの一例示的な実装の一例示的なスイムレーン図及び関連フローチャートをそれぞれ示す。
図4図5A、及び図5Bは、セキュアAPIフローの一例示的な実装の一例示的なスイムレーン図及び関連フローチャートをそれぞれ示す。
図4図5A、及び図5Bは、セキュアAPIフローの一例示的な実装の一例示的なスイムレーン図及び関連フローチャートをそれぞれ示す。
一例示的なコンピューティングシステムを示す。

実施例

0007

本開示は、API管理サービスを使用するとき秘密データを安全にするために公開及び秘密鍵ペアを使用することに関する。API管理サービスには、APIのクライアントとAPIプロバイダとの間で「仲立」又は「仲介」として動作するサービスを含み得る。例えば、API管理サービスは、クレデンシャル収集し、かつ/あるいは複数の異なるAPIプロバイダからの複数のAPIへのアクセスを提供することができる。API管理サービスへのアクセスを有することにより、ユーザは単一のシステムを通して複数のAPIにアクセスすることができる。しかしながら、API管理サービスを通してAPIリクエストを送信するとき、APIリクエストデータがAPI管理サービスに晒される可能性がある。APIリクエストをサブミットするとき、リクエストデータは機密データの可能性がある。例えば、FACEBOOK(登録商標)ログインAPIのリクエストをサブミットするとき、リクエストは、ユーザのFACEBOOK(登録商標)アカウントパスワードを含む。

0008

本開示は、API管理サービスを通過するAPIフローなどの、API管理サービスと対話するためのセキュアなアプローチを提供する実施形態を提供する。開発者は、APIを使用する許可を要求するとき、APIプロバイダと公開鍵を交換することができる。開発者は、開発者により開発されたソフトウェアがAPIコールを呼び出すときに使用される開発者秘密鍵及びAPIプロバイダ公開鍵を組み込むことができる。例えば、APIリクエストと共に送信される入力データ及び/又は開発者データ(APIアクセス情報など)は、APIプロバイダの公開鍵を使用して暗号化されてもよい。入力データ及び/又は開発者データを暗号化することにより、API管理サービスは、入力データを観察又は復号できることなく、APIリクエストに対して期待される管理サービスを依然として実行し得る。例えば、APIリクエストのメタデータは暗号化されていない可能性がある。API管理サービスを実行した後、API管理サーバはAPIリクエストをAPIプロバイダに転送し得る。APIプロバイダは、その独自の秘密鍵を使用して入力データ及び/又は開発者データを復号し、入力データを使用して入力データを使用するAPIを呼び出し得る。APIからのレスポンスは、開発者の公開鍵を使用して暗号化されてもよい。レスポンスは反対に通信されてもよく、再度、API管理サーバは、レスポンスデータを観察又は復号できることなく管理サービスを実行する。APIクライアントは、開発者の秘密鍵を使用してレスポンスを復号し得る。このようにして、APIへの入力データ/開発者データとAPIを呼び出した後のレスポンス(例えば、APIの出力)の双方が、API管理サービスを通過するときに暗号化されている。

0009

本開示の特定の実施形態は、API管理サービスの従前の反復を上回る向上を提供し得る。例えば、本開示の実施形態は、情報の限られた露出を可能にすることによりAPIクライアントとAPIプロバイダとの間のよりセキュアな対話を提供することができる。さらに、本開示は、API管理サービスが実行されることを依然として可能にする方法でそうすることができる。本明細書で用いられるとき、用語「APIクライアント」は、APIコールを呼び出す任意のエンティティデバイス、プログラム等を参照し得る。

0010

1つ以上の例示的な実施形態が、添付の図面を参照して説明される。

0011

図1は、本開示の1つ以上の実施形態による、セキュアAPIフローに使用され得る一例示的なシステム100を示す図である。システム100は、開発者(developer)110及びAPIプロバイダ120を含み得る。開発者110は、APIプロバイダ120により提供されるAPI125を呼び出すAPIコール118を有するプログラム115を開発することができる。API管理サービス130は、API管理サービスを提供することができる。エンドユーザデバイス150は、APIコール118を呼び出すプログラム115を利用することができる。

0012

動作において、開発者110及びAPIプロバイダ120は、暗号化鍵140を交換することができる。例えば、開発者110が秘密公開鍵ペアを生成してもよく、開発者110により生成された公開鍵をAPIプロバイダ120に提供してもよい。これら及び他の実施形態において、開発者110は、秘密/公開鍵ペアを一般的に開発者110のために利用してもよく、あるいはそのようなペアを特定のプログラム(プログラム115など)のために生成してもよく、あるいはそのようなペアをプログラム115の特定のエンドユーザ又はライセンスのために生成してもよい。別の例として、APIプロバイダ120が秘密/公開鍵ペアを生成してもよく、APIプロバイダ120により生成された公開鍵を開発者110に提供してもよい。これら及び他の実施形態において、APIプロバイダ120は、秘密/公開鍵ペアを一般的にAPIプロバイダ120のために利用してもよく、あるいはそのようなペアを特定のAPI(API125など)のために生成してもよく、あるいはそのようなペアを特定の開発者110のために生成してもよい。

0013

開発者110は、プログラム115を開発及び/又は実装するときに暗号化鍵140を利用することができる。いくつかの実施形態において、プログラム115は、APIコール118を呼び出すとき、APIプロバイダ120から開発者110により受信された公開鍵を使用してプログラム115がAPIコール118への入力データを暗号化し得るように、コード化されてもよい。さらに、プログラム115は、開発者110及び/又はプログラム115によるAPI125へのアクセスを可能にするためのセキュア情報などの開発者データを暗号化してもよい。そうする際、プログラム115は、APIリクエスト160の一部分を暗号化してもよく(例えば、暗号化された部分164)、APIリクエスト160の一部分を暗号化されないままにしてもよい(例えば、暗号化されていない部分162)。このような暗号化されていない情報には、APIリクエスト160に関するメタデータ、例えば、リクエストがどこにルーティングされるべきか、利用されるHTTP動詞機能(verb function)などを含んでもよい。このようにして、API管理サービス130は、APIプロバイダ120の秘密鍵なしでは暗号化された部分を復号できないと同時に、API管理サービス130により観察可能な暗号化されていない部分162に基づいてAPIリクエスト160に対する管理タスクを実行することができる。任意の管理タスクを実行した後、API管理サービス130はAPIリクエスト160をAPIプロバイダ120に転送してもよく、それにより、API125は入力データを処理することができる。

0014

いくつかの実施形態において、暗号化された部分164を有するAPIリクエスト160を受信したとき、APIプロバイダ120は、APIプロバイダ120の秘密鍵を使用して、暗号化された部分164を復号することができる。通信及びAPI管理は、入力データに対して動作するAPI125からのAPIレスポンスに基づいて、同様の方法で反対に生じてもよい。例えば、APIプロバイダ120は、開発者110の公開鍵を使用してレスポンスを暗号化し、レスポンスをサブミットし(submit)、レスポンスの部分を暗号化されないままにしてもよく(例えば、メタデータ)、それにより、API管理サービス130は、レスポンスに対して管理サービスを実行することができる。任意の管理タスクを実行した後、API管理サービス130はレスポンスをプログラム115へ転送してもよく、それにより、プログラム115はレスポンスを利用することができる。例えば、プログラム115は、プログラム115が開発者110の秘密鍵を利用してレスポンスを復号するように、コード化されてもよい。

0015

いくつかの実施形態において、本開示はAPI認証との互換性を残す。例えば、開発者110がその公開鍵をAPIプロバイダ120に提供するとき、APIプロバイダ120は、API125へのアクセスを許可するクレデンシャル又は他の認証情報を開発者110に提供してもよい。いくつかの実施形態において、認証情報は、暗号化された部分164又は暗号化されていない部分162の一部でもよい。例えば、ハイパーテキストトランスファープロトコル(HTTP)認証について、APIリクエスト160の中でユーザ名及びパスワードが提供されて、APIプロバイダ120に対して真正性を証明してもよい。このような例において、ユーザ名及び/又はパスワードは、暗号化された部分164に含まれてもよい。認証の他の例には、APIキーオープン認証(OAuthバージョン1.0、2.0等を含むOAuth)が含まれる。

0016

いくつかの実施形態において、API認証情報は、開発者データの一部として暗号化された部分164の一部である。開発者データの1つ以上の他のコンポーネントが、開発者110及び/又はプログラム115のセキュア識別情報などの、暗号化された部分164の一部でもよい。

0017

開発者110は、APIプロバイダ120からのAPI125の使用の許可を開始し得る任意のエンティティ、当事者(party)、又は組織を含むことができる。例えば、開発者110は、ソフトウェアプログラマウェブ開発者、アプリ開発者ハードウェア開発者等を含んでもよい。これら及び他の実施形態において、プログラム115は、APIコール118を呼び出す任意の実行可能命令を含んでもよい。例えば、プログラム115は、ソフトウェアプログラム、ウェブスクリプト、ハードウェアスクリプト等を含んでもよい。

0018

エンドユーザデバイス150は、プログラム115を動作させてAPIコール118を呼び出す任意のデバイスを含むことができる。例えば、プログラム115がウェブスクリプトである場合、エンドユーザデバイス150は、スクリプトを処理するブラウザ又は他のウェブアクセスソフトウェアを有するデバイスでもよい。別の例として、プログラム115が(例えば、スマートウォッチ又は他のモノインターネット(IOT)デバイスの)ハードウェアスクリプトである場合、エンドユーザデバイスは、ハードウェアスクリプトを実行するデバイスでもよい。いくつかの実施形態において、エンドユーザデバイス150は、入力データのためのユーザ入力を受信することができる。例えば、エンドユーザデバイス150のユーザが、APIリクエスト160における入力データとして使用されるテキスト文字列、画像等を入力してもよい。いくつかの実施形態において、開発者110は、例えばテスト初期実装、開発等の間、エンドユーザデバイス150として操作してもよい。

0019

APIプロバイダ120は、API125などのAPIへのアクセスを開発、ホスト、又はその他の方法で提供し得る任意のエンティティ、当事者、又は組織を含むことができる。APIプロバイダ120は、任意数のAPIへのアクセスを提供することができる。

0020

暗号化鍵140は、通信を安全にするために使用される任意タイプの公開/秘密鍵ペアリング及び/又は暗号化アルゴリズムを含むことができる。例えば、暗号化鍵140は、セキュアシェル(secure shell、SSH)公開鍵暗号化で動作してもよい。別の例として、暗号化鍵140は、データ暗号化標準(Data Encryption Standard、DES)、トリプルDES、RSA、Blowfish、Twofish、高度暗号化標準(Advanced Encryption Standard、AES)等と関連して導出及び/又は使用されてもよい。

0021

API管理サービス130は、APIへのアクセスを提供し、かつ/あるいはAPIプロバイダ120及び/又はエンドユーザデバイス150を行き来する又はこれらの間のトラフィックに対する管理タスクを実行するように構成された、任意のシステム、デバイス、コンポーネント、サーバ等を含むことができる。例えば、管理タスクは、トラフィック制御(例えば、APIコール数の制限、APIコールがサブミットされるレートの制御等)、管理ポリシー(例えば、APIリクエストの分類、APIリクエストの優先順位付け等)、セキュリティポリシー(例えば、エンドユーザデバイス150のクレデンシャルの確認等)などを含んでもよい。

0022

中間者」として示されているが、いくつかの実施形態において、API管理サービス130は、APIクライアントの一部として動作してもよく(例えば、第三者API管理サービスへのプログラム呼び出し、プログラム115に含まれるソフトウェアパッケージなどの、プログラム115の一部としてコード化されてもよい)、それにより、APIプロバイダ120は、プログラム115がAPI管理サービス130を使用していることを認識しなくてもよい。さらに又は代わりに、API管理サービス130は、APIプロバイダ120の一部として動作してもよく、それにより、プログラム115及び/又は開発者110は、APIプロバイダ120がAPI管理サービス130を使用していることを認識しなくてもよい。いくつかの実施形態において、他方に認識させない能力は、APIリクエスト/レスポンス160が向けられるアドレス(例えば、直接他の当事者でなくAPI管理サービス130へ)に基づいてもよい。

0023

本開示の範囲から逸脱することなく、システム100に対して変更、追加、又は省略がなされてもよい。例えば、記載された方法における異なる要素の指定は、本明細書に記載される概念の説明を助けることが意図され、限定的ではない。さらに、システム100は、任意数の他の要素を含んでもよく、あるいは記載されたものとは他のシステム又は文脈において実現されてもよい。例えば、図1のコンポーネントのうち任意のものが、さらなるコンポーネントに分割されてもよく、あるいはより少ないコンポーネントに結合されてもよい。

0024

図2は、本開示の1つ以上の実施形態による、セキュアAPIフローで使用される一例示的なAPIリクエスト200を示す。APIリクエスト200は、図1のAPIリクエスト/レスポンス160と同様であり、あるいは相当し得る。図2に示すように、APIリクエスト200は、暗号化されていない部分210及び暗号化された部分220を含み得る。暗号化されていない部分210は、通信中にAPI管理サービスに可視の部分を含むことができ、暗号化された部分は、秘密鍵がエンティティにより保持されている場合のみ見える部分を含むことができる(例えば、APIプロバイダは、暗号化部分を暗号化するために使用された公開鍵に関連づけられた秘密鍵を維持する)。

0025

いくつかの実施形態において、暗号化されていない部分210は、クライアント識別子フィールド212、プロバイダ識別子フィールド214、及び/又は承認情報フィールド216を含んでもよい。いくつかの実施形態において、クライアント識別子フィールド212は、APIを呼び出すデバイス、コンポーネント、システム、ソフトウェア等、及び/又はユーザ(APIクライアントと呼ばれる)のための識別子を含んでもよい。そのような識別子には、非機密の(例えば、クライアント識別子が潜在的に悪意のある当事者により観察されることがAPIクライアントにとって有害でない)識別子を含んでもよい。クライアント識別子フィールド212内のクライアント識別子は、APIレスポンスがどこに送信されるべきかについての識別子又は他の位置情報役割を果たしてもよい。このような識別子の例には、インターネットプロトコル(IP)アドレス、媒体アクセス制御(MAC)アドレス、ユーザ名等を含んでもよい。

0026

いくつかの実施形態において、プロバイダ識別子フィールド214は、APIをホスト又はその他の方法で提供するデバイス、コンポーネント、システム、ソフトウェア等、及び/又は組織が識別され得る識別子を含んでもよい。そのような識別子には、非機密の識別子を含んでもよい。プロバイダ識別子フィールド214内のAPIプロバイダ識別子は、APIリクエストがどこに送信されるべきかについての識別子又は他の位置情報の役割を果たしてもよい。このような識別子の例には、IPアドレスMACアドレス、URL、組織名等を含んでもよい。

0027

承認情報フィールド216は、APIサービスマネージャ及び/又はAPIプロバイダとの間でAPIクライアントを確認するために使用される任意の情報を含んでもよい。例えば、承認情報フィールド216は、APIクライアントがAPIサービスマネージャにより検証され得るためのトークン又は他の認証情報を含んでもよい。別の例として、承認情報フィールド216は、APIプロバイダとの間でクライアントを認証するために使用される認証情報を含んでもよい。いくつかの実施形態において、承認情報フィールド216は、暗号化されていない部分210でなく暗号化された部分220に含まれてもよい。

0028

いくつかの実施形態において、暗号化された部分220は、機密認証情報222及び/又はデータペイロード224を含んでもよい。機密認証情報222は、APIクライアントがAPIプロバイダとの間で自身を認証し得るための情報だが、潜在的に悪意のある当事者により観察された場合に危険にさらす可能性がある情報(例えば、APIクライアントがAPIプロバイダとの間で自身を認証するために使用するパスワード)を含んでもよい。データペイロード224は、APIリクエスト200が送信されているAPIへの入力として提供される任意の情報を含んでもよい。例えば、データペイロード224は、テキスト、画像、ファイル、又は他の任意のデータを含んでもよい。

0029

本開示の範囲から逸脱することなく、APIリクエスト200に対して変更、追加、又は省略がなされてもよい。例えば、記載された方法における異なる要素の指定は、本明細書に記載される概念の説明を助けることが意図され、限定的ではない。さらに、APIリクエスト200は、任意数の他の要素を含んでもよく、あるいは記載されたものとは他のシステム又は文脈において実現されてもよい。例えば、APIリクエスト200は、暗号化されていない部分210又は暗号化された部分220のいずれかに任意の数又はタイプのフィールドを含んでもよい。

0030

図3は、本開示の1つ以上の実施形態による、セキュアAPIフローで使用される一例示的なAPIリクエスト300の一代替図を示す。APIリクエスト300は、API管理サービスを通したAPIコールルーティングの様々な部分間の論理的関係を示す。

0031

ブロック310は、API管理サービスを通してルーティングされるAPIコールを示す。ブロック310から延びる矢印により示されるように、APIリクエスト300は、APIリクエスト300が最初にどこにルーティングされるべきかを識別するAPIマネージャURL312を含んでもよい。さらに又は代わりに、APIリクエスト300は、API管理サービスがAPIリクエスト300を取得するためにいずれのメソッドを利用し得るかを示すハイパーテキストトランスファープロトコル(HTTP)メソッド314を含んでもよい(例えば、リクエストは、POST、PUSH、GET等のHTTPメソッドを介して送信されてもよい)。例えば、PUSHコマンドは、API管理URL312におけるAPI管理サーバにAPIリクエストを自動的にプッシュすることができる。いくつかの実施形態において、APIリクエスト300は、API管理サービスの使用を承認する認証情報を含んでもよい。

0032

破線ブロック320は、ネイティブAPIコールの潜在的に暗号化された部分(例えば、API管理システムに送信される要素のないAPIコール)を表し得る。例えば、ネイティブAPIコールは、ヘッダ321、クエリ322、及びボディ323を含んでもよい。ヘッダ321、クエリ322、及び/又はボディ323の何らかの組み合わせに含まれるAPIリクエスト300は、API認証325(例えば、APIプロバイダとの間のAPIクライアントの認証中に使用される情報又はクレデンシャル)、1つ以上のリクエストパラメータ326(例えば、APIに対する入力データ)、リクエストネイティブAPI URL32(例えば、呼び出されるAPIにアクセスするためのURL)、及び/又はネイティブHTTPメソッド328(例えば、APIプロバイダがAPIリクエスト300を取得するためにいずれのメソッドを利用し得るか)を含んでもよい。

0033

APIプロバイダによるAPIの実装及び/又はAPI管理サービスの実装に依存して、ネイティブAPIリクエストの異なるデータコンポーネントが、ヘッダ321、クエリ322、及び/又はボディ323間の異なるコンポーネントに存在し得る。例えば、ヘッダ321は、リクエストネイティブAPI URL327及びAPI認証を含んでもよく、クエリ322は、ネイティブHTTPメソッド328を含んでもよく、ボディ323は、リクエストパラメータ326を含んでもよい。これら及び他の実施形態において、ヘッダ321、クエリ322、及び/又はボディ323の任意の組み合わせが暗号化されてもよい。例えば、ヘッダ321が暗号化されなくてもよく、クエリ322及びボディ324が暗号化されてもよい。

0034

本開示の範囲から逸脱することなく、APIリクエスト300に対して変更、追加、又は省略がなされてもよい。例えば、記載された方法における異なる要素の指定は、本明細書に記載される概念の説明を助けることが意図され、限定的ではない。さらに、APIリクエスト300は、任意数の他の要素を含んでもよく、あるいは記載されたものとは他のシステム又は文脈において実現されてもよい。例えば、APIリクエスト300は、図3に示されるものとは他のコンポーネントを含んでもよい。

0035

図4図5A、及び図5Bは、本開示の1つ以上の実施形態による、セキュアAPIフローの一例示的な実装の一例示的なスイムレーン図400及び関連フローチャートの方法500をそれぞれ示す。図4は、開発者410、APIプロバイダ420、API管理サーバ430、及びAPIクライアント415間のいずれのエンティティが、図5A及び図5Bに示される動作505〜590に対応する(505〜590とラベル付けされた)種々の動作を実行するかを示す。

0036

スイムレーン図400及び/又は方法500の1つ以上の動作は、システム100、開発者110、APIプロバイダ120、API管理サービス130、及び/又はエンドユーザ150などの、システム若しくはデバイス又はこれらの組み合わせにより実行され得る。別個のブロックとして示されているが、スイムレーン図400及び/又は方法500の種々のブロックは、所望の実装に依存してさらなるブロックに分割されてもよく、より少ないブロックに結合されてもよく、あるいは除去されてもよい。さらに、開発者410、APIプロバイダ420、API管理サーバ430、及びAPIクライアント415間の特定のエンティティが特定のタスクを実行するが、これらは単なる例であり、異なるエンティティが種々のアクション及び/又はさらなるアクションを実行してもよいことが理解される。

0037

ブロック505において、開発者410が、APIクライアント415により使用されるべきメッセージの暗号化のための公開及び秘密鍵を生成し得る。いくつかの場合に、秘密鍵は、APIクライアント415などの特定のAPIクライアントに固有でもよく、あるいは開発者により開発されたソフトウェアが使用されるすべての場合に使用される秘密鍵でもよい。これら及び他の実施形態において、秘密鍵及び公開鍵は、開発者410により開発されるソフトウェアプログラムにエンコードされてもよく、それにより、秘密鍵及び/又は公開鍵は、ソフトウェアの利用者にはアクセスできない。数学的に記載すると以下のとおりである。
KeyPairclient=(PKC,PRc)
KeyPairclientは、クライアントのために生成される鍵のペアに対応し、PKcは、開発者410により生成される公開鍵であり、PRcは、APIクライアント415のために開発者410により生成される秘密鍵である。

0038

ブロック510において、開発者410が、APIへのアクセスを要求するリクエストをAPIプロバイダ420にサブミットし得る。アクセスを要求する典型的なメッセージに追加で、開発者410は、ブロック505で生成された公開鍵(例えば、公開鍵PKc)を含めてもよく、それにより、APIプロバイダ420は、開発者410により生成されたAPIクライアント415の公開鍵へのアクセスを有し得る。これら及び他の実施形態において、開発者410は、開発されたソフトウェアプログラムに含まれ得るアクセストークンを要求してもよく、それにより、APIが呼び出されたとき、アクセストークンが利用され、かつ/あるいは、開発されたソフトウェアプログラムが実行しているときにAPIプロバイダへのリクエストに含まれる。さらに又は代わりに、ユーザ名/パスワード、OAuth、OAuth2、ダイジェストなどの任意の他タイプのAPI認証アプローチが利用されてもよい。

0039

ブロック515において、APIプロバイダ420が、APIプロバイダ420により使用されるべきメッセージの暗号化のための公開鍵及び秘密鍵を生成し得る。例えば、APIプロバイダ420は、APIクライアント415などの任意のAPIクライアントとの間でメッセージを暗号化及び復号するために公開鍵及び秘密鍵のペアを利用してもよい。数学的に記載すると以下のとおりである。
KeyPairMG=(PKMG,PRMG)
KeyPairMGは、APIプロバイダ420により生成される鍵のペアに対応し、PKMGは、APIプロバイダ420により生成される公開鍵であり、PRMGは、APIプロバイダ420により生成される秘密鍵である。

0040

ブロック520において、APIプロバイダ420が、開発者410にAPIへのアクセスを付与し得、ブロック515で生成されたAPIプロバイダ公開鍵を開発者410に提供し得る。例えば、APIプロバイダ420は、APIプロバイダ420の公開鍵(PKMG)と、APIにアクセスするとき開発者410及び/又はAPIクライアント415により使用されるべき任意の認証情報(例えば、API認証データ構造)とを含むメッセージを開発者410に送信してもよい。

0041

ブロック525において、API管理サーバへの登録が生じ得る。図4に示すように、動作525aにおいて、開発者410は、API管理サーバ430に登録することができ、API管理サーバ430は、API管理サーバ430への登録の認可/肯定応答(acknowledgment)を提供することができる。さらに又は代わりに、動作525bにおいて、APIプロバイダ420は、API管理サーバ430に登録することができ、API管理サーバ430は、API管理サーバ430への登録の対応する認可/肯定応答を提供することができる。これら及び他の実施形態において、登録は、登録当事者を認証する情報、例えば、サブスクリプション名、サブスクリプション識別子プライマリキー、トークン、開発者410/APIプロバイダ420のユーザ名(例えば、電子メールアドレス)などを含んでもよい。いくつかの実施形態において、動作525a及び525bの双方が実行されてもよく、それにより、APIプロバイダ420及び開発者410は双方、API管理サーバ430に登録でき、これは、同じAPI管理サービス又は区別可能なAPI管理サービスを含んでもよい。

0042

ブロック530において、開発者410が、APIアクセス情報及び暗号化情報をAPIクライアントに提供し得る。例えば、開発者410は、API認証情報及びAPIプロバイダ420の公開鍵を組み込んだソフトウェアを配布してもよく、それにより、ソフトウェアは、APIプロバイダ420へのAPIリクエストの部分を暗号化することができる。別の例として、ソフトウェアは、開発者410により生成された秘密鍵をエンコードしてもよく、それにより、ソフトウェアは、APIプロバイダ420からのメッセージを復号することができる。さらなる例として、開発者410は、APIアクセス情報(例えば、API認証トークンなど)及び暗号化情報(例えば、秘密鍵PRC及び公開鍵PKMG)を、開発されたソフトウェアとは別個の区別可能なコンポーネント又はクレデンシャルとして提供してもよい。そのような情報、又は開発者410に固有及び/又は開発者410により使用される他の情報は、開発者データとして特徴づけられてもよい。

0043

ブロック535において、APIクライアント415が、APIプロバイダ420のAPIに対する入力データを取得し得る。例えば、配布されたソフトウェアが動作しているとき、それがユーザ入力を要求してもよく、あるいはAPI管理サーバ430により管理されるAPIプロバイダ420のAPIへの入力としてサブミットされるべき値又は他のデータを生成又はその他の方法で取得してもよい。

0044

ブロック540において、ブロック535の入力データが、APIプロバイダ420の公開鍵を使用して暗号化され得る。例えば、配布されたソフトウェアは、入力データ及び/又はAPIリクエストの他のコンポーネントをPKMGを使用して暗号化することができる。さらに、開発者データ(例えば、ブロック530で配布されたソフトウェアで提供されるものなどの、APIへのアクセスを許可するための認証情報)が暗号化され、リクエスト/リクエストの暗号化された部分の一部に含まれてもよい。数学的に記述すると、APIクライアント415(開発者410により配布されたソフトウェアを介したAPIクライアント415を含む)は、以下の演算を実行することができる。
ENC(Req,PKMG),& MG API Auth
ENCは、暗号化鍵(PKMG)を使用してコンテンツ(Req)を暗号化する機能を含むことができ、Reqは、暗号化されるべきブロック535の入力データ及び/又はAPIリクエストの他のデータを表すことができ、MG API Authは、ブロック525で提供される情報などの、API管理サーバ430にアクセスするために使用される認証情報を表すことができる。これら及び他の実施形態において、APIリクエストは、暗号化された部分及び暗号化されていない部分の双方を含んでもよい。

0045

ブロック545において、暗号化された入力データを有するAPIリクエストが、API管理サーバ430に送信され得る。例えば、APIクライアント415は、APIリクエストをAPI管理サーバ430に送信してAPIリクエストに対する管理サービスを実行することができる。

0046

ブロック550において、API管理サーバ430が、APIリクエストの暗号化されていない部分に基づいて、APIリクエストに対するAPI管理サービスを実行し得る。例えば、API管理サーバ430は、トラフィック制御を実行し、管理ポリシーを実施し(enforce)、セキュリティポリシーを実施し、リクエスト数に制限を課すなどが可能である。いくつかの実施形態において、API管理サーバ430は、APIリクエストを破棄してもよく(例えば、割り当て量を超えた場合)、APIリクエストを遅延又は延期させてもよく、1つのリクエストを他のものより上に優先順位付けてもよい。これら及び他の実施形態において、このようなタスクは、暗号化されていないAPIリクエストのメタデータに基づいて実行されてもよい。

0047

ブロック555において、API管理サーバ430が、APIリクエストをAPIプロバイダ420に転送し得る。

0048

ブロック560において、APIプロバイダ420が、APIプロバイダ420の秘密鍵(例えば、PRMG)を使用してAPIリクエストを復号し得る。いくつかの実施形態において、APIリクエストが復号される前に、APIリクエストに対して実行される予備的承認があってもよい。復号は、数学的に以下のように記述され得る。
DEC(Req,PRMG)
DECは、鍵PRMGを使用したコンテンツReqの復号アルゴリズムを表すことができる。

0049

ブロック565において、APIが、ブロック535で取得された入力データを使用して呼び出され、出力を生成し得る。

0050

ブロック570において、APIプロバイダ420が、ブロック510で開発者410により提供された公開鍵を使用して、APIの呼び出しからのレスポンス(例えば、APIの出力)を暗号化し得る。例えば、数学的に記述されると以下のとおりである。
ENC(Res,PKC)

0051

ブロック575において、ブロック570からの暗号化されたレスポンスデータを有するAPIレスポンスが、APIプロバイダ420からAPI管理サーバ430に送信され得る。これら及び他の実施形態において、APIレスポンスは、暗号化された部分(例えば、APIにより生成されたレスポンス)と暗号化されていない部分(例えば、レスポンスがどこに送られるべきかの識別情報)とを含んでもよい。

0052

ブロック580において、API管理サーバ430が、ブロック575で送信されたAPIレスポンスの暗号化されていない部分に基づいて管理サービスを実行し得る。

0053

ブロック585において、APIレスポンスが、API管理サーバ430からAPIクライアント415へ転送され得る。

0054

ブロック590において、APIレスポンスが、秘密鍵PRCを使用してAPIクライアント415により復号され得る。数学的に記述すると、APIクライアント415は以下の演算を実行することができる。
DEC(Req,PRC)

0055

このようなアプローチを使用することにより、API管理サーバ430は、リクエスト及びレスポンスの実際の内容へのアクセスを有することなく、APIリクエスト及びレスポンスに対する管理サービスを実行し続けることができる。

0056

本開示の範囲から逸脱することなく、スイムレーン図400及び/又は方法500に対して変更、追加、又は省略がなされてもよい。例えば、スイムレーン図400及び/又は方法500の動作は異なる順序で実現されてもよい。さらに又は代わりに、2つ以上の動作が同時に実行されてもよい。さらに、概説された動作及びアクションは例として提供されているに過ぎず、動作及びアクションのいくつかは、開示される実施形態の本質を損なうことなく、任意であってもよく、より少ない動作及びアクションに結合されてもよく、あるいはさらなる動作及びアクションへ拡張されてもよい。

0057

図6は、本開示に記載される少なくとも1つの実施形態による、一例示的なコンピューティングシステム600を示す。コンピューティングシステム600は、プロセッサ610、メモリ620、データ記憶装置630、及び/又は通信ユニット640を含んでもよく、これらはすべて通信上結合されてもよい。図1のシステム100の一部又は全部が、開発者110、APIプロバイダ120、API管理サービス130、及び/又はエンドユーザデバイス150を含む、コンピューティングシステム600と一貫性のあるコンピューティングシステムとして実現されてもよい。

0058

一般に、プロセッサ610は、種々のコンピュータハードウェア又はソフトウェアモジュールを含む、任意の適切な専用若しくは汎用コンピュータコンピューティングエンティティ、又は処理デバイスを含んでもよく、任意の適用可能なコンピュータ読取可能記媒体に記憶された命令を実行するように構成されてもよい。例えば、プロセッサ610は、マイクロプロセッサマイクロコントローラデジタル信号プロセッサ(DSP)、特定用途向け集積回路ASIC)、フィールドプログラマブルゲートアレイFPGA)、又はプログラム命令解釈及び/又は実行するよう及び/又はデータを処理するように構成された任意の他のデジタル若しくはアナログ回路を含んでもよい。

0059

図6において単一のプロセッサとして示されているが、プロセッサ610は、本開示に記載の任意数の動作を個々又は集合的に実行するように構成された、任意数のネットワーク又は物理位置にわたり分散された任意数のプロセッサを含んでもよい。いくつかの実施形態において、プロセッサ610は、メモリ620、データ記憶装置630、又はメモリ620及びデータ記憶装置630に記憶されたプログラム命令を解釈及び/又は実行し、かつ/あるいはデータを処理してもよい。いくつかの実施形態において、プロセッサ610は、データ記憶装置630からプログラム命令を取り出し、プログラム命令をメモリ620にロードしてもよい。

0060

プログラム命令がメモリ620にロードされた後、プロセッサ610は、プログラム命令、例えば、図4及び図5のスイムレーン図400及び/又は方法500にそれぞれ示される動作のうち任意のものを実行する命令などを実行することができる。例えば、プロセッサ610は、APIリクエストへの入力データを取得することができ、そのデータをAPIプロバイダの公開鍵を使用して暗号化することができる。

0061

メモリ620及びデータ記憶装置630は、記憶されたコンピュータ実行可能命令又はデータ構造を搬送し又は有するコンピュータ読取可能記憶媒体又は1つ以上のコンピュータ読取可能記憶媒体を含むことができる。そのようなコンピュータ読取可能記憶媒体は、プロセッサ610などの汎用又は専用コンピュータによりアクセスされ得る任意の利用可能な媒体でもよい。例えば、メモリ620及び/又はデータ記憶装置630は、1つ以上の公開又は秘密鍵を記憶することができる。いくつかの実施形態において、コンピューティングシステム600は、メモリ620及びデータ記憶装置630のいずれかを含んでもよく、あるいは含まなくてもよい。

0062

限定でなく例として、そのようなコンピュータ読取可能記憶媒体は、ランダムアクセスメモリ(RAM)、読取専用メモリ(ROM)、電気的消去可能プログラマブル読取専用メモリ(EEPROM)、コンパクトディスク読取専用メモリ(CD‐ROM)若しくは他の光ディスク記憶装置磁気ディスク記憶装置若しくは他の磁気記憶デバイスフラッシュメモリデバイス(例えば、ソリッドステートメモリデバイス)、又はコンピュータ実行可能命令又はデータ構造の形式で所望のプログラムコードを搬送又は記憶するために使用でき、かつ汎用又は専用コンピュータによりアクセスできる任意の他の記憶媒体を含む、非一時的なコンピュータ読取可能記憶媒体を含んでもよい。上記の組み合わせもまた、コンピュータ読取可能記憶媒体の範囲内に含まれてもよい。コンピュータ実行可能命令は、例えば、プロセッサ610に特定の動作又は動作のグループを実行させるように構成された命令及びデータを含んでもよい。

0063

通信ユニット640は、ネットワークを介して情報を送信又は受信するように構成された任意のコンポーネント、デバイス、システム、又はこれらの組み合わせを含んでもよい。いくつかの実施形態において、通信ユニット640は、他の場所、同じ場所における他のデバイス、又はさらには同じシステム内の他のコンポーネントと通信してもよい。例えば、通信ユニット640は、モデムネットワークカード無線又は有線)、光通信装置赤外線通信装置無線通信装置アンテナなど)、及び/又はチップセット(Bluetooth(登録商標)装置、802.6装置(メトロポリタンエリアネットワークMAN)など)、WiFi装置、WiMax(登録商標)装置、セルラー通信設備等)などを含んでもよい。通信ユニット640は、ネットワーク及び/又は本開示に記載される任意の他のデバイス又はシステムとの間でデータが交換されることを可能にし得る。例えば、通信ユニット640は、システム600が、コンピューティングデバイス及び/又は他のネットワークなどの他のシステムと通信することを可能にし得る。

0064

業者は本開示を検討した後、本開示の範囲から逸脱することなくシステム600に対して変更、追加、又は省略がなされ得ることを認識し得る。例えば、システム600は、明示的に例示及び記載されたものより多くの又は少ないコンポーネントを含んでもよい。

0065

前述の開示は、開示された正確な形式又は特定の分野に本開示を限定することは意図されない。したがって、本明細書に明示的に記載されているか又は暗示されているかにかかわらず、本開示に対する種々の代替実施形態及び/又は修正が本開示に照らして可能なことが企図される。このように本開示の実施形態を説明したが、本開示の範囲から逸脱することなく形式及び詳細において変更がなされ得ることが認識され得る。したがって、本開示は、特許請求の範囲によってのみ限定される。

0066

いくつかの実施形態において、本開示に記載される異なるコンポーネント、モジュールエンジン、及びサービスが、コンピューティングシステム上で実行するオブジェクト又はプロセスとして(例えば、別個のスレッドとして)実現されてもよい。本明細書に記載されるシステム及びプロセスのいくつかは、一般に、(汎用ハードウェアに記憶され、及び/又は汎用ハードウェアにより実行される)ソフトウェアで実現されるものとして記載されるが、特定のハードウェア実装、又はソフトウェアと特定のハードウェア実装との組み合わせもまた可能であり、企図される。

0067

本明細書において、特に別記の特許請求の範囲(例えば、別記の特許請求の範囲の本文)において用いられる用語は、一般に「開放的」な用語として意図されている(例えば、用語「含んでいる」は、「含んでいるがこれに限定されない」と解釈されるべきであり、用語「有する」は、「少なくとも有する」と解釈されるべきであり、用語「含む」は、「含むがこれに限定されない」と解釈されるべきである、等)。

0068

さらに、特定数の導入された請求項記載が意図されている場合、そのような意図は請求項に明示的に記載され、そのような記載がない場合、そのような意図は存在しない。例えば、理解の助けとして、以下の別記の特許請求の範囲は、請求項記載を導入するために、導入フレーズ「少なくとも1つの」及び「1つ以上の」の使用を含むことがある。しかしながら、そのようなフレーズの使用は、不定詞「一の」(“a”又は“an”)による請求項記載の導入が、同じ請求項が導入フレーズ「1つ以上の」又は「少なくとも1つの」と「一の」などの不定冠詞とを含むときでも、そのような導入された請求項記載を含む任意の特定の請求項を1つのそのような記載のみ含む実施形態に限定することを暗に示すように見なされるべきではない(例えば、「一の」(“a”及び/又は“an”)は「少なくとも1つの」又は「1つ以上の」を意味するよう解釈されるべきである)。請求項記載を導入するために用いられる定冠詞の使用についても同様である。

0069

さらに、特定数の導入された請求項記載が明示的に記載されている場合であっても、当業者は、そのような記載は少なくとも記載された数を意味するよう解釈されるべきであることを認識するであろう(例えば、他の修飾語を伴わない「2つの記載」というただそれだけの記載は、少なくとも2つの記載、又は2つ以上の記載を意味する)。さらに、「A、B、及びC等のうち少なくとも1つ」又は「A、B、及びC等のうち1つ以上」と類似の規定が用いられている例において、一般に、そのような構造は、A単独、B単独、C単独、A及びB共に、A及びC共に、B及びC共に、又はA、B、及びC共に等を含むことが意図される。例えば、用語「及び/又は」の使用は、このようにみなされることが意図される。

0070

さらに、明細書においてか、特許請求の範囲においてか、又は図面においてかにかかわらず、2つ以上の代替的な用語を提示するいかなる分離的なワード又はフレーズも、用語のうち1つ、用語のうちいずれか、又は双方の用語を含む可能性を考慮するよう理解されるべきである。例えば、フレーズ「A又はB」は、「A」又は「B」又は「A及びB」の可能性を含むよう理解されるべきである。

0071

しかしながら、そのようなフレーズの使用は、不定冠詞「一の」(“a”又は“an”)による請求項記載の導入が、同じ請求項が導入フレーズ「1つ以上の」又は「少なくとも1つの」と「一の」などの不定冠詞とを含むときでも、そのような導入された請求項記載を含む任意の特定の請求項を1つのそのような記載のみ含む実施形態に限定することを暗に示すように見なされるべきではない(例えば、「一の」(“a”及び/又は“an”)は「少なくとも1つの」又は「1つ以上の」を意味するよう解釈されるべきである)。請求項記載を導入するために用いられる定冠詞の使用についても同様である。

0072

さらに、用語「第1」、「第2」、「第3」等の使用は、本明細書において必ずしも特定の順序を含意するために使用されるものではない。一般に、用語「第1」、「第2」、「第3」等は、異なる要素間で区別するために使用される。用語「第1」、「第2」、「第3」等が特定の順序を含意することの具体的な提示なしでは、これらの用語は特定の順序を含意するよう理解されるべきではない。

0073

本明細書に記載される全ての例及び条件付き言語は、本発明及び発明者が当該技術分野を促進するために寄与した概念を理解する際に読者を助けるための教育的目的が意図され、このように具体的に記載された例及び条件に限定されないものとみなされるべきである。本開示の実施形態が詳細に説明されたが、本開示の主旨及び範囲から逸脱することなく種々の変更、置換、及び改変をこれに行えることを理解されたい。

0074

開示された実施形態の前の説明は、当業者が本開示を製造又は使用することができるように提供される。これらの実施形態に対する種々の修正は、当業者には容易に明らかであり、本明細書で定義される一般的原理は、本開示の主旨又は範囲から逸脱することなく他の実施形態に適用され得る。したがって、本開示は、本明細書に示される実施形態に限定されることは意図されず、本明細書に開示された原理及び新規の特徴と一致する最も広い範囲を与えられるべきである。

0075

上記の実施形態につき以下の付記を残しておく。
(付記1)
アプリケーションプログラミングインターフェース(API)に対する入力データを取得するステップと、
前記APIに対する前記入力データを前記APIのプロバイダの公開鍵を使用して暗号化するステップと、
前記APIを呼び出すAPIリクエストをAPI管理サーバに送信するステップであり、前記APIリクエストは、前記APIに対するAPIコールと前記暗号化された入力データとを含み、前記APIリクエストは、前記API管理サーバが前記APIコールに基づきAPI管理サービスを実行できるが前記暗号化された入力データを前記公開鍵で復号できないフォーマットである、ステップと、
を含む方法。
(付記2)
前記API管理サーバから前記APIリクエストに対するレスポンスを受信するステップであり、前記APIリクエストに対する前記レスポンスは、前記入力データに基づく前記APIの出力を含み、前記出力は、クライアントの公開鍵を使用して前記APIプロバイダにより暗号化される、ステップをさらに含む付記1に記載の方法。
(付記3)
前記APIリクエストに対する前記レスポンスを前記クライアントの秘密鍵を使用して復号するステップをさらに含む付記2に記載の方法。
(付記4)
前記APIリクエストは、クライアント識別子とAPIプロバイダ識別子とAPI管理承認構造とを含む暗号化されていないデータコンポーネントをさらに含む、付記1に記載の方法。
(付記5)
開発者データを前記APIリクエストの一部であるように暗号化するステップであり、前記開発者データは、前記入力データを取得する前に開発者により提供される、ステップをさらに含む付記1に記載の方法。
(付記6)
前記プロバイダの前記公開鍵は、前記APIリクエストを生成するコンピュータプログラム内に埋め込まれ、それにより、前記入力データの前記暗号化はユーザ入力なしに生じる、付記1に記載の方法。
(付記7)
前記API管理サービスは、トラフィック制御、管理ポリシー実施、及びセキュリティポリシー実施のうち少なくとも1つを含む、付記1に記載の方法。
(付記8)
1つ以上のプロセッサにより実行されることに応答してシステムに動作を実行させる命令を含む1つ以上の非一時的コンピュータ読取可能媒体であって、前記動作は、
アプリケーションプログラミングインターフェース(API)に対する入力データを取得することと、
前記APIに対する前記入力データを前記APIのプロバイダの公開鍵を使用して暗号化することと、
通信コンポーネントに、前記APIを呼び出すAPIリクエストをAPI管理サーバに送信するように指示することであり、前記APIリクエストは、前記APIに対するAPIコールと前記暗号化された入力データとを含み、前記APIリクエストは、前記API管理サーバが前記APIコールに基づきAPI管理サービスを実行できるが前記暗号化された入力データを前記公開鍵で復号できないフォーマットである、ことと、
を含む、1つ以上のコンピュータ読取可能媒体。
(付記9)
前記動作は、前記API管理サーバから前記APIリクエストに対するレスポンスを受信することであり、前記APIリクエストに対する前記レスポンスは、前記入力データに基づく前記APIの出力を含み、前記出力は、クライアントの公開鍵を使用して前記APIプロバイダにより暗号化される、ことをさらに含む、付記8に記載の1つ以上のコンピュータ読取可能媒体。
(付記10)
前記動作は、前記APIリクエストに対する前記レスポンスを前記クライアントの秘密鍵を使用して復号することをさらに含む、付記9に記載の1つ以上のコンピュータ読取可能媒体。
(付記11)
前記APIリクエストは、クライアント識別子とAPIプロバイダ識別子とAPI管理承認構造とを含む暗号化されていないデータコンポーネントを含む、付記8に記載の1つ以上のコンピュータ読取可能媒体。
(付記12)
前記動作は、クライアントデータを前記APIリクエストの一部であるように暗号化することをさらに含む、付記8に記載の1つ以上のコンピュータ読取可能媒体。
(付記13)
前記プロバイダの前記公開鍵は、前記APIリクエストを生成するコンピュータプログラム内に埋め込まれ、それにより、前記入力データの前記暗号化はユーザ入力なしに生じる、付記8に記載の1つ以上のコンピュータ読取可能媒体。
(付記14)
前記API管理サービスは、トラフィック制御、管理ポリシー実施、及びセキュリティポリシー実施のうち少なくとも1つを含む、付記8に記載の1つ以上のコンピュータ読取可能媒体。
(付記15)
システムであって、
1つ以上のプロセッサと、
前記1つ以上のプロセッサにより実行されることに応答して当該システムに動作を実行させる命令を含む1つ以上の非一時的コンピュータ読取可能媒体と、
を含み、前記動作は、
アプリケーションプログラミングインターフェース(API)に対する入力データを取得することと、
前記APIに対する前記入力データを前記APIのプロバイダの公開鍵を使用して暗号化することと、
通信コンポーネントに、前記APIを呼び出すAPIリクエストをAPI管理サーバに送信するように指示することであり、前記APIリクエストは、前記APIに対するAPIコールと前記暗号化された入力データとを含み、前記APIリクエストは、前記API管理サーバが前記APIコールに基づきAPI管理サービスを実行できるが前記暗号化された入力データを前記公開鍵で復号できないフォーマットである、ことと、
を含む、システム。
(付記16)
前記動作は、前記API管理サーバから前記APIリクエストに対するレスポンスを受信することであり、前記APIリクエストに対する前記レスポンスは、前記入力データに基づく前記APIの出力を含み、前記出力は、クライアントの公開鍵を使用して前記APIプロバイダにより暗号化される、ことをさらに含む、付記15に記載のシステム。
(付記17)
前記動作は、前記APIリクエストに対する前記レスポンスを前記クライアントの秘密鍵を使用して復号することをさらに含む、付記16に記載のシステム。
(付記18)
前記APIリクエストは、クライアント識別子とAPIプロバイダ識別子とAPI管理承認構造とを含む暗号化されていないデータコンポーネントをさらに含む、付記15に記載のシステム。
(付記19)
前記動作は、開発者データを前記APIリクエストの一部であるように暗号化することであり、前記開発者データは、前記入力データを取得する前に開発者により提供される、ことをさらに含む、付記15に記載のシステム。
(付記20)
前記プロバイダの前記公開鍵は、前記APIリクエストを生成するコンピュータプログラム内に埋め込まれ、それにより、前記入力データの前記暗号化はユーザ入力なしに生じる、付記15に記載のシステム。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ