JP6904183B2 - 情報処理装置、プログラム及び情報処理方法 - Google Patents

Description

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

ブラウザと連携するＷｅｂアプリケーションがＷｅｂ ＡＰＩ（Application Programming Interface）の機能を利用する形態において、Ｗｅｂアプリケーションに利用される一次のＷｅｂ ＡＰＩが、更に二次のＷｅｂ ＡＰＩの機能を利用すれば、多様なサービスが実現されると考えられる。

このように多段にＷｅｂ ＡＰＩを呼び出す態様において、二次のＷｅｂ ＡＰＩのレスポンスが、秘匿性の高い内容であれば、中間段階における暴露を防ぐことが望ましい。

或る多段呼び出し態様では、一次のＷｅｂ ＡＰＩが二次のＷｅｂ ＡＰＩのレスポンスを用いることなく、二次レスポンスをそのまま一次のＷｅｂ ＡＰＩのレスポンスに含めてＷｅｂアプリケーションに送り返すかも知れない。このような場合は、一次のＷｅｂ ＡＰＩで受け取る二次レスポンスが平文である必要はない。

但し、Ｗｅｂアプリケーションは、元来、直接的に二次のＷｅｂ ＡＰＩを呼び出すことを想定していないので、Ｗｅｂアプリケーションが自発的に二次のＷｅｂ ＡＰＩと連携することは難しい。

特開２００５−８６４２８号公報 特表２０１６−５３１５２８号公報 特開２０１２−１５１８４３号公報

本発明の目的は、一側面では、一次機能のレスポンスに内包される二次機能のレスポンスを秘匿化することである。

一態様に係る情報処理装置は、第１サーバが提供する一次機能を利用する情報処理装置であって、（Ａ）一次機能が利用しようとする二次機能を提供する第２サーバ宛にリダイレクトさせるアクセス先データを、第１サーバから受信する受信部と、（Ｂ）アクセス先データに暗号化用の鍵データを付してブラウザへ転送して当該ブラウザにリダイレクトさせることで、暗号化用の鍵データを第２サーバに送る転送部と、（Ｃ）一次機能によるレスポンスに含まれる、二次機能によるレスポンスの少なくとも一部に基づく暗号化データを暗号化用の鍵データに適応した復号用の鍵データを用いて復号する復号部とを有する。

一側面としては、一次機能のレスポンスに内包される二次機能のレスポンスを秘匿化できる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

暗号鍵が付加された二次認可要求を、ブラウザ１０３が受け取ることによって、ブラウザ１０３とＷｅｂ ＡＰＩ＿Ｙ１１１との間における二次認可の手続きが行われる（Ｓ５０５）。この手続きによって、Ｗｅｂ ＡＰＩ＿Ｙ１１１は二次認可を受け付ける。尚、二次認可の手続きにおいて、ブラウザ１０３に二次同意画面が表示される。また、Ｗｅｂ ＡＰＩ＿Ｙ１１１は、受け取った暗号鍵を保持する。

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

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

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

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

Ｗｅｂ ＡＰＩ＿Ｙ１１１のサービスによって生成されＷｅｂ ＡＰＩ＿Ｘ１０９へ送られるレスポンスのデータ本体は、保持している暗号鍵を用いて暗号化される。そして、暗号化データは、Ｗｅｂ ＡＰＩ＿Ｘ１０９からＷｅｂアプリケーション＿Ａ１０７へのレスポンスに含められる。

Ｗｅｂアプリケーション＿Ａ１０７は、受け取ったレスポンスに含まれる暗号化データを、先に生成した暗号鍵を用いて復号する。このようにすれば、Ｗｅｂ ＡＰＩ＿Ｙ１１１からのレスポンスのデータ本体は、中継過程で暗号化されており、例えばＷｅｂ ＡＰＩ＿Ｘ１０９に対してその内容を秘密にすることができる。

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

