JP6825473B2 - アクセス制御装置、アクセス制御プログラム及びアクセス制御方法 - Google Patents

Description

本発明は、ネットワークを介した機能呼び出しの技術に関する。

ブラウザと連携するＷｅｂアプリケーションがＷｅｂ ＡＰＩ（Application Programming Interface）を利用する場合、ＷｅｂアプリケーションがＷｅｂ ＡＰＩを利用する権限についてユーザに認可を受けることが前提となる。具体的には、Ｗｅｂ ＡＰＩが提供する同意画面をブラウザに表示させ、ユーザによる認可の操作を受け付けるようにする。

このように、ＷｅｂアプリケーションがＷｅｂ ＡＰＩを利用する形態において、Ｗｅｂアプリケーションに利用される一次のＷｅｂ ＡＰＩが、更に二次のＷｅｂ ＡＰＩを利用すれば、より高度な機能が実現できると考えられる。

但し、一次のＷｅｂ ＡＰＩが二次のＷｅｂ ＡＰＩを利用する権限を適正に得られるようにしなければ、安全性が損なわれる。尚、Ｗｅｂ ＡＰＩは、ネットワークを介して提供される機能の例である。

特開２０１６−０７１５６１号公報

本発明の目的は、一側面では、ネットワークを介して提供する第１機能において、ネットワークを介して提供される第２機能を、より安全に利用できるようにすることである。

一態様に係るアクセス制御装置は、（Ａ）ネットワークを介して提供する第１機能に関する第１インターフェースへのアクセスを受信する受信部と、（Ｂ）上記アクセスを受信した場合に、ネットワークを介して提供される第２機能に関する第２インターフェースを利用する権限に関する認可要求を、上記アクセスの送信元プログラムと連携するブラウザ宛に転送させる指示を、当該送信元プログラムへ送信する送信部とを有する。

一側面としては、ネットワークを介して提供する第１機能において、ネットワークを介して提供される第２機能を、より安全に利用できるようになる。

図１は、ネットワーク構成例を示す図である。 図２は、一次認可及び一次ＡＰＩ呼び出しの概要を示す図である。 図３は、一次同意画面の例を示す図である。 図４は、二次認可における課題を示す図である。 図５は、二次認可及び二次ＡＰＩ呼び出しの概要を示す図である。 図６は、二次同意画面の例を示す図である。 図７は、アクセストークンの紐付けの概要を示す図である。 図８は、アプリケーション部のモジュール構成例を示す図である。 図９は、第１機能提供部のモジュール構成例を示す図である。 図１０は、一次認可のシーケンス例を示す図である。 図１１は、一次認可のシーケンス例を示す図である。 図１２は、一次認可のシーケンス例を示す図である。 図１３は、一次認可及び一次ＡＰＩ呼び出しのシーケンス例を示す図である。 図１４は、二次認可のシーケンス例を示す図である。 図１５は、紐付けテーブルの例を示す図である。 図１６は、第２機能提供部のモジュール構成例を示す図である。 図１７は、二次認可のシーケンス例を示す図である。 図１８は、二次認可のシーケンス例を示す図である。 図１９は、二次認可及び二次ＡＰＩ呼び出しのシーケンス例を示す図である。 図２０は、二次ＡＰＩ呼び出し以降のシーケンス例を示す図である。 図２１は、一次ＡＰＩ呼び出し及び二次ＡＰＩ呼び出しのシーケンス例を示す図である。 図２２は、実施の形態２における一次認可のシーケンス例を示す図である。 図２３は、実施の形態２における一次認可及び一次ＡＰＩ呼び出しのシーケンス例を示す図である。 図２４は、実施の形態２における二次認可のシーケンス例を示す図である。 図２５は、実施の形態２における二次認可及び二次ＡＰＩ呼び出しのシーケンス例を示す図である。 図２６は、ネットワーク構成例を示す図である。 図２７は、コンピュータの機能ブロック図である。

図１に、ネットワーク構成例を示す。ユーザ端末１０１は、ブラウザ１０３を有し、インターネットに接続する機能を有している。Ｗｅｂサーバ１０５ａは、インターネットに接続している。Ｗｅｂサーバ１０５ａは、Ｗｅｂアプリケーション＿Ａ１０７を有する。この例におけるＷｅｂアプリケーション＿Ａ１０７は、ブラウザ１０３からのリクエストに応じてＨＴＭＬ（HyperText Markup Language）ファイルを提供する。尚、Ｗｅｂアプリケーション＿Ａ１０７は、ブラウザ１０３と連携するアプリケーションプログラムの例である。

Ｗｅｂサーバ１０５ｂは、Ｗｅｂ ＡＰＩ＿Ｘ１０９を有する。この例において、Ｗｅｂ ＡＰＩ＿Ｘ１０９は、Ｗｅｂアプリケーション＿Ａ１０７に呼び出され、所定の機能に係るサービスをＷｅｂアプリケーション＿Ａ１０７に提供するものとする。Ｗｅｂサーバ１０５ｃは、Ｗｅｂ ＡＰＩ＿Ｙ１１１を有する。この例において、Ｗｅｂ ＡＰＩ＿Ｙ１１１は、Ｗｅｂ ＡＰＩ＿Ｘ１０９に呼び出され、所定の機能に係るサービスをＷｅｂ ＡＰＩ＿Ｘ１０９に提供するものとする。

図２に、一次認可及び一次ＡＰＩ呼び出しの概要を示す。この例で、Ｗｅｂアプリケーション＿Ａ１０７がＷｅｂ ＡＰＩ＿Ｘ１０９を利用するための権限について、ユーザから受ける認可を一次認可という。また、一次認可に基づくＷｅｂ ＡＰＩ＿Ｘ１０９の呼び出しを、一次ＡＰＩ呼び出しという。尚、以下では、一次認可に係るエンティティ、プログラム、処理、画面、データ及びパラメータ等について、「一次」の語句を付して、後述する二次認可に係るエンティティ、プログラム、処理、画面、データ及びパラメータ等と区別する。

この例における一次認可の手順は、ＯＡｕｔｈに準拠する。ＯＡｕｔｈは、権限の認可を行う手順に係るオープンスタンダードである。この例におけるプログラムをＯＡｕｔｈにおけるエンティティに当てはめる。ブラウザ１０３は、一次認可におけるリソースオーナー（つまり、一次リソースオーナー）である。リソースオーナーは、保護リソースに対するアクセス権限に関するユーザの同意を直接的に受け付ける。Ｗｅｂアプリケーション＿Ａ１０７は、一次認可におけるクライアント（つまり、一次クライアント）である。クライアントは、アクセス権限が与えられた場合に保護リソースを利用する。Ｗｅｂ ＡＰＩ＿Ｘ１０９は、一次認可における許可サーバ（つまり、一次許可サーバ）である。許可サーバは、ユーザの同意を取り付けて、保護リソースにアクセスするためのトークン（アクセストークン）を発行する。Ｗｅｂ ＡＰＩ＿Ｘ１０９は、更に一次認可におけるリソースサーバ（つまり、一次リソースサーバ）である。リソースサーバは、保護リソースを管理する。

最初に、Ｗｅｂ ＡＰＩ＿Ｘ１０９を利用しようとするＷｅｂアプリケーション＿Ａ１０７は、一次認可要求をブラウザ１０３へ送る（Ｓ２０１）。次に、ブラウザ１０３とＷｅｂ ＡＰＩ＿Ｘ１０９との間における一次認可の手続きを経て（Ｓ２０３）、Ｗｅｂ ＡＰＩ＿Ｘ１０９は一次認可を受け付ける。尚、一次認可の手続きにおいて、ブラウザ１０３に一次同意画面が表示される。

