JP2018133022A - Ａｐｉ提供装置及びａｐｉ使用権委譲の同意方法 - Google Patents

Abstract

【課題】ＡＰＩ使用権委譲の同意に係るユーザの負担を改善し、ＡＰＩ卸元事業者のＡＰＩ提供装置を隠ぺいする。【解決手段】上位ＡＰＩ提供装置５は、ＡＰＩの使用権を委譲することに同意したユーザの同意情報に基づき、下位ＡＰＩ提供装置７から該ユーザへのＡＰＩ使用権委譲の同意要求に対して同意を示す同意情報を送信する疑似ユーザ機能を備える。【選択図】図１

Description

本発明は、ＡＰＩ使用権委譲の同意応答やユーザのアカウントを管理する技術に関する。

クライアントアプリケーションがＷｅｂ−ＡＰＩ（Web Application Programming Interface）を利用する際、ＡＰＩ提供装置とのＡＰＩ利用認証を行う技術として、非特許文献１，２がある。

"OAth 2.0"、［online］、［平成29年2月6日検索］、＜URL: https://oauth.net/2/＞ "The OAuth 2.0 Authorization Framework，4.1. Authorization Code Grant"、［online］、［平成29年2月13日検索］、＜URL: https://tools.ietf.org/html/rfc6749#section-4.1＞

ＡＰＩの再販を行うビジネスモデルの場合、複数のＡＰＩ提供装置が多段に接続される。このとき、ＡＰＩ利用認証において、複数のＡＰＩ提供装置がエンドユーザに対してＡＰＩ使用権委譲の同意をそれぞれ要求するため、エンドユーザは複数の同意要求に対して応答する必要があり、クライアントアプリケーション利用の利便性に欠けるという課題がある。また、その同意要求がＡＰＩ卸元事業者のＡＰＩ提供装置からエンドユーザに直接送信されるため、ＡＰＩ卸元事業者をユーザやクライアントに隠ぺいしたいという要件を満たすことができない。

本発明は、上記事情を鑑みてなされたものであり、ＡＰＩ使用権委譲の同意に係るユーザの負担を改善し、ＡＰＩ卸元事業者のＡＰＩ提供装置を隠ぺいすることを目的とする。

以上の課題を解決するため、請求項１に係るＡＰＩ提供装置は、ＡＰＩの使用権を委譲することに同意したユーザの同意情報に基づき、他のＡＰＩ提供装置から前記ユーザへのＡＰＩ使用権委譲の同意要求に対して同意を示す同意情報を送信する応答部を備えることを特徴とする。

請求項２に係るＡＰＩ提供装置は、請求項１に記載のＡＰＩ提供装置において、自ＡＰＩ提供装置の利用者と前記他のＡＰＩ提供装置の利用者がそれぞれ前記ユーザに発行したユーザの識別情報を関連付けて記憶する記憶部を更に備えることを特徴とする。

請求項３に係るＡＰＩ使用権委譲の同意方法は、ＡＰＩ提供装置で行うＡＰＩ使用権委譲の同意方法において、前記ＡＰＩ提供装置が、ＡＰＩの使用権を委譲することに同意したユーザの同意情報に基づき、他のＡＰＩ提供装置から前記ユーザへのＡＰＩ使用権委譲の同意要求に対して同意を示す同意情報を送信するステップを行うことを特徴とする。

請求項４に係るＡＰＩ使用権委譲の同意方法は、請求項３に記載のＡＰＩ使用権委譲の同意方法において、前記ステップを行う前に、自ＡＰＩ提供装置の利用者と前記他のＡＰＩ提供装置の利用者がそれぞれ前記ユーザに発行したユーザの識別情報を関連付けて記憶部に記憶するステップを行うことを特徴とする。

本発明によれば、ＡＰＩ使用権委譲の同意に係るユーザの負担を軽減し、ＡＰＩ卸元事業者のＡＰＩ提供装置を隠ぺいすることができる。