Ｗｅｂアプリケーション＿Ａ１０７は、Ｗｅｂ ＡＰＩ＿Ｙ１１１で用いられる暗号鍵ＫＡ＿Ｙを生成したときに、Ｗｅｂ ＡＰＩ＿Ｘ１０９へのアクセスに用いた一次アクセストークンＴＸ＿Ａと対応付けて、当該暗号鍵ＫＡ＿Ｙを記憶する。

また、Ｗｅｂ ＡＰＩ＿Ｙ１１１は、Ｗｅｂ ＡＰＩ＿Ｘ１０９に対して二次アクセストークンＴＹ＿Ｘ１を発行するときに、二次認可の手続きで受け取った暗号鍵ＫＡ＿Ｙを、当該二次アクセストークンＴＹ＿Ｘ１と対応付けて記憶する。

Ｗｅｂ ＡＰＩ＿Ｘ１０９は、二次アクセストークンのＴＹ＿Ｘ１を取得したときに、ＴＹ＿Ｘ１を取得する契機となった呼び出しにおいて示された一次アクセストークンのＴＸ＿Ａと当該ＴＹ＿Ｘ１とを紐付ける。

上記紐付けを前提として、Ｗｅｂ ＡＰＩ＿Ｙ１１１は、二次レスポンスのデータ本体を二次アクセストークンＴＹ＿Ｘ１に対応する暗号鍵ＫＡ＿Ｙで暗号化してから、Ｗｅｂ ＡＰＩ＿Ｘ１０９へ送る。Ｗｅｂ ＡＰＩ＿Ｘ１０９は、暗号化データを含む一次レスポンスを生成し、Ｗｅｂアプリケーション＿Ａ１０７へ送る。

Ｗｅｂアプリケーション＿Ａ１０７は、Ｗｅｂ ＡＰＩ＿Ｘ１０９へのアクセスに用いた一次アクセストークンＴＸ＿Ａに対応する暗号鍵ＫＡ＿Ｙを用いて、一次レスポンスに含まれる暗号化データを復号する。

その後、再びＷｅｂアプリケーション＿Ａ１０７が一次アクセストークンのＴＸ＿Ａを伴ってＷｅｂ ＡＰＩ＿Ｘ１０９を呼び出した場合には、Ｗｅｂ ＡＰＩ＿Ｘ１０９はＴＸ＿Ａに対応する二次アクセストークンのＴＹ＿Ｘ１を伴ってＷｅｂ ＡＰＩ＿Ｙ１１１を呼び出すようにする。暗号化及び復号については、その後も同様である。

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

Ｗｅｂアプリケーション＿Ｂ７０１は、Ｗｅｂ ＡＰＩ＿Ｙ１１１で用いられる暗号鍵ＫＢ＿Ｙを生成したときに、Ｗｅｂ ＡＰＩ＿Ｘ１０９へのアクセスに用いた一次アクセストークンＴＸ＿Ｂと対応付けて、当該暗号鍵ＫＢ＿Ｙを記憶する。

また、Ｗｅｂ ＡＰＩ＿Ｙ１１１は、Ｗｅｂ ＡＰＩ＿Ｘ１０９に対して二次アクセストークンＴＹ＿Ｘ２を発行するときに、二次認可の手続きで受け取った暗号鍵ＫＢ＿Ｙを、当該二次アクセストークンＴＹ＿Ｘ２と対応付けて記憶する。

Ｗｅｂ ＡＰＩ＿Ｘ１０９は、二次アクセストークンのＴＹ＿Ｘ２を取得したときに、ＴＹ＿Ｘ２を取得する契機となった呼び出しにおいて示された一次アクセストークンのＴＸ＿Ｂと当該ＴＹ＿Ｘ２とを紐付ける。

上記紐付けを前提として、Ｗｅｂ ＡＰＩ＿Ｙ１１１は、二次レスポンスのデータ本体を二次アクセストークンＴＹ＿Ｘ２に対応する暗号鍵ＫＢ＿Ｙで暗号化してから、Ｗｅｂ ＡＰＩ＿Ｘ１０９へ送る。Ｗｅｂ ＡＰＩ＿Ｘ１０９は、暗号化データを含む一次レスポンスを生成し、Ｗｅｂアプリケーション＿Ｂ７０１へ送る。