図３に、一次同意画面の例を示す。「ＡＡＡ」は、Ｗｅｂアプリケーション＿Ａ１０７の名前である。「ＸＸＸ」は、Ｗｅｂ ＡＰＩ＿Ｘ１０９の名前である。図３に示したように、一次クライアントが一次リソースサーバを呼び出すことについての同意を確認する内容のコメントが表示される。「認可する」と表示された認可ボタンが選択されると、Ｗｅｂアプリケーション＿Ａ１０７によるＷｅｂ ＡＰＩ＿Ｘ１０９の呼び出しをユーザが認可したことになる。一方、「拒否する」と表示された拒否ボタンが選択されると、Ｗｅｂアプリケーション＿Ａ１０７によるＷｅｂ ＡＰＩ＿Ｘ１０９の呼び出しをユーザが拒否したことになる。

図２の説明に戻る。Ｗｅｂ ＡＰＩ＿Ｘ１０９が一次認可を受け付けると、Ｗｅｂ ＡＰＩ＿Ｘ１０９は一次アクセストークンを発行し、当該一次アクセストークンはＷｅｂアプリケーション＿Ａ１０７に引き渡される。本実施の形態では、ＯＡｕｔｈにおける認可コードグラント方式によって一次アクセストークンが発行される例について説明する。この例では、Ｗｅｂ ＡＰＩ＿Ｘ１０９からブラウザ１０３を介してＷｅｂアプリケーション＿Ａ１０７へ認可コードを渡した後で（Ｓ２０５ａ及びＳ２０５ｂ）、認可コードに基づいて一次アクセストークンが渡される（Ｓ２０５ｃ）。

一次アクセストークンを得たＷｅｂアプリケーション＿Ａ１０７は、一次アクセストークンを伴ってＷｅｂ ＡＰＩ＿Ｘ１０９を呼び出す（Ｓ２０７）。Ｗｅｂ ＡＰＩ＿Ｘ１０９は、一次アクセストークンが正当であることを確認して、呼び出されたＷｅｂ ＡＰＩ＿Ｘ１０９のコマンドの機能に基づくサービスを提供する。

この例では、更にＷｅｂ ＡＰＩ＿Ｘ１０９がＷｅｂ ＡＰＩ＿Ｙ１１１を利用することを想定する。Ｗｅｂ ＡＰＩ＿Ｘ１０９がＷｅｂ ＡＰＩ＿Ｙ１１１を利用するための権限について、ユーザから受ける認可を二次認可という。また、二次認可に基づくＷｅｂ ＡＰＩ＿Ｙ１１１の呼び出しを、二次ＡＰＩ呼び出しという。

ここで、図４を用いて二次認可における課題について説明する。尚、二次認可に係るエンティティ、プログラム、処理、画面、データ及びパラメータ等について、「二次」の語句を付して、一次認可に係るエンティティ、プログラム、処理、画面、データ及びパラメータ等と区別する。

この例における二次認可の手順も、ＯＡｕｔｈに準拠する。この例におけるプログラムをＯＡｕｔｈにおけるエンティティに当てはめる。ブラウザ１０３は、二次認可におけるリソースオーナー（つまり、二次リソースオーナー）である。Ｗｅｂ ＡＰＩ＿Ｘ１０９は、二次認可におけるクライアント（つまり、二次クライアント）である。Ｗｅｂ ＡＰＩ＿Ｙ１１１は、二次認可における許可サーバ（つまり、二次許可サーバ）である。Ｗｅｂ ＡＰＩ＿Ｙ１１１は、更に二次認可におけるリソースサーバ（つまり、二次リソースサーバ）である。

上記一次認可の手順で説明したように、従来技術によれば呼び出し元に対して認可要求が送られる。従って、二次認可にこの仕組みを適用すれば、二次認可要求は、Ｗｅｂアプリケーション＿Ａ１０７に送られることになる。しかし、Ｗｅｂアプリケーション＿Ａ１０７は、二次リソースオーナーではないので二次認可に係る対応を行えない。本来的には、二次リソースオーナーであるブラウザ１０３に二次認可要求を送るべきところであるが、そのような仕組みは従来ない。

図５を用いて、本実施の形態における二次認可及び二次ＡＰＩ呼び出しの概要について説明する。Ｗｅｂ ＡＰＩ＿Ｘ１０９は、呼び出し元であるＷｅｂアプリケーション＿Ａ１０７へ二次認可要求の転送指示を送る（Ｓ５０１）。Ｗｅｂアプリケーション＿Ａ１０７は、この指示に従って二次認可要求をブラウザ１０３へ転送する（Ｓ５０３）。

次に、ブラウザ１０３とＷｅｂ ＡＰＩ＿Ｙ１１１との間における二次認可の手続きを経て（Ｓ５０５）、Ｗｅｂ ＡＰＩ＿Ｙ１１１は二次認可を受け付ける。尚、二次認可の手続きにおいて、ブラウザ１０３に二次同意画面が表示される。

図６に、二次同意画面の例を示す。上述した通り、「ＡＡＡ」は、Ｗｅｂアプリケーション＿Ａ１０７の名前である。同じく「ＸＸＸ」は、Ｗｅｂ ＡＰＩ＿Ｘ１０９の名前である。「ＹＹＹ」は、Ｗｅｂ ＡＰＩ＿Ｙ１１１の名前である。

図６に示したように、一次クライアントに呼び出された一次リソースサーバが、二次クライアントとして二次リソースサーバを呼び出すことについての同意を確認する内容のコメントが表示される。「認可する」と表示された認可ボタンが選択されると、Ｗｅｂアプリケーション＿Ａ１０７により呼び出されたＷｅｂ ＡＰＩ＿Ｘ１０９によるＷｅｂ ＡＰＩ＿Ｙ１１１の呼び出しをユーザが認可したことになる。一方、「拒否する」と表示された拒否ボタンが選択されると、Ｗｅｂアプリケーション＿Ａ１０７により呼び出されたＷｅｂ ＡＰＩ＿Ｘ１０９によるＷｅｂ ＡＰＩ＿Ｙ１１１の呼び出しをユーザが拒否したことになる。

図５の説明に戻る。Ｗｅｂ ＡＰＩ＿Ｙ１１１が二次認可を受け付けると、Ｗｅｂ ＡＰＩ＿Ｙ１１１は二次アクセストークンを発行し、当該二次アクセストークンはＷｅｂ ＡＰＩ＿Ｘ１０９に引き渡される。本実施の形態では、ＯＡｕｔｈにおける認可コードグラント方式によって二次アクセストークンが発行される例について説明する。この例では、Ｗｅｂ ＡＰＩ＿Ｙ１１１からブラウザ１０３を介してＷｅｂ ＡＰＩ＿Ｘ１０９へ認可コードを渡した後で（Ｓ５０７ａ及びＳ５０７ｂ）、認可コードに基づいて二次アクセストークンが渡される（Ｓ５０７ｃ）。

二次アクセストークンを得たＷｅｂ ＡＰＩ＿Ｘ１０９は、二次アクセストークンを伴ってＷｅｂ ＡＰＩ＿Ｙ１１１を呼び出す（Ｓ５０９）。Ｗｅｂ ＡＰＩ＿Ｙ１１１は、二次アクセストークンが正当であることを確認して、呼び出されたＷｅｂ ＡＰＩ＿Ｙ１１１のコマンドの機能に基づくサービスを提供する。

本実施の形態では、二次クライアントにおいて、一次クライアント毎の二次アクセストークンを管理する。図７に、アクセストークンの紐付けの概要を示す。上述した通り、Ｗｅｂアプリケーション＿Ａ１０７がブラウザ１０３からのリクエストに応じた処理を行う際にＷｅｂ ＡＰＩ＿Ｘ１０９を利用し、また利用されるＷｅｂ ＡＰＩ＿Ｘ１０９は、更にＷｅｂ ＡＰＩ＿Ｙ１１１を利用する。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９はＷｅｂアプリケーション＿Ａ１０７に対して一次アクセストークンであるＴＸ＿Ａを発行する。また、Ｗｅｂ ＡＰＩ＿Ｙ１１１はＷｅｂ ＡＰＩ＿Ｘ１０９に対して二次アクセストークンであるＴＹ＿Ｘ１を発行する。