システム構成を示す図である。 システム全体の処理シーケンスを示す図である。 ＡＰＩリクエスト処理部１１の処理フローを示す図である。 認可リクエスト検証部１３の処理フローを示す図である。 ユーザ認証部１４の処理フローを示す図である。 ＡＰＩリクエスト生成部１５の処理フローを示す図である。 ＡＰＩレスポンス処理部１６の処理フローを示す図である。 ユーザ認証応答部１７の処理フローを示す図である。 認可コード発行部１８の処理フローを示す図である。 ＡＰＩレスポンス生成部１２の処理フローを示す図である。 トークンリクエスト検証部１９の処理フローを示す図である。 アクセストークン発行部２０の処理フローを示す図である。 アクセストークン検証部２１の処理フローを示す図である。 アクセストークン変換部２２の処理フローを示す図である。 ユーザ認証情報の例を示す図である。 アクセストークンの例を示す図である。 認可コードの例を示す図である。 本実施の形態と従来例との概説図である。

上記課題を解決するため、本発明は、多段接続された複数のＡＰＩ提供装置において、ＡＰＩ卸売事業者のＡＰＩ提供装置（上位ＡＰＩ提供装置）に疑似ユーザ機能を具備する。そして、その疑似ユーザ機能で、ＡＰＩ卸元事業者のＡＰＩ提供装置（下位ＡＰＩ提供装置）からユーザへのＡＰＩ使用権委譲の同意要求に対し、ＡＰＩ使用権の委譲に同意したユーザの同意情報に基づき、ユーザに代わりユーザの同意を自ら代理応答する。これにより、ＡＰＩ使用権委譲の同意に係るユーザの負担を軽減し、ＡＰＩ卸元事業者のＡＰＩ提供装置を隠ぺいしつつＡＰＩを提供することができる。以下、本発明を実施する一実施の形態について図面を用いて説明する。

本実施の形態に係るシステム構成を図１に示す。このシステム構成では、エンドユーザ利用端末１と、ＡＰＩ利用装置３と、上位ＡＰＩ提供装置５と、下位ＡＰＩ提供装置７と、リソースサーバ９と、を備えて構成される。図１に示したＡＰＩ提供装置の接続構成は２段の例であり、例えば３段以上を多段接続してもよい。

エンドユーザ利用端末１は、例えば携帯電話やスマートフォンなど、リソースサーバ９などで提供されるサービスをクライアント側で実行するための装置である。また、ＡＰＩ利用装置３は、そのサービスをクライアント側で実行するアプリケーション又はその装置である。そのアプリケーションをエンドユーザ利用端末１の内部で実行してもよい。

上位ＡＰＩ提供装置５は、サービスに係るソフトウェアの機能をＡＰＩとして提供する装置であり、ＡＰＩ提供前にエンドユーザに対してＡＰＩ使用権委譲の同意を要求する「同意要求機能」、エンドユーザからの同意を受信済であれば下位ＡＰＩ提供装置７からエンドユーザへのＡＰＩ使用権委譲の同意要求に対してユーザの同意を代理応答する「疑似ユーザ機能」などを備える。本実施の形態において上位ＡＰＩ提供装置５はＡＰＩ卸売事業者により利用される。

一方、下位ＡＰＩ提供装置７は、ＡＰＩ卸元事業者により利用され、上記同意要求機能などを備える。下位ＡＰＩ提供装置７は、基本的には従来のＡＰＩ提供装置であり、その一方で上位ＡＰＩ提供装置５は、従来のＡＰＩ提供装置に対して上記「疑似ユーザ機能」を追加して構成されている。

また、上位ＡＰＩ提供装置５は、下位ＡＰＩ提供装置７に対してユーザの同意を代理応答するにあたり、下位ＡＰＩ提供装置７へログインを行う必要がある。そこで、下位ＡＰＩ提供装置７がエンドユーザに対して発行したユーザＩＤ及びパスワードを保持・管理する「ユーザアカウント管理機能」を更に備える。