Ｗｅｂアプリケーション＿Ｂ７０１は、Ｗｅｂ ＡＰＩ＿Ｘ１０９へのアクセスに用いた一次アクセストークンＴＸ＿Ｂに対応する暗号鍵ＫＢ＿Ｙを用いて、一次レスポンスに含まれる暗号化データを復号する。

その後、再びＷｅｂアプリケーション＿Ｂ７０１が一次アクセストークンのＴＸ＿Ｂを伴ってＷｅｂ ＡＰＩ＿Ｘ１０９を呼び出した場合には、Ｗｅｂ ＡＰＩ＿Ｘ１０９はＴＸ＿Ｂに対応する二次アクセストークンのＴＹ＿Ｘ２を伴ってＷｅｂ ＡＰＩ＿Ｙ１１１を呼び出すようにする。暗号化及び復号については、その後も同様である。

このようにすれば、Ｗｅｂ ＡＰＩ＿Ｙ１１１からの二次レスポンスのデータ本体は、起点となったアプリケーション以外において不明であり、秘密となる。つまり、Ｗｅｂアプリケーション＿Ｂ７０１が、Ｗｅｂアプリケーション＿Ａ１０７へ送られる二次レスポンスの内容を得ることはない。逆に、Ｗｅｂアプリケーション＿Ａ１０７が、Ｗｅｂアプリケーション＿Ｂ７０１へ送られる二次レスポンスの内容を得ることもない。

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

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

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

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

アプリケーション部８０１は、更に第２生成部８２１、紐付け部８２３、特定部８２５、復号部８２７及び紐付けテーブル記憶部８３１を有する。

第２生成部８２１は、暗号鍵を生成する。紐付け部８２３は、一次アクセストークンに暗号鍵を紐付ける。特定部８２５は、第１紐付けテーブルに基づいて暗号鍵を特定する。復号部８２７は、一次ＡＰＩからのレスポンスに含まれる暗号化データを復号する。紐付けテーブル記憶部８３１は、第１紐付けテーブルを記憶する。

図８Ｂに、第１紐付けテーブルの例を示す。第１紐付けテーブルにおけるレコードは、一次アクセストークンが格納されるフィールドと、暗号鍵が格納されるフィールドとを有している。暗号鍵は、第２生成部８２１において生成されたものである。一次アクセストークンは、暗号鍵を生成する契機となった一次ＡＰＩ呼び出しにおいて用いられたアクセストークンである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１４Ａの説明に戻る。Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７が二次認可要求の転送指示を受信した後（Ｓ１４１０）、図１４Ｂに示したシーケンスに移る。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の第２生成部８２１は、暗号鍵ＫＡ＿Ｙを生成する（Ｓ１４１１）。当該第２生成部８２１は、この例における暗号鍵は、対称暗号化方式における共通鍵である。非対称暗号化方式を採用する場合には、暗号化鍵と、当該暗号化鍵に対応した復号鍵とを生成するようにしてもよい。対称暗号化方式と非対称暗号化方式とのいずれであっても、復号に用いられる鍵は、暗号化に用いられる鍵に適応したものである。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の紐付け部８２３は、図１３のＳ１３２１に示したＷｅｂ ＡＰＩ＿Ｘ１０９の呼び出しにおいてＷｅｂ ＡＰＩ＿Ｘ１０９に転送した一次アクセストークンＴＸ＿Ａに、Ｓ１４１１で生成した暗号鍵を紐付ける（Ｓ１４１２）。具体的には、当該紐付け部８２３は、第１紐付けテーブルに新たなレコードを設け、当該レコードに一次アクセストークンＴＸ＿Ａ及び暗号鍵ＫＡ＿Ｙを格納する。非対称暗号化方式を採用する場合には、当該紐付け部８２３は、復号鍵を格納するようにしてもよい。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の転送部８１７は、受信した二次認可要求を、図１０のＳ１００１におけるリクエストの送信元であるブラウザ１０３へ転送する（Ｓ１４１３）。このとき、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の転送部８１７は、二次認可要求に上記パラメータ（二次レスポンスタイプ、二次クライアントＩＤ、二次認可レスポンスのコールバックＵＲＬ及び二次ローカルステート）の他に暗号鍵もパラメータとして付加する。非対称暗号化方式を採用する場合には、転送部８１７は、暗号化鍵を付加するようにしてもよい。

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

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

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

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

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