更に、上述した手順と同様に、Ｗｅｂアプリケーション＿Ｂ７０１がブラウザ１０３からのリクエストに応じた処理を行う際にＷｅｂ ＡＰＩ＿Ｘ１０９を利用し、また利用されるＷｅｂ ＡＰＩ＿Ｘ１０９は、更にＷｅｂ ＡＰＩ＿Ｙ１１１を利用するものとする。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９はＷｅｂアプリケーション＿Ｂ７０１に対して一次アクセストークンであるＴＸ＿Ｂを発行する。また、Ｗｅｂ ＡＰＩ＿Ｙ１１１はＷｅｂ ＡＰＩ＿Ｘ１０９に対して二次アクセストークンであるＴＹ＿Ｘ２を発行する。

Ｗｅｂ ＡＰＩ＿Ｘ１０９は、二次アクセストークンのＴＹ＿Ｘ１を取得したときに、ＴＹ＿Ｘ１を取得する契機となった呼び出しにおいて示された一次アクセストークンのＴＸ＿Ａと当該ＴＹ＿Ｘ１とを紐付ける。その後、Ｗｅｂアプリケーション＿Ａ１０７が一次アクセストークンのＴＸ＿Ａを伴ってＷｅｂ ＡＰＩ＿Ｘ１０９を呼び出した場合には、Ｗｅｂ ＡＰＩ＿Ｘ１０９はＴＸ＿Ａに対応する二次アクセストークンのＴＹ＿Ｘ１を伴ってＷｅｂ ＡＰＩ＿Ｙ１１１を呼び出すようにする。

同様に、Ｗｅｂ ＡＰＩ＿Ｘ１０９は、二次アクセストークンのＴＹ＿Ｘ２を取得したときに、ＴＹ＿Ｘ２を取得する契機となった呼び出しにおいて示された一次アクセストークンのＴＸ＿Ｂと当該ＴＹ＿Ｘ２とを紐付ける。その後、Ｗｅｂアプリケーション＿Ｂ７０１が一次アクセストークンのＴＸ＿Ｂを伴ってＷｅｂ ＡＰＩ＿Ｘ１０９を呼び出した場合には、Ｗｅｂ ＡＰＩ＿Ｘ１０９はＴＸ＿Ｂに対応する二次アクセストークンのＴＹ＿Ｘ２を伴ってＷｅｂ ＡＰＩ＿Ｙ１１１を呼び出すようにする。

このようにすれば、二次同意画面に示されたコメントの内容に従ってアクセス権限を区別することができる。もしも、Ｗｅｂアプリケーション＿Ｂ７０１の動作に伴う二次同意画面においてユーザが拒否した場合には、Ｗｅｂ ＡＰＩ＿Ｘ１０９が二次アクセストークンのＴＹ＿Ｘ１を保持していたとしても、この二次アクセストークンを用いることはない。つまり、二次アクセストークンのＴＹ＿Ｘ１は、Ｗｅｂアプリケーション＿Ａ１０７の動作における認可に基づくので流用されない。以上で、本実施の形態における概要の説明を終える。

以下、本実施の形態における動作について詳述する。図８に示すように、Ｗｅｂサーバ１０５ａは、アプリケーション部８０１を有する。アプリケーション部８０１は、Ｗｅｂアプリケーション＿Ａ１０７のプログラムに含まれる命令をＣＰＵ（Central Processing Unit）が処理することによって実現される。

図８を用いてアプリケーション部８０１のモジュール構成について説明する。アプリケーション部８０１は、第１送信部８０３、第２送信部８０５、受信部８０７、作成部８０９、生成部８１１、認証部８１３、呼び出し部８１５及び転送部８１７を有する。

第１送信部８０３は、ブラウザ１０３へ各種データを送信する。第２送信部８０５は、Ｗｅｂ ＡＰＩ＿Ｘ１０９へ各種データを送信する。受信部８０７は、各種データを受信する。作成部８０９は、ＨＴＭＬファイルを作成する。生成部８１１は、一次乱数を生成する。認証部８１３は、一次ローカルステートの認証を行う。一次ローカルステートは、一次認可要求を識別するデータである。ＯＡｕｔｈの仕様に従ったローカルステートの認証によって、成りすましが防止される。呼び出し部８１５は、一次ＡＰＩ呼び出しを行う。転送部８１７は、二次認可要求をブラウザ１０３へ転送する。

上述したアプリケーション部８０１、第１送信部８０３、第２送信部８０５、受信部８０７、作成部８０９、生成部８１１、認証部８１３、呼び出し部８１５及び転送部８１７は、ハードウエア資源（例えば、図２７）と、以下で述べる処理をＣＰＵに実行させるアプリケーションプログラムとを用いて実現される。

図９に示すように、Ｗｅｂサーバ１０５ｂは、第１機能提供部９０１を有する。第１機能提供部９０１は、Ｗｅｂ ＡＰＩ＿Ｘ１０９のプログラムに含まれる命令をＣＰＵが処理することによって実現される。

図９を用いて第１機能提供部９０１のモジュール構成について説明する。第１機能提供部９０１は、第１送信部９０３、第２送信部９０５、第３送信部９０７、受信部９０９、第１生成部９１１、第２生成部９１３、第１認証部９１５、第１検証部９１７、第３生成部９１９、第４生成部９２１、第１特定部９２３、紐付け部９２５、第２認証部９２７、呼び出し部９２９、探索部９３１、第２特定部９３３、第２検証部９３５、機能部９３７及び紐付けテーブル記憶部９４１を有する。

第１送信部９０３は、ブラウザ１０３へ各種データを送信する。第２送信部９０５は、Ｗｅｂアプリケーション＿Ａ１０７へ各種データを送信する。第３送信部９０７は、Ｗｅｂ ＡＰＩ＿Ｙ１１１へ各種データを送信する。受信部９０９は、各種データを受信する。

第１生成部９１１は、一次同意画面を生成する。第２生成部９１３は、一次認可コードを生成する。認可コードは、ＯＡｕｔｈの仕様に基づき、アクセストークンを取得する前提となるデータである。第１認証部９１５は、一次クライアントの認証を行う。第１検証部９１７は、一次認可コードの検証を行う。第３生成部９１９は、一次アクセストークンを生成する。第４生成部９２１は、二次乱数を生成する。第１特定部９２３は、一次クライアントＩＤに基づいて一次クライアント名を特定する。紐付け部９２５は、紐付けテーブルを生成する。紐付けテーブルは、紐付けテーブル記憶部９４１に記憶される。紐付けテーブルについては、図１５を用いて後述する。

第２認証部９２７は、二次ローカルステートの認証を行う。二次ローカルステートは、二次認可要求を識別するデータである。ＯＡｕｔｈの仕様に従ったローカルステートの認証によって、成りすましが防止される。呼び出し部９２９は、二次ＡＰＩ呼び出しを行う。探索部９３１は、紐付けテーブルにおいて二次アクセストークンを探索する。第２特定部９３３は、一次クライアントＩＤに基づいてコールバックＵＲＬを特定する。尚、第２特定部９３３については、実施の形態２において説明する。

第２検証部９３５は、一次アクセストークンの検証を行う。機能部９３７は、Ｗｅｂ ＡＰＩ＿Ｘ１０９のコマンドの機能を実現するための処理を実行する。

上述した第１機能提供部９０１、第１送信部９０３、第２送信部９０５、第３送信部９０７、受信部９０９、第１生成部９１１、第２生成部９１３、第１認証部９１５、第１検証部９１７、第３生成部９１９、第４生成部９２１、第１特定部９２３、紐付け部９２５、第２認証部９２７、呼び出し部９２９、探索部９３１、第２特定部９３３、第２検証部９３５及び機能部９３７は、ハードウエア資源（例えば、図２７）と、以下で述べる処理をＣＰＵに実行させるＷｅｂ ＡＰＩのプログラムとを用いて実現される。