上位ＡＰＩ提供装置５の構成例について説明する。本実施の形態において、上位ＡＰＩ提供装置５は、図１に示したように、ＡＰＩリクエスト処理部１１と、ＡＰＩレスポンス生成部１２と、認可リクエスト検証部１３と、ユーザ認証部１４と、ＡＰＩリクエスト生成部１５と、ＡＰＩレスポンス処理部１６と、ユーザ認証応答部１７と、認可コード発行部１８と、トークンリクエスト検証部１９と、アクセストークン発行部２０と、アクセストークン検証部２１と、アクセストークン変換部２２と、ユーザ認証情報記憶部２３と、認可コード記憶部２４と、アクセストークン記憶部２５と、を備えて構成される。

図１では、従来のＡＰＩ提供装置に対する追加機能部に斜めハッチを施している。上述した「疑似ユーザ機能」は、ＡＰＩリクエスト生成部１５と、ＡＰＩレスポンス処理部１６と、ユーザ認証応答部１７と、で構成される。また、上述した「ユーザアカウント管理機能」は、ユーザ認証情報記憶部２３で構成される。これら４つの機能部が互いに連携して動作することにより、下位ＡＰＩ提供装置７に対してログイン処理及びユーザ同意の代理応答処理を実行する。

また、これら４つの機能部と後述するアクセストークン変換部２２を除く他の全ての機能部は、従来のＡＰＩ提供装置が備える機能部であり、「OAuth 2.0」などで規定された認可サーバとして機能する。この認可サーバについては非特許文献１，２に詳しいが、簡易には、リソース利用の認証と認可の取得が成功した後にトークン（クライアントに対して発行されたアクセス認可を表す文字列であり、リソース側で認可された権限の範囲とアクセス期間を示す）を発行するサーバである。但し、本実施の形態では、「疑似ユーザ機能」でユーザの代理応答を行うため、ＡＰＩリクエストに含まれるトークンを下位ＡＰＩ提供装置７が発行したトークンに変換する必要がある。そこで、上位ＡＰＩ提供装置５は、トークンを変換する「トークン変換機能」も更に備える。この「トークン変換機能」は、アクセストークン変換部２２で構成される。

下位ＡＰＩ提供装置７は、認可サーバとして機能する従来のＡＰＩ提供装置である。具体的には、下位ＡＰＩ提供装置７は、図１に示した上位ＡＰＩ提供装置５から、ＡＰＩリクエスト生成部１５と、ＡＰＩレスポンス処理部１６と、ユーザ認証応答部１７と、ユーザ認証情報記憶部２３と、アクセストークン変換部２２と、を除く機能部により構成される。

リソースサーバ９は、所定のサービスを提供するサーバである。

次に、上位ＡＰＩ提供装置５の動作について説明する。

まず、その動作を概説する。上位ＡＰＩ提供装置５がＡＰＩ利用装置３（クライアント）からのＡＰＩ利用リクエストを受信すると、ＡＰＩ使用権委譲の同意をユーザに要求する。ユーザの承諾後、上位ＡＰＩ提供装置５から下位ＡＰＩ提供装置７へＡＰＩ利用リクエストを送信する。その後、ＡＰＩ使用権委譲の同意が下位ＡＰＩ提供装置から上位ＡＰＩ提供装置へ要求されるが、ユーザの同意を既に受信しているので、上位ＡＰＩ提供装置５の疑似ユーザ機能が保存済のユーザ認証情報を利用して同意に自動応答し、認証プロセスを通過する。

続いて、その動作を詳述する。図２は、システム全体の処理シーケンスである。図３〜図１４は、上位ＡＰＩ提供装置５を構成する各機能部の処理フローを示す図である。図１５〜図１７は、本処理シーケンスで用いる各種データの例を示す図である。

なお、予めユーザとＡＰＩ卸売事業者とＡＰＩ卸元事業者との間で、「ＡＰＩ使用権委譲について、ユーザが上位ＡＰＩ提供装置５からの同意要求に対して同意を承諾したことを以て、下位ＡＰＩ提供装置７からの同意要求も承諾したとみなす」ことが成立しているものとする。