第２機能提供部１６０１は、更に紐付け部１６３１、第２特定部１６３３、暗号化部１６３５及び紐付けテーブル記憶部１６４１を有する。

紐付け部１６３１は、二次アクセストークンに暗号鍵を紐付ける。第２特定部１６３３は、第３紐付けテーブルに基づいて暗号鍵を特定する。暗号化部１６３５は、暗号鍵を用いてＡＰＩレスポンスのデータ本体を暗号化する。紐付けテーブル記憶部１６４１は、第３紐付けテーブルを記憶する。

図１６Ｂに、第３紐付けテーブルの例を示す。第３紐付けテーブルにおけるレコードは、二次アクセストークンが格納されるフィールドと、暗号鍵が格納されるフィールドとを有している。暗号鍵は、図１４ＢのＳ１４１７で示したＷｅｂ ＡＰＩ＿Ｙ１１１へのアクセスにおいて引き渡されたものである。二次アクセストークンは、当該アクセスを契機として発行されるアクセストークンである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の紐付け部１６３１は、Ｓ１９１３で生成した二次アクセストークンＴＹ＿Ｘ１に、図１４ＢのＳ１４１７で示したＨＴＴＰリダイレクトによるアクセスにおいて引き渡された暗号鍵を紐付ける（Ｓ１９１４）。具体的には、当該紐付け部１６３１は、第３紐付けテーブルに新たなレコードを設け、当該レコードに二次アクセストークンＴＹ＿Ｘ１及び暗号鍵ＫＡ＿Ｙを格納する。

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

Ｗｅｂ ＡＰＩ＿Ｘ１０９に相当する第１機能提供部９０１の受信部９０９が二次アクセストークンであるＴＹ＿Ｘ１を受信した後（Ｓ１９１７）、図１９Ｂに示したシーケンスに移る。

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

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

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

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

図２０Ａについて説明する。Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の機能部１６２３が、Ｗｅｂ ＡＰＩ＿Ｙ１１１におけるコマンドの機能を実現するための処理を終えると、 Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第２特定部１６３３は、第３紐付けテーブルに基づいて暗号鍵を特定する（Ｓ２０００）。具体的には、当該第２特定部１６３３は、図１９ＢのＳ１９２５に示したＡＰＩ＿Ｙ１１１の呼び出しにおいて転送された二次アクセストークンＴＹ＿Ｘ１に対応する暗号鍵ＫＡ＿Ｙを特定する。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の暗号化部１６３５は、特定した暗号鍵を用いて、ＡＰＩレスポンスのデータ本体を暗号化する（Ｓ２００１）。このとき、暗号化部１６３５は、例えばデータ本体の全体を暗号化する。或いは、暗号化部１６３５は、ポリシーに従ってデータ本体の所定部分を暗号化するようにしてもよい。

Ｗｅｂ ＡＰＩ＿Ｙ１１１に相当する第２機能提供部１６０１の第２送信部１６０５は、ＡＰＩレスポンスをＷｅｂ ＡＰＩ＿Ｙ１１１の呼び出し元であるＷｅｂ ＡＰＩ＿Ｘ１０９へ、暗号化されたＡＰＩレスポンスを送信する（Ｓ２００２）。

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

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７がＷｅｂ ＡＰＩ＿Ｘ１０９からのレスポンスを受信した後（Ｓ２００６）、図２０Ｂに示したシーケンスに移る。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の特定部８２５は、第１紐付けテーブルに基づいて暗号鍵を特定する（Ｓ２００７）。具体的には、当該特定部８２５は、図１３のＳ１３２１に示したＡＰＩ＿Ｘ１０９の呼び出しにおいて転送された一次アクセストークンＴＸ＿Ａに対応する暗号鍵ＫＡ＿Ｙを特定する。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の復号部８２７は、特定された暗号鍵ＫＡ＿Ｙを用いて、ＡＰＩ＿Ｘ１０９からのレスポンスに含まれる暗号化データを復号する（Ｓ２００８）。

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

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

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

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

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

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

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

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