上述した紐付けテーブル記憶部９４１は、ハードウエア資源（例えば、図２７）を用いて実現される。

続いて、本実施の形態におけるシーケンスについて説明する。図１０に、一次認可のシーケンス例を示す。Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７が、ブラウザ１０３から送られたＨＴＭＬファイルのリクエストを受信すると（Ｓ１００１）、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の作成部８０９は、ＨＴＭＬファイルを作成する処理を開始する（Ｓ１００３）。

ＨＴＭＬファイルを作成する処理においてＷｅｂ ＡＰＩ＿Ｘ１０９を利用しようとする場合に、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１は、Ｗｅｂ ＡＰＩ＿Ｘ１０９を呼び出すための準備処理を開始する（Ｓ１００５）。Ｓ１００７以降の処理が、Ｗｅｂ ＡＰＩ＿Ｘ１０９を呼び出すための準備処理に相当する。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の生成部８１１は、一次乱数を生成する（Ｓ１００７）。一次乱数は、一次認可要求の識別子として用いられる。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の第１送信部８０３は、一次認可要求を、Ｓ１００１におけるリクエストの送信元であるブラウザ１０３へ送信する（Ｓ１００９）。具体的には、一次認可要求は、ＨＴＴＰリダイレクトの指示である。リダイレクト先ＵＲＬは、Ｗｅｂ ＡＰＩ＿Ｘ１０９における一次同意画面のＵＲＬである。リダイレクト先ＵＲＬには、パラメータとして、一次レスポンスタイプ、一次クライアントＩＤ、一次認可レスポンスのコールバックＵＲＬ及び一次ローカルステートが付加される。

認可コードグラント方式の場合に、一次レスポンスタイプには、認可コード型が設定される。この例における一次クライアントＩＤは、Ｗｅｂアプリケーション＿Ａ１０７のＩＤである。一次認可レスポンスのコールバックＵＲＬは、一次認可レスポンスの宛先に相当する。この例における一次認可レスポンスのコールバックＵＲＬは、Ｗｅｂアプリケーション＿Ａ１０７のＵＲＬである。一次ローカルステートには、一次乱数が設定される。一次ローカルステートは、一次認可要求を識別するデータであって、ＯＡｕｔｈの仕様に従って一次認可におけるやり取りの一貫性を保つために用いられる。第三者による成りすましを防止するために、推測され難い値が用いられる。

ブラウザ１０３が一次認可要求を受信すると（Ｓ１０１１）、ブラウザ１０３は、ＨＴＴＰリダイレクトによってＷｅｂ ＡＰＩ＿Ｘ１０９における一次同意画面のＵＲＬへアクセスする（Ｓ１０１３）。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９における一次同意画面のＵＲＬに付加されている上記パラメータも引き渡される。図１１に示したシーケンスに移る。

図１１について説明する。Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第１生成部９１１は、一次同意画面を生成する（Ｓ１１０１）。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第１生成部９１１は、一次同意画面のコメントに、一次クライアントのプログラム名（以下、一次クライアント名という。）と一次リソースサーバとのプログラム名（以下、一次リソースサーバ名という。）を設定する。一次クライアント名は、一次クライアントＩＤに基づいて特定される。尚 、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１は、予め一次クライアントＩＤに対応付けて一次クライアント名を保持している。そして、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第１送信部９０３は、一次同意画面データをアクセス元であるブラウザ１０３へ送信する（Ｓ１１０３）。

ブラウザ１０３が一次同意画面データを受信すると（Ｓ１１０５）、ブラウザ１０３は、一次同意画面を表示する（Ｓ１１０７）。一次同意画面において認可ボタンが選択されると、ブラウザ１０３は、一次認可を受け付ける（Ｓ１１０９）。一次同意画面の仕組みに従って、ブラウザ１０３は、一次認可通知をＷｅｂ ＡＰＩ＿Ｘ１０９へ送信する（Ｓ１１１１）。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の受信部９０９が一次認可通知を受信すると（Ｓ１１１３）、図１２に示したシーケンスに移る。

図１２について説明する。Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第２生成部９１３は、一次認可コードを生成する（Ｓ１２０１）。一次認可コードの生成は、従来技術による。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第１送信部９０３は、一次認可レスポンスを、一次認可通知の送信元であるブラウザ１０３へ送信する（Ｓ１２０３）。具体的には、一次認可レスポンスは、ＨＴＴＰリダイレクトの指示である。リダイレクト先ＵＲＬは、一次認可レスポンスのコールバックＵＲＬ（この例では、Ｗｅｂアプリケーション＿Ａ１０７のＵＲＬ）である。リダイレクト先ＵＲＬには、パラメータとして、一次認可コード及び一次ローカルステートが付加される。

ブラウザ１０３が一次認可レスポンスを受信すると（Ｓ１２０５）、ブラウザ１０３は、ＨＴＴＰリダイレクトによってＷｅｂアプリケーション＿Ａ１０７のＵＲＬへアクセスする（Ｓ１２０７）。このとき、Ｗｅｂアプリケーション＿Ａ１０７のＵＲＬに付加されている上記パラメータも引き渡される。図１３に示したシーケンスに移る。

図１３について説明する。Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の認証部８１３は、一次ローカルステートの認証を行う（Ｓ１３０１）。具体的には、図１０のＳ１００９で一次認可要求に含めた一次ローカルステートと、図１２のＳ１２０７で引き渡された一次ローカルステートが一致する場合には、一次ローカルステートの認証が成功する。一次ローカルステートの認証が失敗した場合には、処理が中断される。この例では、一次ローカルステートの認証が成功したものと想定する。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の第２送信部８０５は、一次認可コードに基づく一次アクセストークン要求をＷｅｂ ＡＰＩ＿Ｘ１０９へ送信する（Ｓ１３０３）。一次認可コードには、一次クライアントＩＤ及び一次クライアントシークレットが付加される。シークレットは、パスワードに相当する。つまり、一次クライアントＩＤ及び一次クライアントシークレットは、一次クレデンシャルである。この例における一次クライアントＩＤは、Ｗｅｂアプリケーション＿Ａ１０７のＩＤである。この例における一次クライアントシークレットは、Ｗｅｂアプリケーション＿Ａ１０７のシークレットである。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の受信部９０９が一次アクセストークン要求を受信すると（Ｓ１３０５）、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第１認証部９１５は、一次クライアントＩＤ及び一次クライアントシークレットに基づいて、一次クライアントの認証を行う（Ｓ１３０７）。一次クライアントの認証が失敗した場合には、処理が中断される。この例では、一次クライアントの認証が成功したものと想定する。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第１検証部９１７は、一次認可コードの検証を行う（Ｓ１３０９）。一次認可コードが正当なものであれば、一次認可コードの検証が成功する。一次認可コードの検証が失敗した場合には、処理が中断される。この例では、一次認可コードの検証が成功したものと想定する。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第３生成部９１９は、一次アクセストークンを生成する（Ｓ１３１１）。一次アクセストークンの生成方法は、従来技術による。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第２送信部９０５は、一次アクセストークンを、一次アクセストークン要求の送信元であるＷｅｂアプリケーション＿Ａ１０７へ送信する（Ｓ１３１３）。ここでは、一次アクセストークンであるＴＸ＿Ａが送信されたものとする。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７が一次アクセストークンであるＴＸ＿Ａを受信すると（Ｓ１３１５）、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１は、Ｗｅｂ ＡＰＩ＿Ｘ１０９を呼び出すための準備処理を終了することになる（Ｓ１３１７）。Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の呼び出し部８１５は、Ｗｅｂ ＡＰＩ＿Ｘ１０９の呼び出しを行う（Ｓ１３１９）。Ｗｅｂ ＡＰＩ＿Ｘ１０９へのアクセスの際に、一次アクセストークンであるＴＸ＿Ａが転送される。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の受信部９０９がＷｅｂ ＡＰＩ＿Ｘ１０９へのアクセスを受信すると（Ｓ１３２１）、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第２検証部９３５は、一次アクセストークンの検証を行う（Ｓ１３２３）。一次アクセストークンが正当なものであれば、一次アクセストークンの検証が成功する。一次アクセストークンの検証が失敗した場合には、処理が中断される。この例では、一次アクセストークンの検証が成功したものと想定する。