また、上位ＡＰＩ提供装置５は、予め下位ＡＰＩ提供装置７へユーザ登録を行い、払い出されたユーザ認証情報（ユーザＩＤ及びパスワード）を保存及び管理を行っているものとする。具体的には、上位ＡＰＩ提供装置５のユーザ認証情報記憶部２３が、上位ＡＰＩ提供装置５のＡＰＩ卸売事業者がエンドユーザに既に発行したユーザＩＤをキーに、下位ＡＰＩ提供装置７のＡＰＩ卸元事業者が上位ＡＰＩ提供装置５（＝疑似エンドユーザ）に発行したユーザＩＤ及びパスワードを関連付けて記憶する（後述する図１５を参照）。

まず、図２に示すように、エンドユーザが上位ＡＰＩ提供装置５でクライアントアプリの利用を開始すると、ＡＰＩのアクセスに係る認可リクエストがエンドユーザ利用端末１を介してＡＰＩ利用装置３から上位ＡＰＩ提供装置５へ送信される。

次に、上位ＡＰＩ提供装置５は、図２のステップＡの処理を実行する。図３（ａ）に示すように、ＡＰＩリクエスト処理部１１は、ＡＰＩ利用装置３よりリダイレクトされたエンドユーザ利用端末１からの認可リクエストを受信し（ステップＡ１）、認可リクエスト検証部１３へ該認可リクエストを送信する（ステップＡ２）。

次に、上位ＡＰＩ提供装置５は、図２のステップＢ，Ｃの処理を実行する。図４に示すように、認可リクエスト検証部１３は、ＡＰＩリクエスト処理部１１から認可リクエストを受信し（ステップＢ１）、その認可リクエストに含まれるパラメータが規定に合致しているか否かを判定する（ステップＢ２）。その後、そのパラメータが規定に合致している場合、ユーザ認証部１４へユーザ認証開始信号を送信する（ステップＢ３）。一方、そのパラメータが規定に合致しない場合、エラー信号を生成してＡＰＩ利用装置３へ送信する（ステップＢ４）。以降、ユーザ認証部１４へユーザ認証開始信号を送信したものとする。

その後、図５に示すように、ユーザ認証部１４は、認可リクエスト検証部１３からユーザ認証開始信号を受信し（ステップＣ１）、エンドユーザ利用端末１へユーザ認証画面及びＡＰＩ使用権委譲の同意画面の画面データを送信する（ステップＣ２）。そして、エンドユーザ利用端末１からユーザ認証情報及びＡＰＩ使用権委譲の同意に対する認可又は拒否の応答を受信し（ステップＣ３）、受信した応答に基づき、ユーザ認証が成功し、かつ、ＡＰＩ使用権委譲の同意が認可されたかを判定する（ステップＣ４）。ユーザ認証が成功し、かつ、ＡＰＩ使用権委譲の同意が認可された場合、ＡＰＩリクエスト生成部１５へ認可リクエスト開始信号を送信する（ステップＣ５）。一方、ユーザ認証が成功しない場合、又は、ＡＰＩ使用権委譲の同意が認可されていない場合、エラー信号を生成してＡＰＩ利用装置３へ送信する（ステップＣ６）。

以降、ＡＰＩリクエスト生成部１５へ認可リクエスト開始信号を送信したものとする。なお、上位ＡＰＩ提供装置５は、ユーザ認証結果やユーザによるＡＰＩ使用権委譲への同意応答など、エンドユーザ利用端末１、ＡＰＩ利用装置３又は下位ＡＰＩ提供装置７との間でやりとりされた全てのデータをメモリやハードディスクなどに随時保存しておく。

次に、上位ＡＰＩ提供装置５は、図２のステップＤの処理を実行する。図６（ａ）に示すように、ＡＰＩリクエスト生成部１５は、ユーザ認証部１４から認可リクエスト開始信号を受信し（ステップＤ１）、その認可リクエストをＡＰＩ卸元事業者の下位ＡＰＩ提供装置７へ送信する（ステップＤ２）。