本実施の形態によれば、一次機能のレスポンスに内包される二次機能のレスポンスを秘匿化できる。

また、二次機能の利用に関する同意画面のＵＲＬに暗号鍵を付加するので、比較的に処理が簡単になる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の受信部８０７が二次認可要求の転送指示を受信した後（Ｓ２４０４）、図２４Ｂに示したシーケンスに移る。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の第２生成部８２１は、暗号鍵ＫＡ＿Ｙを生成する（Ｓ２４０５）。当該第２生成部８２１は、例えば乱数を用いて無作為に暗号鍵ＫＡ＿Ｙを生成する。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の紐付け部８２３は、図１３のＳ１３２１に示したＷｅｂ ＡＰＩ＿Ｘ１０９の呼び出しにおいてＷｅｂ ＡＰＩ＿Ｘ１０９に転送した一次アクセストークンＴＸ＿Ａに、Ｓ２４０５で生成した暗号鍵を紐付ける（Ｓ２４０６）。具体的には、当該紐付け部８２３は、第１紐付けテーブルに新たなレコードを設け、当該レコードに一次アクセストークンＴＸ＿Ａ及び暗号鍵ＫＡ＿Ｙを格納する。

Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の転送部８１７は、受信した二次認可要求を、図２２のＳ１００１におけるリクエストの送信元であるブラウザ１０３へ転送する（Ｓ２４０７）。このとき、Ｗｅｂアプリケーション＿Ａ１０７に相当するアプリケーション部８０１の転送部８１７は、二次認可要求に上記パラメータ（二次レスポンスタイプ、二次クライアントＩＤ、二次認可レスポンスのコールバックＵＲＬ及び二次ローカルステート）の他に暗号鍵もパラメータとして付加する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本実施の形態に係る情報処理装置は、第１サーバが提供する一次機能を利用する情報処理装置であって、（Ａ）一次機能が利用しようとする二次機能を提供する第２サーバ宛にリダイレクトさせるアクセス先データを、第１サーバから受信する受信部と、（Ｂ）アクセス先データに暗号化用の鍵データを付してブラウザへ転送して当該ブラウザにリダイレクトさせることで、暗号化用の鍵データを第２サーバに送る転送部と、（Ｃ）一次機能によるレスポンスに含まれる、二次機能によるレスポンスの少なくとも一部に基づく暗号化データを暗号化用の鍵データに適応した復号用の鍵データを用いて復号する復号部とを有する。

このようにすれば、一次機能のレスポンスに内包される二次機能のレスポンスを秘匿化できる。

更に、アクセス先データは、二次機能の利用に関する同意画面のＵＲＬであってもよい。

このようにすれば、比較的に処理が簡単になる。

更に、暗号化用の鍵データ及び復号用の鍵データは、対称暗号化方式における共通鍵であってもよい。

このようにすれば、対称暗号化方式を採用できる。

更に、暗号化用の鍵データは、非対称暗号化方式における暗号化鍵であってもよく、復号用の鍵データは、非対称暗号化方式における復号鍵であってもよい。

このようにすれば、非対称暗号化方式を採用できる。