一次アクセストークンの検証が成功すると、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の機能部９３７が当該アクセスに係るコマンドの機能を実現するための処理を開始する。そして、図１４に示したシーケンスに移る。

図１４について説明する。ここから、二次認可のシーケンスに移る。上記コマンドの機能を実現するための処理においてＷｅｂ ＡＰＩ＿Ｙ１１１を利用しようとする場合に、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１は、Ｗｅｂ ＡＰＩ＿Ｙ１１１を呼び出すための準備処理を開始する（Ｓ１４０１）。Ｓ１４０３以降の処理が、Ｗｅｂ ＡＰＩ＿Ｙ１１１を呼び出すための準備処理に相当する。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第４生成部９２１は、二次乱数を生成する（Ｓ１４０３）。二次乱数は、二次認可要求の識別子として用いられる。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第１特定部９２３は、一次クライアントＩＤに基づいて一次クライアント名を特定する（Ｓ１４０５）。この例における一次クライアント名は、Ｗｅｂアプリケーション＿Ａ１０７の名前「ＡＡＡ」である。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第２送信部９０５は、二次認可要求の転送指示をＷｅｂ ＡＰＩ＿Ｘ１０９の呼び出し元であるＷｅｂアプリケーション＿Ａ１０７へ送信する（Ｓ１４０７）。具体的には、二次認可要求は、ＨＴＴＰリダイレクトの指示である。リダイレクト先ＵＲＬは、Ｗｅｂ ＡＰＩ＿Ｙ１１１における二次同意画面のＵＲＬである。リダイレクト先ＵＲＬには、パラメータとして、二次レスポンスタイプ、二次クライアントＩＤ、二次認可レスポンスのコールバックＵＲＬ及び二次ローカルステートが付加される。

認可コードグラント方式の場合に、二次レスポンスタイプには、認可コード型が設定される。この例における二次クライアントＩＤは、Ｗｅｂ ＡＰＩ＿Ｘ１０９のＩＤである。二次認可レスポンスのコールバックＵＲＬは、二次認可レスポンスの宛先に相当する。この例における二次認可レスポンスのコールバックＵＲＬは、Ｗｅｂ ＡＰＩ＿Ｘ１０９のＵＲＬである。二次ローカルステートには、二次乱数と一次クライアント名との組み合わせが設定される。つまり、この例では、二次ローカルステートの一部を一次クライアント名を伝送するために用いる。但し、二次ローカルステートに、二次乱数のみを設定し、一次クライアント名を別のパラメータとして伝送するようにしてもよい。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、ローカルステートの紐付けを行う（Ｓ１４０９）。具体的には、当該紐付け部９２５は、紐付けテーブルに新たなレコードを設けて、当該レコードに一次アクセストークン、二次リソースサーバのＵＲＬ及び二次ローカルステート（二次乱数と一次クライアント名との組み合わせ）が設定される。この例では、一次アクセストークンであるＴＸ＿Ａ、二次リソースサーバのＵＲＬであるＷｅｂ ＡＰＩ＿Ｙ１１１のＵＲＬ、二次乱数であるＲＸ＿Ａ及び一次クライアント名であるＡＡＡが設定される。

図１５に、紐付けテーブルの例を示す。この例における紐付けテーブルは、二次認可に対応するレコードを有している。紐付けテーブルのレコードは、一次アクセストークンが格納されるフィールドと、二次リソースサーバのＵＲＬが格納されるフィールドと、二次ローカルステートである二次乱数と一次クライアント名との組合せが格納されるフィールドと、二次認可コードが格納されるフィールドと、二次アクセストークンが格納されるフィールドとを有している。

図１４の説明に戻る。Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７が二次認可要求の転送指示を受信すると（Ｓ１４１１）、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の転送部８１７は、受信した二次認可要求を、図１０のＳ１００１におけるリクエストの送信元であるブラウザ１０３へ転送する（Ｓ１４１３）。

ブラウザ１０３が二次認可要求を受信すると（Ｓ１４１５）、ブラウザ１０３は、ＨＴＴＰリダイレクトによってＷｅｂ ＡＰＩ＿Ｙ１１１における二次同意画面のＵＲＬへアクセスする（Ｓ１４１７）。このとき、Ｗｅｂ ＡＰＩ＿Ｙ１１１における二次同意画面のＵＲＬに付加されている上記パラメータも引き渡される。

ここで、一旦シーケンスについての説明を中断し、Ｗｅｂサーバ１０５ｃにおけるモジュールについて説明する。

図１６に示すように、Ｗｅｂサーバ１０５ｃは、第２機能提供部１６０１を有する。第２機能提供部１６０１は、Ｗｅｂ ＡＰＩ＿Ｙ１１１のプログラムに含まれる命令をＣＰＵが処理することによって実現される。

図１６を用いて第２機能提供部１６０１のモジュール構成について説明する。図１６に、第２機能提供部１６０１のモジュール構成例を示す。第２機能提供部１６０１は、第１送信部１６０３、第２送信部１６０５、受信部１６０７、第１生成部１６０９、第２生成部１６１１、認証部１６１３、第１検証部１６１５、第３生成部１６１７、特定部１６１９、第２検証部１６２１及び機能部１６２３を有する。

第１送信部１６０３は、ブラウザ１０３へ各種データを送信する。第２送信部１６０５は、Ｗｅｂ ＡＰＩ＿Ｘ１０９へ各種データを送信する。受信部１６０７は、各種データを受信する。第１生成部１６０９は、二次同意画面を生成する。第２生成部１６１１は、二次認可コードを生成する。認証部１６１３は、二次クライアントの認証を行う。第１検証部１６１５は、二次認可コードの検証を行う。第３生成部１６１７は、二次アクセストークンを生成する。特定部１６１９は、二次クライアントＩＤに基づいてコールバックＵＲＬを特定する。第２検証部１６２１は、二次アクセストークンの検証を行う。機能部１６２３は、Ｗｅｂ ＡＰＩ＿Ｙ１１１のコマンドの機能を実現するための処理を実行する。

上述した第２機能提供部１６０１、第１送信部１６０３、第２送信部１６０５、受信部１６０７、第１生成部１６０９、第２生成部１６１１、認証部１６１３、第１検証部１６１５、第３生成部１６１７、特定部１６１９、第２検証部１６２１及び機能部１６２３は、ハードウエア資源（例えば、図２７）と、以下で述べる処理をＣＰＵに実行させるＷｅｂ ＡＰＩのプログラムとを用いて実現される。

シーケンスの説明に戻る。図１４に示したシーケンスから図１７に示したシーケンスに移る。Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第１生成部１６０９は、二次同意画面を生成する（Ｓ１７０１）。このとき、Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第１生成部１６０９は、二次同意画面のコメントに、一次クライアント名と、一次リソースサーバである二次クライアントのプログラム名（以下、二次クライアント名という。）と、二次リソースサーバのプログラム名（以下、二次リソースサーバ名という。）とを設定する。一次クライアント名は、二次ローカルステートから取り出される。二次クライアント名は、二次クライアントＩＤに基づいて特定される。尚、Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１は、予め二次クライアントＩＤに対応付けて二次クライアント名を保持している。そして、Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第１送信部１６０３は、二次同意画面データをアクセス元であるブラウザ１０３へ送信する（Ｓ１７０３）。