次に、上位ＡＰＩ提供装置５は、図２のステップＥ，Ｆ，Ｇの処理を実行する。図７（ａ）に示すように、ＡＰＩレスポンス処理部１６は、ＡＰＩ卸元事業者の下位ＡＰＩ提供装置７からユーザ認証画面及びＡＰＩ使用権委譲の同意画面の画面データを受信し（ステップＥ１）、ユーザ認証応答部１７に該画面データを送信する（ステップＥ２）。

その後、図８に示すように、ユーザ認証応答部１７は、ＡＰＩレスポンス処理部１６からユーザ認証画面及びＡＰＩ使用権委譲の同意画面の画面データを受信し（ステップＦ１）、ユーザ認証情報記憶部２３に認証情報を問い合わせる（ステップＦ２）。そして、ユーザ認証及びＡＰＩ使用権委譲の同意に応答する伝文を組み立て、ＡＰＩリクエスト生成部１５に送信する（ステップＦ３）。

その後、図６（ｂ）に示すように、ＡＰＩリクエスト生成部１５は、ユーザ認証応答部１７からユーザ認証及びＡＰＩ使用権委譲の同意に応答する伝文を受信し（ステップＧ１）、ユーザ同意応答をＡＰＩ卸元事業者の下位ＡＰＩ提供装置７へ送信する（ステップＧ２）。

ここで、ステップＦ，Ｇの動作を詳述する。ユーザは、予め下位ＡＰＩ提供装置７からのＡＰＩ使用権委譲の同意要求に対して同意承諾を擬制し、また、既に上位ＡＰＩ提供装置５に対してＡＰＩ使用権の委譲に同意を示している。それゆえ、ユーザ認証応答部１７は、そのユーザの同意に基づき、下位ＡＰＩ提供装置７へのログイン及びユーザ同意処理を自動で開始する。具体的には、ユーザ認証情報記憶部２３（図１５参照）から、対象ユーザのユーザＩＤ（上位ＡＰＩ提供装置５が発行したユーザＩＤ）に対応する、下位ＡＰＩ提供装置７のＡＰＩ卸元事業者が発行したユーザＩＤ及びパスワードを取得し、そのユーザＩＤ及びパスワードとユーザの同意を示す同意情報とに基づき下位ＡＰＩ提供装置７へのログイン処理及び同意処理を実行する。

次に、上位ＡＰＩ提供装置５は、図２のステップＨの処理を実行する。図７（ｂ）に示すように、ＡＰＩレスポンス処理部１６は、ＡＰＩ卸元事業者の下位ＡＰＩ提供装置７から認可レスポンスを受信し（ステップＨ１）、その認可レスポンス内の認可コード（Ｂ）をＡＰＩリクエスト生成部１５に送信する（ステップＨ２）。

次に、上位ＡＰＩ提供装置５は、図２のステップＩの処理を実行する。図６（ｃ）に示すように、ＡＰＩリクエスト生成部１５は、ＡＰＩレスポンス処理部１６から認可コード（Ｂ）を受信し（ステップＩ１）、その認可コード（Ｂ）を含めたトークンリクエストをＡＰＩ卸元事業者の下位ＡＰＩ提供装置７へ送信する（ステップＩ２）。

次に、上位ＡＰＩ提供装置５は、図２のステップＪ，Ｋ，Ｌの処理を実行する。図７（ｃ）に示すように、ＡＰＩレスポンス処理部１６は、ＡＰＩ卸元事業者の下位ＡＰＩ提供装置７からトークンレスポンスを受信し（ステップＪ１）、そのトークンレスポンスに含まれるアクセストークン（Ｂ）をアクセストークン記憶部２５（図１６参照）に格納し（ステップＪ２）、認可コード発行部１８へ認可レスポンス開始信号を送信する（ステップＪ３）。