本実施の形態に係るアクセス制御システムは、ネットワークを介して一次機能を提供する第１サーバと、ネットワークを介して二次機能を提供する第２サーバと、一次機能を利用するアプリケーション装置とを含むアクセス制御システムである。そして、上記アプリケーション装置は、（Ｄ）一次認証データと第１鍵データとを対応付けて記憶する第１記憶部と、（Ｅ）一次認証データを付して一次機能を呼び出す第１呼び出し部とを有する。上記第１サーバは、（Ｆ）一次認証データと二次認証データとを対応付けて記憶する第２記憶部と、（Ｇ）一次機能が呼び出された場合に、一次認証データを検証する第１検証部と、（Ｈ）一次認証データに対応する二次認証データを探索する探索部と、（Ｉ）二次認証データを付して二次機能を呼び出す第２呼び出し部とを有する。上記第２サーバは、（Ｊ）二次認証データと第２鍵データとを対応付けて記憶する第３記憶部と、（Ｋ）二次機能が呼び出された場合に、二次認証データを検証する第２検証部と、（Ｌ）二次認証データに対応する第２鍵データを特定する第１特定部と、（Ｍ）二次機能によって生成された二次レスポンスの少なくとも一部データを、第２鍵データで暗号化する暗号化部と、（Ｎ）暗号化データを含む二次レスポンスを二次呼び出し元の第１サーバへ送信する第１送信部とを有する。上記第１サーバは、（Ｏ）暗号化データを含む二次レスポンスを受信する第１受信部と、（Ｐ）暗号化データを含み、一次機能によって生成された一次レスポンスを一次呼び出し元のアプリケーション装置へ送信する第２送信部とをさらに有する。上記アプリケーション装置は、（Ｑ）暗号化データを含む一次レスポンスを受信する第２受信部と、（Ｒ）一次レスポンスの契機である一次呼び出しに付した一次認証データに対応する第１鍵データを特定する第２特定部と、（Ｅ）第１鍵データを用いて、暗号化データを復号する復号部とをさらに有する。

このようにすれば、秘匿化された二次レスポンスを、適正なアクセス権限に基づいて復元できるようになる。

更に、上記アプリケーション装置は、（Ｔ）第１サーバから受信してユーザ端末に転送する二次機能に関する認可要求に、第２鍵データを付して転送する転送部をさらに有するようにしてもよい。上記第２サーバは、（Ｕ）認可要求に応じたリダイレクトによってユーザ端末から第２鍵データを受信する第３受信部と、（Ｖ）二次機能の呼び出しに関する二次認証データを生成した際に、二次認証データに第２鍵データを紐付ける紐付け部とをさらに有するようにしてもよい。

このようにすれば、アプリケーション装置から受けた鍵データを適正なアクセス権限と対応付けられる。

更に、第１鍵データ及び第２鍵データとは、対称暗号化方式における共通鍵であってもよい。

このようにすれば、対称暗号化方式を採用できる。

更に、第１鍵データは、非対称暗号化方式における復号鍵であってもよく、第２鍵データは、非対称暗号化方式における暗号化鍵であってもよい。

このようにすれば、非対称暗号化方式を採用できる。

本実施の形態に係る情報処理装置は、（Ｗ）自ら提供する機能の利用に関する同意画面へのアクセスにおいて鍵データを受信する受信部と、（Ｘ）同意画面の送信先から受信した認可通知に基づいて発行する認証データと鍵データとを紐付ける紐付け部と、（Ｙ）機能が呼び出されたときに、当該呼び出しに付された認証データに対応する鍵データを用いて、上記機能によるレスポンスの少なくとも一部を暗号化する暗号化部とを有する。

このようにすれば、適正なアクセス権限に基づく鍵データを用いて暗号化できる。

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

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

（付記１）
第１サーバが提供する一次機能を利用する情報処理装置であって、
前記一次機能が利用しようとする二次機能を提供する第２サーバ宛にリダイレクトさせるアクセス先データを、前記第１サーバから受信する受信部と、
前記アクセス先データに暗号化用の鍵データを付してブラウザへ転送して当該ブラウザにリダイレクトさせることで、前記暗号化用の鍵データを前記第２サーバに送る転送部と、
前記一次機能によるレスポンスに含まれる、前記二次機能によるレスポンスの少なくとも一部に基づく暗号化データを前記暗号化用の鍵データに適応した復号用の鍵データを用いて復号する復号部と
を有する情報処理装置。

（付記２）
前記アクセス先データは、前記二次機能の利用に関する同意画面のＵＲＬである
付記１記載の情報処理装置。

（付記３）
前記暗号化用の鍵データ及び前記復号用の鍵データは、対称暗号化方式における共通鍵である
付記１又は２記載の情報処理装置。