ブラウザ１０３が二次同意画面データを受信すると（Ｓ１７０５）、ブラウザ１０３は、二次同意画面を表示する（Ｓ１７０７）。二次同意画面において認可ボタンが選択されると、ブラウザ１０３は、二次認可を受け付ける（Ｓ１７０９）。二次同意画面の仕組みに従って、ブラウザ１０３は、二次認可通知をＷｅｂ ＡＰＩ＿Ｙ１１１へ送信する（Ｓ１７１１）。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の受信部１６０７が二次認可通知を受信すると（Ｓ１７１３）、図１８に示したシーケンスに移る。

図１８について説明する。Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第２生成部１６１１は、二次認可コードを生成する（Ｓ１８０１）。二次認可コードの生成は、従来技術による。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第１送信部１６０３は、二次認可レスポンスを、二次認可通知の送信元であるブラウザ１０３へ送信する（Ｓ１８０３）。具体的には、二次認可レスポンスは、ＨＴＴＰリダイレクトの指示である。リダイレクト先ＵＲＬは、二次認可レスポンスのコールバックＵＲＬ（この例では、Ｗｅｂ ＡＰＩ＿Ｘ１０９のＵＲＬ）である。リダイレクト先ＵＲＬには、パラメータとして、二次認可コード及び二次ローカルステートが付加される。

ブラウザ１０３が二次認可レスポンスを受信すると（Ｓ１８０５）。ブラウザ１０３は、ＨＴＴＰリダイレクトによってＷｅｂ ＡＰＩ＿Ｘ１０９のＵＲＬへアクセスする（Ｓ１８０７）。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９のＵＲＬに付加されている上記パラメータも引き渡される。図１９に示したシーケンスに移る。

図１９について説明する。Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第２認証部９２７は、二次ローカルステートの認証を行う（Ｓ１９０１）。図１４のＳ１４０７で二次認可要求に含めた二次ローカルステートと、図１８のＳ１８０７で引き渡された二次ローカルステートが一致する場合には、二次ローカルステートの認証が成功する。二次ローカルステートの認証が失敗した場合には、処理が中断される。この例では、二次ローカルステートの認証が成功したものと想定する。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、二次認可コードの紐付けを行う（Ｓ１９０３）。具体的には、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、Ｓ１４０９で設けたレコードに、二次認可コードを設定する。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、二次ローカルステートに基づいてレコードを特定するようにしてもよい。このようにすれば、結果的に二次認可コードが一次アクセストークンに紐付けられる。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第３送信部９０７は、二次認可コードに基づく二次アクセストークン要求をＷｅｂ ＡＰＩ＿Ｙ１１１へ送信する（Ｓ１９０５）。二次認可コードには、二次クライアントＩＤ及び二次クライアントシークレットが付加される。二次クライアントＩＤ及び二次クライアントシークレットは、二次クレデンシャルである。この例における二次クライアントＩＤは、Ｗｅｂ ＡＰＩ＿Ｘ１０９のＩＤである。この例における二次クライアントシークレットは、Ｗｅｂ ＡＰＩ＿Ｘ１０９のシークレットである。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の受信部１６０７が二次アクセストークン要求を受信すると（Ｓ１９０７）、Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の認証部１６１３は、二次クライアントＩＤ及び二次クライアントシークレットに基づいて、二次クライアントの認証を行う（Ｓ１９０９）。二次クライアントの認証が失敗した場合には、処理が中断される。この例では、二次クライアントの認証が成功したものと想定する。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第１検証部１６１５は、二次認可コードの検証を行う（Ｓ１９１１）。二次認可コードが正当なものであれば、二次認可コードの検証が成功する。二次認可コードの検証が失敗した場合には、処理が中断される。この例では、二次認可コードの検証が成功したものと想定する。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第３生成部１６１７は、二次アクセストークンを生成する（Ｓ１９１３）。二次アクセストークンの生成方法は、従来技術による。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第２送信部１６０５は、二次アクセストークンを、二次アクセストークン要求の送信元であるＷｅｂ ＡＰＩ＿Ｘ１０９へ送信する（Ｓ１９１５）。ここでは、二次アクセストークンであるＴＹ＿Ｘ１が送信されたものとする。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の受信部９０９が二次アクセストークンであるＴＹ＿Ｘ１を受信すると（Ｓ１９１７）、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、二次アクセストークンの紐付けを行う（Ｓ１９１９）。具体的には、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、Ｓ１４０９で設けたレコードに、二次アクセストークンを設定する。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、二次認可コードに基づいてレコードを特定するようにしてもよい。このようにすれば、結果的に二次アクセストークンが一次アクセストークンに紐付けられる。

この段階で、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１は、Ｗｅｂ ＡＰＩ＿Ｙ１１１を呼び出すための準備処理を終了することになる（Ｓ１９２１）。Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の呼び出し部９２９は、Ｗｅｂ ＡＰＩ＿Ｙ１１１の呼び出しを行う（Ｓ１９２３）。Ｗｅｂ ＡＰＩ＿Ｙ１１１へのアクセスの際に、二次アクセストークンであるＴＹ＿Ｘ１が転送される。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の受信部１６０７がＷｅｂ ＡＰＩ＿Ｙ１１１へのアクセスを受信すると（Ｓ１９２５）、Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第２検証部１６２１は二次アクセストークンの検証を行う（Ｓ１９２７）。二次アクセストークンが正当なものであれば、二次アクセストークンの検証が成功する。二次アクセストークンの検証が失敗した場合には、処理が中断される。この例では、二次アクセストークンの検証が成功したものと想定する。

二次アクセストークンの検証が成功すると、Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の機能部１６２３が、Ｗｅｂ ＡＰＩ＿Ｙ１１１におけるコマンドの機能を実現するための処理を開始する。そして、図２０に示したシーケンスに移る。

図２０について説明する。Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の機能部１６２３が、Ｗｅｂ ＡＰＩ＿Ｙ１１１におけるコマンドの機能を実現するための処理を終えると、Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第２送信部１６０５は、ＡＰＩレスポンスをＷｅｂ ＡＰＩ＿Ｙ１１１の呼び出し元であるＷｅｂ ＡＰＩ＿Ｘ１０９へ送信する（Ｓ２００１）。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の受信部９０９がＷｅｂ ＡＰＩ＿Ｙ１１１からのレスポンスを受信すると（Ｓ２００３）、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の機能部９３７がＷｅｂ ＡＰＩ＿Ｘ１０９におけるコマンドの機能を実現するための処理を継続する。そして、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の機能部９３７が当該処理を終えると、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第２送信部９０５は、ＡＰＩレスポンスをＷｅｂ ＡＰＩ＿Ｘ１０９の呼び出し元であるＷｅｂアプリケーション＿Ａ１０７へ送信する（Ｓ２００５）。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７がＷｅｂ ＡＰＩ＿Ｘ１０９からのレスポンスを受信すると（Ｓ２００７）、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の作成部８０９がＨＴＭＬファイル作成の処理を継続する。そして、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の作成部８０９がＨＴＭＬファイル作成の処理を終えると（Ｓ２００９）、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の第１送信部８０３は、ＨＴＭＬファイルをリクエスト元のブラウザ１０３へ送信する（Ｓ２０１１）。

ブラウザ１０３がＨＴＭＬファイルを受信すると（Ｓ２０１３）、ブラウザ１０３は、ＨＴＭＬファイルに基づく画面表示を行う（Ｓ２０１５）。