その後、図９に示すように、認可コード発行部１８は、ＡＰＩレスポンス処理部１６から認可レスポンス開始信号を受信し（ステップＫ１）、認可コード（Ａ）を発行して認可コード記憶部２４（図１７参照）に格納する（ステップＫ２）。そして、その認可コード（Ａ）をＡＰＩレスポンス生成部１２に送信する（ステップＫ３）。

その後、図１０（ａ）に示すように、ＡＰＩレスポンス生成部１２は、認可コード発行部１８から認可コード（Ａ）を受信し（ステップＬ１）、エンドユーザ利用端末１へ該認可コード（Ａ）を含む認可レスポンスを送信する（ステップＬ２）。この認可レスポンスは、ＡＰＩ利用装置３へリダイレクトされる。

次に、上位ＡＰＩ提供装置５は、図２のステップＭ，Ｎ，Ｏ，Ｐの処理を実行する。図３（ｂ）に示すように、ＡＰＩリクエスト処理部１１は、ＡＰＩ利用装置３から認可コード（Ａ）を含むトークンリクエストを受信し（ステップＭ１）、そのトークンリクエストをトークンリクエスト検証部１９へ送信する（ステップＭ２）。

その後、図１１に示すように、トークンリクエスト検証部１９は、ＡＰＩリクエスト処理部１１からトークンリクエストを受信し（ステップＮ１）、そのトークンリクエストに含まれるパラメータが規定に合致しているか否かを判定する（ステップＮ２）。そして、そのパラメータが規定に合致している場合、アクセストークン発行部２０へトークン発行信号を送信する（ステップＮ３）。一方、そのパラメータが規定に合致しない場合、エラー信号を生成してＡＰＩ利用装置３へ送信する（ステップＮ４）。以降、アクセストークン発行部２０へトークン発行信号を送信したものとする。

その後、図１２に示すように、アクセストークン発行部２０は、トークンリクエスト検証部１９からトークン発行信号を受信し（ステップＯ１）、アクセストークン（Ａ）を発行してアクセストークン記憶部２５に格納する（ステップＯ２）。そして、そのアクセストークン（Ａ）をＡＰＩレスポンス生成部１２に送信する（ステップＯ３）。

その後、図１０（ｂ）に示すように、ＡＰＩレスポンス生成部１２は、アクセストークン発行部２０からアクセストークン（Ａ）を受信し（ステップＰ１）、ＡＰＩ利用装置３へ該アクセストークン（Ａ）を含むトークンレスポンスを送信する（ステップＰ２）。

次に、上位ＡＰＩ提供装置５は、図２のステップＱ，Ｒ，Ｓの処理を実行する。図３（ｃ）に示すように、ＡＰＩリクエスト処理部１１は、ＡＰＩ利用装置３からアクセストークン（Ａ）を含むＡＰＩリクエストを受信し（ステップＱ１）、アクセストークン検証部２１へ該ＡＰＩリクエストを送信する（ステップＱ２）。

その後、図１３に示すように、アクセストークン検証部２１は、ＡＰＩリクエスト処理部１１からＡＰＩリクエストを受信し（ステップＲ１）、そのＡＰＩリクエストに含まれるアクセストークン（Ａ）がアクセストークン記憶部２５のアクセストークンに合致するか否かを確認し（ステップＲ２）、ＡＰＩリクエストのパラメータが規定に合致しているか否かを判定する（ステップＲ３）。そして、アクセストークンが合致し、かつ、パラメータが規定に合致している場合、アクセストークン変換部２２へＡＰＩリクエストを送信する（ステップＲ４）。一方、アクセストークンが合致しない場合、又は、パラメータが規定に合致しない場合、エラー信号を生成してＡＰＩ利用装置３へ送信する（ステップＲ５）。以降、アクセストークン変換部２２へＡＰＩリクエストを送信したものとする。