（付記４）
前記暗号化用の鍵データは、非対称暗号化方式における暗号化鍵であり、前記復号用の鍵データは、非対称暗号化方式における復号鍵である
付記１又は２記載の情報処理装置。

（付記５）
第１サーバが提供する一次機能を利用するコンピュータに、
前記一次機能が利用しようとする二次機能を提供する第２サーバ宛にリダイレクトさせるアクセス先データを、前記第１サーバから受信し、
前記アクセス先データに暗号化用の鍵データを付してブラウザへ転送して当該ブラウザにリダイレクトさせることで、前記暗号化用の鍵データを前記第２サーバに送り、
前記一次機能によるレスポンスに含まれる、前記二次機能によるレスポンスの少なくとも一部に基づく暗号化データを前記暗号化用の鍵データに適応した復号用の鍵データを用いて復号する
処理を実行させるプログラム。

（付記６）
第１サーバが提供する一次機能を利用するコンピュータにより実行される情報処理方法であって、
前記一次機能が利用しようとする二次機能を提供する第２サーバ宛にリダイレクトさせるアクセス先データを、前記第１サーバから受信し、
前記アクセス先データに暗号化用の鍵データを付してブラウザへ転送して当該ブラウザにリダイレクトさせることで、前記暗号化用の鍵データを前記第２サーバに送り、
前記一次機能によるレスポンスに含まれる、前記二次機能によるレスポンスの少なくとも一部に基づく暗号化データを前記暗号化用の鍵データに適応した復号用の鍵データを用いて復号する
処理を含む情報処理方法。

（付記７）
ネットワークを介して一次機能を提供する第１サーバと、
前記ネットワークを介して二次機能を提供する第２サーバと、
前記一次機能を利用するアプリケーション装置と
を含むアクセス制御システムであって、
前記アプリケーション装置は、
一次認証データと第１鍵データとを対応付けて記憶する第１記憶部と、
前記一次認証データを付して前記一次機能を呼び出す第１呼び出し部と
を有し、
前記第１サーバは、
前記一次認証データと二次認証データとを対応付けて記憶する第２記憶部と、
前記一次機能が呼び出された場合に、前記一次認証データを検証する第１検証部と、
前記一次認証データに対応する前記二次認証データを探索する探索部と、
前記二次認証データを付して前記二次機能を呼び出す第２呼び出し部と
を有し、
前記第２サーバは、
前記二次認証データと第２鍵データとを対応付けて記憶する第３記憶部と、
前記二次機能が呼び出された場合に、前記二次認証データを検証する第２検証部と、
前記二次認証データに対応する前記第２鍵データを特定する第１特定部と、
前記二次機能によって生成された二次レスポンスの少なくとも一部データを、前記第２鍵データで暗号化する暗号化部と、
暗号化データを含む前記二次レスポンスを二次呼び出し元の前記第１サーバへ送信する第１送信部と
を有し、
前記第１サーバは、
前記暗号化データを含む前記二次レスポンスを受信する第１受信部と、
前記暗号化データを含み、前記一次機能によって生成された一次レスポンスを一次呼び出し元の前記アプリケーション装置へ送信する第２送信部と
をさらに有し、
前記アプリケーション装置は、
前記暗号化データを含む前記一次レスポンスを受信する第２受信部と、
前記一次レスポンスの契機である一次呼び出しに付した前記一次認証データに対応する前記第１鍵データを特定する第２特定部と、
前記第１鍵データを用いて、前記暗号化データを復号する復号部と
をさらに有するアクセス制御システム。

（付記８）
前記アプリケーション装置は、
前記第１サーバから受信してユーザ端末に転送する前記二次機能に関する認可要求に、前記第２鍵データを付して転送する転送部
をさらに有し、
前記第２サーバは、
前記認可要求に応じたリダイレクトによって前記ユーザ端末から前記第２鍵データを受信する第３受信部と、
前記二次機能の呼び出しに関する前記二次認証データを生成した際に、前記二次認証データに前記第２鍵データを紐付ける紐付け部と
をさらに有する付記７記のアクセス制御システム。