その後ブラウザ１０３が、例えば前回と同様にＨＴＭＬファイルをリクエストする場合に、一次アクセストークンの発行及び二次アクセストークンの発行は省略される。図２１に、２回目以降における一次ＡＰＩ呼び出し及び二次ＡＰＩ呼び出しのシーケンス例を示す。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７がブラウザ１０３から送られたＨＴＭＬファイルのリクエストを受信すると（Ｓ２１０１）、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の呼び出し部８１５は、Ｗｅｂアプリケーション＿Ａ１０７におけるユーザアカウントに対応付けられている一次アクセストークン（この例では、ＴＸ＿Ａ）を用いて、Ｗｅｂ ＡＰＩ＿Ｘ１０９の呼び出しを行う（Ｓ２１０３）。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の受信部９０９がＷｅｂ ＡＰＩ＿Ｘ１０９へのアクセスを受信すると（Ｓ２１０５）、一次アクセストークンが正当であるので、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１は正常に動作する。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１は、Ｗｅｂ ＡＰＩ＿Ｙ１１１を呼び出すための準備処理に移る。Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の探索部９３１は、二次アクセストークンを探索する（Ｓ２１０７）。具体的には、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の探索部９３１は、紐付けテーブルにおいて、一次アクセストークンをキーとして、当該一次アクセストークンと一致するレコードを探索する。或いは、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の探索部９３１は、紐付けテーブルにおいて、一次アクセストークンと二次リソースサーバのＵＲＬとの組をキーとして、当該組と一致するレコードを探索する。該当するレコードがあれば、当該レコードに格納されている二次アクセストークンを用いる。尚、該当するレコードがない場合には、図１４に示したＳ１４０１以降の処理を行う。

この例では、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の呼び出し部９２９は、二次アクセストークン（ＴＹ＿Ｘ１）を用いて、Ｗｅｂ ＡＰＩ＿Ｙ１１１の呼び出しを行う（Ｓ２１０９）。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の受信部１６０７がＷｅｂ ＡＰＩ＿Ｙ１１１へのアクセスを受信すると（Ｓ２１１１）、二次アクセストークンが正当であるので、Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１は正常に動作する。

本実施の形態によれば、Ｗｅｂ ＡＰＩ＿Ｘ１０９において、Ｗｅｂ ＡＰＩ＿Ｙ１１１を、より安全に利用できるようになる。

また、一次アクセストークンに基づいて、二次アクセストークンを特定できるようになる。

［実施の形態２］
上述した実施の形態では、ＯＡｕｔｈにおける認可コードグラント方式によって一次アクセストークンを発行し、同じく認可コードグラント方式によって二次アクセストークンを発行する例について説明した。但し、別の方式によって一次アクセストークンを発行するようにしてもよい。また、別の方式によって二次アクセストークンを発行するようにしてもよい。本実施の形態では、ＯＡｕｔｈにおけるインプリシットグラント方式によって一次アクセストークンを発行し、同じくインプリシットグラント方式によって二次アクセストークンを発行する例について説明する。

実施の形態２では、図１０に示した一次認可のシーケンスにおける処理に代えて、図２２に示した一次認可のシーケンスにおける処理が実行される。

Ｓ１００１乃至Ｓ１００７に示した処理は、図１０の場合と同様である。

Ｓ２２０１においてＷｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の第１送信部８０３が送信する一次認可要求は、実施の形態１の場合と同様にＨＴＴＰリダイレクトの指示である。但し、インプリシットグラント方式の場合に、二次レスポンスタイプには、アクセストークン型が設定される。また、二次認可レスポンスのコールバックＵＲＬは、省かれる。

ブラウザ１０３が上記パラメータを含む一次認可要求を受信すると（Ｓ２２０３）、ブラウザ１０３は、ＨＴＴＰリダイレクトによってＷｅｂ ＡＰＩ＿Ｘ１０９における一次同意画面のＵＲＬへアクセスする（Ｓ２２０５）。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９における一次同意画面のＵＲＬに付加されている上記パラメータも引き渡される。図１１に示したシーケンスに移る。

実施の形態２では、図１１に示した一次認可のシーケンスの場合と同様の処理が実行される。

実施の形態２では、図１２及び図１３に示した一次認可及び一次ＡＰＩ呼び出しのシーケンスにおける処理に代えて、図２３に示した一次認可及び一次ＡＰＩ呼び出しのシーケンスにおける処理が実行される。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第４生成部９２１は、一次アクセストークンを生成する（Ｓ２３０１）。一次アクセストークンの生成方法は、従来技術による。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第２特定部９３３は、一次クライアントＩＤに基づいてコールバックＵＲＬを特定する（Ｓ２３０３）。コールバックＵＲＬは、一次クライアントのＵＲＬである。尚、第１機能提供部９０１は、従来技術の通り、一次クライアントのＵＲＬを一次クライアントＩＤと対応付けるデータを保持しているものとする。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の第１送信部９０３は、一次認可レスポンスを、一次認可通知の送信元であるブラウザ１０３へ送信する（Ｓ２３０５）。実施の形態２では、リダイレクト先ＵＲＬのパラメータとして、一次認可コードに代えて、一次アクセストークン（この例では、ＴＸ＿Ａ）が付加される。

ブラウザ１０３が一次認可レスポンスを受信すると（Ｓ２３０７）、ブラウザ１０３は、ＨＴＴＰリダイレクトによってＷｅｂアプリケーション＿Ａ１０７のＵＲＬへアクセスする（Ｓ２３０９）。このとき、Ｗｅｂアプリケーション＿Ａ１０７のＵＲＬに付加されている上記パラメータも引き渡される。

Ｓ１３１７乃至Ｓ１３２３に示した処理は、図１３の場合と同様である。

実施の形態２では、図１４に示した二次認可のシーケンスにおける処理に代えて、図２４に示した、二次認可のシーケンスにおける処理が実行される。

Ｓ１４０１乃至Ｓ１４０５に示した処理は、図１４の場合と同様である。

Ｓ２４０１において転送指示の対象となる二次認可要求は、実施の形態１の場合と同様にＨＴＴＰリダイレクトの指示である。但し、インプリシットグラント方式の場合に、二次レスポンスタイプには、アクセストークン型が設定される。また、二次認可レスポンスのコールバックＵＲＬは、省かれる。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、ローカルステートの紐付けを行う（Ｓ２４０３）。具体的には、当該紐付け部９２５は、紐付けテーブルに新たなレコードを設けて、当該レコードに一次アクセストークン、二次リソースサーバのＵＲＬ及び二次ローカルステート（二次乱数と一次クライアント名との組み合わせ）が設定される。この例では、一次アクセストークンであるＴＸ＿Ａ、二次リソースサーバのＵＲＬであるＷｅｂ ＡＰＩ＿Ｙ１１１のＵＲＬ、二次乱数であるＲＸ＿Ａ及び一次クライアント名であるＡＡＡが設定される。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７が二次認可要求の転送指示を受信すると（Ｓ２４０５）、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の転送部８１７は、受信した二次認可要求を、図２２のＳ１００１におけるリクエストの送信元であるブラウザ１０３へ転送する（Ｓ２４０７）。

ブラウザ１０３が二次認可要求を受信すると（Ｓ２４０９）、ブラウザ１０３は、ＨＴＴＰリダイレクトによってＷｅｂ ＡＰＩ＿Ｙ１１１における二次同意画面のＵＲＬへアクセスする（Ｓ２４１１）。このとき、Ｗｅｂ ＡＰＩ＿Ｙ１１１における二次同意画面のＵＲＬに付加されている上記パラメータも引き渡される。

実施の形態２では、図１７に示した二次認可のシーケンスの場合と同様の処理が実行される。

実施の形態２では、図１８及び図１９に示した二次認可及び二次ＡＰＩ呼び出しのシーケンスにおける処理に代えて、図２５に示した二次認可及び二次ＡＰＩ呼び出しのシーケンスにおける処理が実行される。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第３生成部１６１７は、二次アクセストークンを生成する（Ｓ２５０１）。二次アクセストークンの生成方法は、従来技術による。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の特定部１６１９は、二次クライアントＩＤに基づいてコールバックＵＲＬを特定する（Ｓ２５０３）。コールバックＵＲＬは、二次クライアントのＵＲＬである。尚、第２機能提供部１６０１は、従来技術の通り、二次クライアントのＵＲＬを二次クライアントＩＤと対応付けるデータを保持しているものとする。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第１送信部１６０３は、二次認可レスポンスを、二次認可通知の送信元であるブラウザ１０３へ送信する（Ｓ２５０５）。実施の形態２では、リダイレクト先ＵＲＬのパラメータとして、二次認可コードに代えて、二次アクセストークン（この例では、ＴＹ＿Ｘ１）が付加される。