その後、図１４に示すように、アクセストークン変換部２２は、アクセストークン検証部２１からアクセストークン（Ａ）を含むアクセストークンＡＰＩリクエストを受信し（ステップＳ１）、アクセストークン記憶部２５へＡＰＩ卸元事業者の下位ＡＰＩ提供装置７から受信したアクセストークン（Ｂ）を問い合わせて取得する（ステップＳ２）。そして、ＡＰＩリクエスト内のアクセストークン（Ａ）をアクセストークン（Ｂ）に変換し（ステップＳ３）、ＡＰＩ卸元事業者の下位ＡＰＩ提供装置７へ変換後のＡＰＩリクエストを送信する（ステップＳ４）。

最後に、上位ＡＰＩ提供装置５は、図２のステップＴの処理を実行する。図１０（ｃ）に示すように、ＡＰＩレスポンス生成部１２は、ＡＰＩ卸元事業者の下位ＡＰＩ提供装置７からＡＰＩレスポンスを受信し（ステップＴ１）、ＡＰＩ利用装置３へ該ＡＰＩレスポンスを送信する（ステップＴ２）。

以上より、本実施の形態によれば、ＡＰＩ卸売事業者の上位ＡＰＩ提供装置５が、ＡＰＩ卸元事業者の下位ＡＰＩ提供装置７からのＡＰＩ使用権委譲の同意要求に対してユーザの同意（同意情報）を代理応答するので、ユーザは複数のＡＰＩ提供装置からの各同意要求に応答不要となり、ＡＰＩ使用権委譲の同意に係るユーザの負担を軽減し、ユーザやクライアントに対してＡＰＩ卸元事業者を隠ぺいすることができる（図１８参照）。

最後に、本実施の形態で説明した上位ＡＰＩ提供装置５は、コンピュータで実現できる。また、上位ＡＰＩ提供装置５としてコンピュータを機能させるためのＡＰＩ提供プログラム、そのＡＰＩ提供プログラムの記憶媒体を作成することも可能である。

１…エンドユーザ利用端末
３…ＡＰＩ利用装置
５…上位ＡＰＩ提供装置
７…下位ＡＰＩ提供装置
９…リソースサーバ
１１…ＡＰＩリクエスト処理部
１２…ＡＰＩレスポンス生成部
１３…認可リクエスト検証部
１４…ユーザ認証部
１５…ＡＰＩリクエスト生成部
１６…ＡＰＩレスポンス処理部
１７…ユーザ認証応答部
１８…認可コード発行部
１９…トークンリクエスト検証部
２０…アクセストークン発行部
２１…アクセストークン検証部
２２…アクセストークン変換部
２３…ユーザ認証情報記憶部
２４…認可コード記憶部
２５…アクセストークン記憶部

Claims (4)

1. ＡＰＩ（Application Programming Interface）の使用権を委譲することに同意したユーザの同意情報に基づき、他のＡＰＩ提供装置から前記ユーザへのＡＰＩ使用権委譲の同意要求に対して同意を示す同意情報を送信する応答部、
   を備えることを特徴とするＡＰＩ提供装置。
2. 自ＡＰＩ提供装置の利用者と前記他のＡＰＩ提供装置の利用者がそれぞれ前記ユーザに発行したユーザの識別情報を関連付けて記憶する記憶部、
   を更に備えることを特徴とする請求項１に記載のＡＰＩ提供装置。
3. ＡＰＩ提供装置で行うＡＰＩ使用権委譲の同意方法において、
   前記ＡＰＩ提供装置が、
   ＡＰＩ（Application Programming Interface）の使用権を委譲することに同意したユーザの同意情報に基づき、他のＡＰＩ提供装置から前記ユーザへのＡＰＩ使用権委譲の同意要求に対して同意を示す同意情報を送信するステップ、
   を行うことを特徴とするＡＰＩ使用権委譲の同意方法。
4. 前記ステップを行う前に、自ＡＰＩ提供装置の利用者と前記他のＡＰＩ提供装置の利用者がそれぞれ前記ユーザに発行したユーザの識別情報を関連付けて記憶部に記憶するステップ、
   を行うことを特徴とする請求項３に記載のＡＰＩ使用権委譲の同意方法。

Images