（付記９）
前記第１鍵データ及び前記第２鍵データとは、対称暗号化方式における共通鍵である
付記７又は８記載のアクセス制御システム。

（付記１０）
前記第１鍵データは、非対称暗号化方式における復号鍵であり、前記第２鍵データは、非対称暗号化方式における暗号化鍵である
付記７又は８記載のアクセス制御システム。

（付記１１）
自ら提供する機能の利用に関する同意画面へのアクセスにおいて鍵データを受信する受信部と、
前記同意画面の送信先から受信した認可通知に基づいて発行する認証データと前記鍵データとを紐付ける紐付け部と、
前記機能が呼び出されたときに、当該呼び出しに付された前記認証データに対応する前記鍵データを用いて、前記機能によるレスポンスの少なくとも一部を暗号化する暗号化部と
を有する情報処理装置。

（付記１２）
自ら提供する機能の利用に関する同意画面へのアクセスにおいて鍵データを受信し、
前記同意画面の送信先から受信した認可通知に基づいて発行する認証データと前記鍵データとを紐付け、
前記機能が呼び出されたときに、当該呼び出しに付された前記認証データに対応する前記鍵データを用いて、前記機能によるレスポンスの少なくとも一部を暗号化する
処理をコンピュータに実行させるプログラム。

（付記１３）
自ら提供する機能の利用に関する同意画面へのアクセスにおいて鍵データを受信し、
前記同意画面の送信先から受信した認可通知に基づいて発行する認証データと前記鍵データとを紐付け、
前記機能が呼び出されたときに、当該呼び出しに付された前記認証データに対応する前記鍵データを用いて、前記機能によるレスポンスの少なくとも一部を暗号化する
処理を含み、コンピュータにより実行される情報処理方法。

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

Claims (4)

1. 第１サーバが提供する一次機能を利用する情報処理装置であって、
   前記一次機能が利用しようとする二次機能を提供する第２サーバ宛にリダイレクトさせるアクセス先データを、前記第１サーバから受信する受信部と、
   前記アクセス先データに暗号化用の鍵データを付してブラウザへ転送して当該ブラウザにリダイレクトさせることで、前記暗号化用の鍵データを前記第２サーバに送る転送部と、
   前記一次機能によるレスポンスに含まれる、前記二次機能によるレスポンスの少なくとも一部に基づく暗号化データを前記暗号化用の鍵データに適応した復号用の鍵データを用いて復号する復号部と
   を有する情報処理装置。
2. 前記アクセス先データは、前記二次機能の利用に関する同意画面のＵＲＬである
   請求項１記載の情報処理装置。
3. 第１サーバが提供する一次機能を利用するコンピュータに、
   前記一次機能が利用しようとする二次機能を提供する第２サーバ宛にリダイレクトさせるアクセス先データを、前記第１サーバから受信し、
   前記アクセス先データに暗号化用の鍵データを付してブラウザへ転送して当該ブラウザにリダイレクトさせることで、前記暗号化用の鍵データを前記第２サーバに送り、
   前記一次機能によるレスポンスに含まれる、前記二次機能によるレスポンスの少なくとも一部に基づく暗号化データを前記暗号化用の鍵データに適応した復号用の鍵データを用いて復号する
   処理を実行させるプログラム。
4. 第１サーバが提供する一次機能を利用するコンピュータにより実行される情報処理方法であって、
   前記一次機能が利用しようとする二次機能を提供する第２サーバ宛にリダイレクトさせるアクセス先データを、前記第１サーバから受信し、
   前記アクセス先データに暗号化用の鍵データを付してブラウザへ転送して当該ブラウザにリダイレクトさせることで、前記暗号化用の鍵データを前記第２サーバに送り、
   前記一次機能によるレスポンスに含まれる、前記二次機能によるレスポンスの少なくとも一部に基づく暗号化データを前記暗号化用の鍵データに適応した復号用の鍵データを用いて復号する
   処理を含む情報処理方法。

Images