ブラウザ１０３が二次認可レスポンスを受信すると（Ｓ２５０７）、ブラウザ１０３は、ＨＴＴＰリダイレクトによってＷｅｂアプリケーション＿Ａ１０７のＵＲＬへアクセスする（Ｓ２５０９）。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９のＵＲＬに付加されている上記パラメータも引き渡される。

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、二次アクセストークンの紐付け（Ｓ２５１１）。具体的には、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、図２４のＳ２４０３で設けたレコードに、二次アクセストークンを設定する。このとき、Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の紐付け部９２５は、二次ローカルステートに基づいてレコードを特定するようにしてもよい。このようにすれば、結果的に二次アクセストークンが一次アクセストークンに紐付けられる。

Ｓ１９２１乃至Ｓ１９２７に示した処理は、図１９の場合と同様である。

また、実施の形態２では、図２０及び図２１に示したシーケンスの場合と同様の処理が実行される。

本実施の形態によれば、インプリシットグラント方式によってアクセストークンを発行する場合も、実施の形態１と同様の効果を奏するようにできる。

尚、上述した実施の形態では、ブラウザ１０３と連携するアプリケーションプログラムの例として、ＷｅｂアプリケーションがＷｅｂ ＡＰＩを利用することを想定した。但し、ブラウザ１０３と連携するプログラムの例として、図２６に示すようにネイティブアプリケーション２６０１がＷｅｂ ＡＰＩを利用することを想定し、上述した実施の形態を適用するようにしてもよい。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上述の機能ブロック構成はプログラムモジュール構成に一致しない場合もある。

また、上で説明した各記憶領域の構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ、処理の順番を入れ替えることや複数の処理を並列に実行させるようにしても良い。

なお、上で述べたユーザ端末１０１及びＷｅｂサーバ１０５は、コンピュータ装置であって、図２７に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーションプログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーションプログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーションプログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーションプログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係るアクセス制御装置は、（Ａ）ネットワークを介して提供する第１機能に関する第１インターフェースへのアクセスを受信する受信部と、（Ｂ）上記アクセスを受信した場合に、ネットワークを介して提供される第２機能に関する第２インターフェースを利用する権限に関する認可要求を、上記アクセスの送信元プログラムと連携するブラウザ宛に転送させる指示を、当該送信元プログラムへ送信する送信部とを有する。

このようにすれば、ネットワークを介して提供する第１機能において、ネットワークを介して提供される第２機能を、より安全に利用できるようになる。尚、第２送信部９０５は、（Ｂ）送信部の例である。

更に、アクセス制御装置は、上記アクセスにおける権限の第１識別子と、第２インターフェースを利用する権限の第２識別子とを紐付ける紐付け部を有するようにしてもよい。

このようにすれば、第１インターフェースへアクセスする権限に基づいて、第２インターフェースを利用する権限を特定できるようになる。

なお、上で述べたアクセス制御装置における処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納されるようにしてもよい。尚、中間的な処理結果は、一般的にメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
ネットワークを介して提供する第１機能に関する第１インターフェースへのアクセスを受信する受信部と、
前記アクセスを受信した場合に、前記ネットワークを介して提供される第２機能に関する第２インターフェースを利用する権限に関する認可要求を、前記アクセスの送信元プログラムと連携するブラウザ宛に転送させる指示を、当該送信元プログラムへ送信する送信部と
を有するアクセス制御装置。

（付記２）
更に、
前記アクセスにおける権限の第１識別子と、前記第２インターフェースを利用する前記権限の第２識別子とを紐付ける紐付け部
を有する付記１記載のアクセス制御装置。

（付記３）
ネットワークを介して提供する第１機能に関する第１インターフェースへのアクセスを受信し、
前記アクセスを受信した場合に、前記ネットワークを介して提供される第２機能に関する第２インターフェースを利用する権限に関する認可要求を、前記アクセスの送信元プログラムと連携するブラウザ宛に転送させる指示を、当該送信元プログラムへ送信する
処理をコンピュータに実行させるアクセス制御プログラム。

（付記４）
ネットワークを介して提供する第１機能に関する第１インターフェースへのアクセスを受信し、
前記アクセスを受信した場合に、前記ネットワークを介して提供される第２機能に関する第２インターフェースを利用する権限に関する認可要求を、前記アクセスの送信元プログラムと連携するブラウザ宛に転送させる指示を、当該送信元プログラムへ送信する
処理を含み、コンピュータにより実行されるアクセス制御方法。

１０１ ユーザ端末 １０３ ブラウザ
１０５ Ｗｅｂサーバ １０７ Ｗｅｂアプリケーション＿Ａ
１０９ Ｗｅｂ ＡＰＩ＿Ｘ １１１ Ｗｅｂ ＡＰＩ＿Ｙ
７０１ Ｗｅｂアプリケーション＿Ｂ ８０１ アプリケーション部
８０３ 第１送信部 ８０５ 第２送信部
８０７ 受信部 ８０９ 作成部
８１１ 生成部 ８１３ 認証部
８１５ 呼び出し部 ８１７ 転送部
９０１ 第１機能提供部 ９０３ 第１送信部
９０５ 第２送信部 ９０７ 第３送信部
９０９ 受信部 ９１１ 第１生成部
９１３ 第２生成部 ９１５ 第１認証部
９１７ 第１検証部 ９１９ 第３生成部
９２１ 第４生成部 ９２３ 第１特定部
９２５ 紐付け部 ９２７ 第２認証部
９２９ 呼び出し部 ９３１ 探索部
９３３ 第２特定部 ９３５ 第２検証部
９３７ 機能部 ９４１ 紐付けテーブル記憶部
１６０１ 第２機能提供部 １６０３ 第１送信部
１６０５ 第２送信部 １６０７ 受信部
１６０９ 第１生成部 １６１１ 第２生成部
１６１３ 認証部 １６１５ 第１検証部
１６１７ 第３生成部 １６１９ 特定部
１６２１ 第２検証部 １６２３ 機能部
２６０１ ネイティブアプリケーション

Claims (4)

1. ネットワークを介して提供する第１機能に関する第１インターフェースへのアクセスを受信する受信部と、
   前記アクセスを受信した場合に、前記ネットワークを介して提供される第２機能に関する第２インターフェースを利用する権限に関する認可要求を、前記アクセスの送信元プログラムと連携するブラウザ宛に転送させる指示を、当該送信元プログラムへ送信する送信部と
   を有するアクセス制御装置。
2. 更に、
   前記アクセスにおける権限の第１識別子と、前記第２インターフェースを利用する前記権限の第２識別子とを紐付ける紐付け部
   を有する請求項１記載のアクセス制御装置。
3. ネットワークを介して提供する第１機能に関する第１インターフェースへのアクセスを受信し、
   前記アクセスを受信した場合に、前記ネットワークを介して提供される第２機能に関する第２インターフェースを利用する権限に関する認可要求を、前記アクセスの送信元プログラムと連携するブラウザ宛に転送させる指示を、当該送信元プログラムへ送信する
   処理をコンピュータに実行させるアクセス制御プログラム。
4. ネットワークを介して提供する第１機能に関する第１インターフェースへのアクセスを受信し、
   前記アクセスを受信した場合に、前記ネットワークを介して提供される第２機能に関する第２インターフェースを利用する権限に関する認可要求を、前記アクセスの送信元プログラムと連携するブラウザ宛に転送させる指示を、当該送信元プログラムへ送信する
   処理を含み、コンピュータにより実行されるアクセス制御方法。

Images