JP7294158B2 - 情報処理システム、情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Description

本発明は、情報処理システム、情報処理装置、情報処理方法及び情報処理プログラムに関する。

現在、ユーザリソースを提供するＷｅｂ ＡＰＩ(Application Programming Interface)の公開が広がっている。図１４は、ＷｅｂアプリのＷｅｂ ＡＰＩ呼出動作の一例を示す説明図である。Ｗｅｂブラウザは、Ｗｅｂアプリにリクエストを送信すると、リクエストに対するＷｅｂアプリからのレスポンス画面（ＨＴＭＬコンテンツ）を表示する。これに対して、Ｗｅｂ ＡＰＩを利用する場合には、Ｗｅｂアプリが利用者のリクエストを受けると、Ｗｅｂ ＡＰＩを公開しているサーバに対してリクエストを送信する。そして、Ｗｅｂアプリが、Ｗｅｂ ＡＰＩを公開しているサーバからＪＳＯＮ等のデータを受け取ることで、利用者が操作するＷｅｂブラウザに対して必要な画面を表示することになる。

Ｗｅｂ ＡＰＩを呼び出してデータを受け取る場合には、Ｗｅｂ ＡＰＩに対するリクエストはＷｅｂアプリから送信されることになるため、このリクエストが本当に利用者の同意があるか否かをＷｅｂ ＡＰＩ側では認識できない。そこで、ＷｅｂアプリがＷｅｂ ＡＰＩからのデータを取得する場合には、Ｗｅｂアプリにデータを提供する利用者の同意を利用者に確認する必要がある。

そこで、利用者の同意を確認する技術としてＯＡｕｔｈがある。ＯＡｕｔｈは、Ｗｅｂアプリがユーザリソースにアクセスするために、利用者（リソースオーナ）がＷｅｂアプリのユーザリソースへのアクセスを認可する仕組みである。図１５は、ＯＡｕｔｈ認可処理に関わる認可システムの処理動作の一例を示すシーケンス図である。Ｗｅｂブラウザ２０１は、Ｗｅｂアプリ２０２にリクエストを要求する（ステップＳ２０１）。Ｗｅｂアプリ２０２は、リクエストに応じて認可要求をＷｅｂブラウザ２０１に要求する（ステップＳ２０２）。Ｗｅｂブラウザ２０１は、Ｗｅｂアプリ２０２からの認可要求を認可サーバ２０３に要求する（ステップＳ２０３）。

認可サーバ２０３は、Ｗｅｂアプリ２０２からの認可要求に応じて認可確認をＷｅｂブラウザ２０１に提供する（ステップＳ２０４）。Ｗｅｂブラウザ２０１は、認可確認に応じて認可確認画面２１０を表示する。図１６は、認可確認画面２１０の一例を示す説明図である。図１６に示す認可確認画面２１０は、例えば、「ＷｅｂアプリＸＸＸがリソースＹＹＹへのアクセスを要求しています。」の認可要求内容２１１と、その認可要求内容２１１に同意する場合のＯＫボタン２１２と、その認可要求内容２１１に同意しない場合のＮＧボタン２１３とを有する。利用者は、Ｗｅｂブラウザ２０１に表示する認可確認画面２１０を参照する。

Ｗｅｂブラウザ２０１は、利用者の認可確認画面２１０上のＯＫボタン２１２の操作を検出した場合、利用者の同意を認可サーバ２０３に送信する（ステップＳ２０５）。認可サーバ２０３は、利用者の同意を検出した場合、認可コードをＷｅｂブラウザ２０１に発行する（ステップＳ２０６）。尚、認可コードは、認可サーバ２０３が管理するリソースサーバ２０４にアクセスするためのアクセストークン発行を許可するためのコードである。

Ｗｅｂブラウザ２０１は、認可サーバ２０３からの認可コードをＷｅｂアプリ２０２に送信する（ステップＳ２０７）。更に、Ｗｅｂアプリ２０２は、Ｗｅｂブラウザ２０１からの認可コードを認可サーバ２０３に送信する（ステップＳ２０８）。

認可サーバ２０３は、認可コードを受信した場合、受信した認可コードが自分で発行済の認可コードであるか否かを判定する（ステップＳ２０９）。認可サーバ２０３は、認可コードが自分で発行済の認可コードの場合、Ｗｅｂアプリ２０２に対してアクセストークンを発行する（ステップＳ２１０）。更に、Ｗｅｂアプリ２０２は、認可サーバ２０３が発行したアクセストークンをリソースサーバ２０４に送信する（ステップＳ２１１）。その結果、Ｗｅｂアプリ２０２は、アクセストークンを用いてリソースサーバ２０４内のユーザリソースにアクセスできる。そして、Ｗｅｂブラウザ２０１は、Ｗｅｂアプリ２０２Ａ経由でリソースサーバ２０４内のユーザリソースにアクセスすることになる。

特開２０１７－９１２０７号公報

ＯＡｕｔｈでは、リソースアクセス毎に認可確認画面での利用者の同意操作が必要となる。例えば、５回のリソースアクセスを実行する場合には、認可確認画面での利用者の同意操作が５回必要となる。従って、利用者の操作負担が大きくなる。

１つの側面では、リソースへアクセスする際の利用者の操作負担を軽減できる情報処理システム等を提供することを目的とする。

１つの側面の情報処理システムは、代理サーバと、端末装置と、認可サーバとを有する。代理サーバは、記憶部と、第１の送信部とを有する。記憶部は、アクセス対象である複数のリソースの数を記憶する。第１の送信部は、前記複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバそれぞれから受信した前記アクセスに関する通知の数と、前記リソースの数との一致に応じて、前記リソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む第１の情報を端末装置へ送信する。第１の送信部は、前記端末装置から受信した、前記リソースへのアクセスの許可に必要な複数の確認コードを含む第２の情報を前記複数の認可サーバそれぞれに対して送信する。端末装置は、出力部と、第２の送信部とを有する。出力部は、前記代理サーバから受信した前記第１の情報と、前記認可サーバそれぞれから受信した複数の前記確認コードとに基づいて生成した画面を出力する。第２の送信部は、前記出力に対して入力を受け付けた情報に応じて生成された前記第２の情報を、前記代理サーバへ送信する。認可サーバは、第３の送信部と、判定部とを有する。第３の送信部は、前記端末装置からの前記確認コードの発行要求の受信に応じて、前記端末装置に対して前記確認コードを送信する。判定部は、前記代理サーバから受信した前記第２の情報に基づいて前記リソースに対するアクセスを許可するか否かを判定する。

１つの側面によれば、リソースへアクセスする際の利用者の操作負担を軽減できる。

図１は、本実施例の認可システムの一例を示す説明図である。 図２は、代理サーバのハードウェア構成の一例を示す説明図である。 図３は、代理サーバの機能構成の一例を示す説明図である。 図４は、端末装置のハードウェア構成の一例を示す説明図である。 図５は、端末装置の機能構成の一例を示す説明図である。 図６は、認可サーバのハードウェア構成の一例を示す説明図である。 図７は、認可サーバの機能構成の一例を示す説明図である。 図８は、Ｗｅｂサーバのハードウェア構成の一例を示す説明図である。 図９は、Ｗｅｂサーバの機能構成の一例を示す説明図である。 図１０は、確認コードを含むＷｅｂ画面の一例を示す説明図である。 図１１は、集約認可確認画面の一例を示す説明図である。 図１２は、確認コード入力済みの集約認可確認画面の一例を示す説明図である。 図１３Ａは、認可処理に関わる認可システムの処理動作の一例を示すシーケンス図である。 図１３Ｂは、認可処理に関わる認可システムの処理動作の一例を示すシーケンス図である。 図１４は、ＷｅｂアプリのＷｅｂ ＡＰＩ呼出動作の一例を示す説明図である。 図１５は、ＯＡｕｔｈ認可処理に関わる認可システムの処理動作の一例を示すシーケンス図である。 図１６は、認可確認画面の一例を示す説明図である。 図１７は、先行出願の認可システムの一例を示す説明図である。 図１８は、先行出願の認可確認画面の一例を示す説明図である。 図１９Ａは、先行出願の認可処理に関わる認可システムの処理動作の一例を示すシーケンス図である。 図１９Ｂは、先行出願の認可処理に関わる認可システムの処理動作の一例を示すシーケンス図である。

以下、図面に基づいて、本願の開示する情報処理システム等の実施例を詳細に説明する。尚、各実施例により、開示技術が限定されるものではない。また、以下に示す各実施例は、矛盾を起こさない範囲で適宜組み合わせても良い。

本出願人は、利用者のリソースアクセスへの同意に要する操作負担を軽減するために、１回の同意操作で複数のリソースへのアクセスに一括で同意できる認可システムを提案している。

図１７は、先行出願の認可システム３００の一例を示す説明図である。図１７に示す認可システム３００は、利用者の端末装置３０１と、Ｗｅｂサーバ３０２と、代理サーバ３０３と、複数の認可サーバ３０４とを有する。端末装置３０１は、Ｗｅｂブラウザ３０１Ａを実装している。Ｗｅｂサーバ３０２は、Ｗｅｂアプリ３０２Ａを提供するサーバである。代理サーバ３０３は、Ｗｅｂブラウザ３０１Ａと各認可サーバ３０４との間で処理を代理するサーバである。認可サーバ３０４は、ユーザリソース３０５と接続し、認可サーバ３０４の認可に応じてＷｅｂブラウザ３０１ＡからＷｅｂアプリ３０２Ａ経由でのユーザリソース３０５へのアクセスを許可する。

図１９Ａ及び図１９Ｂは、先行出願の認可処理に関わる認可システム３００の処理動作の一例を示すシーケンス図である。認可処理の前処理としては、利用者がＷｅｂブラウザ３０１Ａから認可サーバ３０４にログインしておくものとする。尚、認可サーバ３０４にログインしていない場合には、Ｗｅｂブラウザ３０１Ａから認可サーバ３０４へリクエストが送信されたとき、その要求が正当な利用者から送信されたものかを認可サーバ３０４側では判断できない。従って、Ｗｅｂブラウザ３０１Ａから認可サーバ３０４へのログインが成功した後、以下の処理手順が実行されることになる。

Ｗｅｂブラウザ３０１Ａは、利用者の操作に応じたリクエストをＷｅｂアプリ３０２Ａに送信する（ステップＳ３０１）。Ｗｅｂアプリ３０２Ａは、当該リクエストに応じてユーザリソースにアクセスする場合、確認コード、必要認可数及び認可セッションＩＤを生成する（ステップＳ３０２）。確認コードは、例えば、乱数として生成されるコードである。必要認可数は、アクセス対象のユーザリソースに応じて認可が必要とされる数である。認可セッションＩＤは、各Ｗｅｂブラウザ３０１Ａとのセッションを識別するための情報である。すなわち、当該処理手順で行われる全ての通信には認可セッションＩＤが紐づけられている。複数のＷｅｂアプリ３０２Ａが同様の処理手順を行った場合でも、認可セッションＩＤに基づいて、いずれのＷｅｂアプリ３０２Ａからのリソース要求であるのかが識別できる。

Ｗｅｂアプリ３０２Ａは、確認コード（対象確認コード）を表示するＷｅｂ画面のＨＴＭコンテンツと、必要認可数（対象必要認可数）と、認可セッションＩＤ（対象認可セッションＩＤ）とを含む応答をＷｅｂブラウザ３０１Ａに送信する（ステップＳ３０３）。

Ｗｅｂブラウザ３０１Ａは、当該応答を受信した場合、当該応答に含まれているＨＴＭＬコンテンツに基づいて、Ｗｅｂ画面を表示する（ステップＳ３０４）。Ｗｅｂ画面は、確認コードを表示している。利用者は、Ｗｅｂ画面を参照することで、確認コードを認識できる。

Ｗｅｂブラウザ３０１Ａは、対象認可セッションＩＤ及び対象必要認可数を代理サーバ３０３に送信する（ステップＳ３０５）。代理サーバ３０３は、対象認可セッションＩＤ及び対象必要認可数を受信した場合、対象必要認可数を対象認可セッションＩＤに関連付けて記憶しておく。

更に、Ｗｅｂブラウザ３０１Ａは、アクセス対象のリソースのアクセスを認可する認可サーバ３０４－１に対して、ワンタイムトークン（ＯＴ）発行要求１を送信する（ステップＳ３０６）。尚、ＯＴ発行要求１には、対象認可セッションＩＤ及び対象確認コードが含まれる。説明の便宜上、アクセス対象のリソースのアクセスを認可する認可サーバ３０４は、例えば、認可サーバ３０４－１及び３０４－Ｎとする。認可サーバ３０４－１は、ＯＴ発行要求１を受信した場合、ＯＴ発行要求１に含まれている対象認可セッションＩＤに関連付けて対象確認コードを記憶する。認可サーバ３０４－１は、例えば、ランダムなワンタイムトークン（ＯＴ１）を生成し、ＯＴ１を対象認可セッションＩＤに関連付けて記憶する（ステップＳ３０７）。従って、認可サーバ３０４－１は、対象確認コード及びＯＴ１の組合せが対象認可セッションＩＤに関連付けられて記憶している。

認可サーバ３０４－１は、対象認可セッションＩＤ及びＯＴ１と、リダイレクト先を代理サーバ３０３とするリダイレクト命令とを含む応答をＷｅｂブラウザ３０１Ａへ送信する（ステップＳ３０８）。Ｗｅｂブラウザ３０１Ａは、当該リダイレクト命令に応じて、対象認可セッションＩＤ及びＯＴ１を代理サーバ３０３へ送信する（ステップＳ３０９）。代理サーバ３０３は、対象認可セッションＩＤ及びＯＴ１を受信した場合、ＯＴ１を、対象認可セッションＩＤ及び認可サーバ３０４－１のＵＲＬに関連付けて記憶する。尚、認可サーバ３０４－１のＵＲＬは、リダイレクトされたＯＴ１等の送信元の情報として、ＨＴＴＰに基づいて特定可能である。

代理サーバ３０３は、認可サーバ３０４－１のＵＲＬ宛の認可要求１を生成し、当該認可要求１を認可サーバ３０４－１に送信する（ステップＳ３１０）。認可サーバ３０４－１は、認可要求１を受信した場合、代理サーバ３０３に認可確認１を送信する（ステップＳ３１１）。代理サーバ３０３は、認可サーバ３０４－１からの認可確認画面のＨＴＭＬコンテンツを取得する（ステップＳ３１２）。

また、Ｗｅｂブラウザ３０１Ａは、アクセス対象のリソースのアクセスを認可する認可サーバ３０４－Ｎに対して、ＯＴ発行要求Ｎを送信する（ステップＳ３０６Ａ）。認可サーバ３０４－Ｎは、例えば、ランダムなワンタイムトークン（ＯＴＮ）を生成し、ＯＴＮを対象認可セッションＩＤに関連付けて記憶する（ステップＳ３０７Ａ）。従って、認可サーバ３０４－Ｎは、対象確認コード及びＯＴＮの組合せが対象認可セッションＩＤに関連付けられて記憶している。

認可サーバ３０４－Ｎは、対象認可セッションＩＤ及びＯＴＮと、リダイレクト先を代理サーバ３０３とするリダイレクト命令とを含む応答をＷｅｂブラウザ３０１Ａへ送信する（ステップＳ３０８Ａ）。Ｗｅｂブラウザ３０１Ａは、当該リダイレクト命令に応じて、対象認可セッションＩＤ及びＯＴＮを代理サーバ３０３へ送信する（ステップＳ３０９Ａ）。代理サーバ３０３は、対象認可セッションＩＤ及びＯＴＮを受信した場合、ＯＴＮを、対象認可セッションＩＤ及び認可サーバ３０４－ＮのＵＲＬに関連付けて記憶する。

代理サーバ３０３は、認可サーバ３０４－ＮのＵＲＬ宛の認可要求を生成し、当該認可要求Ｎを認可サーバ３０４－Ｎに送信する（ステップＳ３１０Ａ）。認可サーバ３０４－Ｎは、認可要求Ｎを受信した場合、代理サーバ３０３に認可確認Ｎを送信する（ステップＳ３１１Ａ）。代理サーバ３０３は、認可サーバ３０４－Ｎからの認可確認画面のＨＴＭＬコンテンツを取得する（ステップＳ３１２Ａ）。

代理サーバ３０３は、各認可サーバ３０４（３０４－１，３０４－Ｎ）からの認可確認画面のＨＴＭＬコンテンツの数が必要認可数に一致したか否かを判定する（ステップＳ３１３）。代理サーバ３０３は、認可確認画面のＨＴＭＬコンテンツの数が必要認可数に一致した場合、各認可サーバ３０４からの認可確認画面のＨＴＭＬコンテンツを集約又は統合する。そして、代理サーバ３０３は、認可確認画面のＨＴＭＬコンテンツを集約又は統合することで、利用者に提示するための図１８に示す集約認可確認画面３１０のＨＴＭＬコンテンツを生成する。図１８は、先行出願の集約認可確認画面３１０の一例を示す説明図である。図１８に示す集約認可確認画面３１０は、確認コード３１１と、認可要求内容３１２と、確認コード入力欄３１３と、送信ボタン３１４とを有する。確認コード３１１は、Ｗｅｂアプリ３０２Ａでランダムに生成するコードである。認可要求内容３１２は、例えば、「ＷｅｂアプリＸＸＸが以下のリソースへのアクセスを要求しています。リソース（１）、リソース（２）…」等の内容である。確認コード入力欄３１３は、利用者が認可要求内容３１２の内容に同意する場合に表示中の確認コード３１１を入力する欄である。送信ボタン３１４は、確認コード入力欄３１３に入力済みの確認コード３１１を代理サーバ３０１に送信するボタンである。

代理サーバ３０３は、図１８に示す集約認可確認画面３１０のＨＴＭＬコンテンツをＷｅｂブラウザ３０１Ａに送信する（ステップＳ３１４）。Ｗｅｂブラウザ３０１Ａは、集約認可確認画面３１０のＨＴＭＬコンテンツを受信した場合（ステップＳ３１５）、図１８に示す集約認可確認画面３１０を表示する。その結果、利用者は、集約認可確認画面３１０内の認可要求内容３１２を参照することで、Ｗｅｂアプリ３０２Ａがどのユーザリソースに対してアクセスを要求しているのかを認識できる。

利用者は、集約認可確認画面３１０内の各認可要求内容３１２を確認し、認可要求内容３１２に同意する場合、表示中の正しい確認コード（対象確認コード）３１１を確認コード入力欄３１３に入力し、送信ボタン３１４を押下する。これに対して、利用者は、認可要求内容３１２に同意しない場合、正しくない確認コードを確認コード入力欄３１３に入力し、送信ボタン３１４を押下する。その結果、利用者は、複数の認可サーバ３０４－１及び３０４－Ｎに対する同意又は拒否を１回の同意操作で実現できる。

図１９ＢにおいてＷｅｂブラウザ３０１Ａは、集約認可確認画面３１０内の確認コード入力欄３１３内に確認コードを入力し、送信ボタン３１４のボタン操作を検出する（ステップＳ３２１）。Ｗｅｂブラウザ３０１Ａは、送信ボタン３１４のボタン操作を検出した場合、確認コード入力欄３１３に入力された文字列（入力確認コード）及び対象認可セッションＩＤを含むリクエストを代理サーバ３０３に送信する（ステップＳ３２２）。

代理サーバ３０３は、入力確認コード及び対象認可セッションＩＤを含むリクエストを受信した場合、認可サーバ３０４毎に対象認可セッションＩＤ及び入力確認コードを含む同意１を送信する（ステップＳ３２３）。つまり、代理サーバ３０３は、対象認可セッションＩＤに関連付けられているＯＴと、当該ＯＴに関連付けられている認可サーバ３０４のＵＲＬを取得する。そして、代理サーバ３０３は、ＯＴに関連付けられている認可サーバ３０４のＵＲＬ宛に当該ＯＴ及び入力確認コードと、対象認可セッションＩＤとを含む同意１を認可サーバ３０４に送信する。

例えば、代理サーバ３０３は、ＯＴ１に対応する認可サーバ３０４－１のＵＲＬ宛にＯＴ１、入力確認コード及び認可セッションＩＤを含む同意１を送信する（ステップＳ３２３）。同様に、代理サーバ３０３は、ＯＴＮに対応する認可サーバ３０４－ＮのＵＲＬ宛にＯＴＮ、入力確認コード及び認可セッションＩＤを含む同意Ｎを送信する（ステップＳ３２３Ａ）。その結果、代理サーバ３０３は、必要認可数分（Ｎ個分）の同意１～Ｎが送信されることになる。代理サーバ３０３は、必要認可数分の同意１～Ｎが各認可サーバ３０４－１及び３０４－Ｎに送信した後、同意送信完了をＷｅｂブラウザ３０１Ａに送信する（ステップＳ３２４）。

例えば、認可サーバ３０４－１は、同意１を受信した場合、当該同意１に含まれているＯＴ１及び入力確認コードの組合せと、当該対象認可セッションＩＤに関連付けられて記憶されているＯＴ１及び対象確認コードの組合せとを比較する。そして、認可サーバ３０４－１は、比較結果に基づき、当該同意１の正当性を確認する（ステップＳ３２５）。

認可サーバ３０４－１は、同意１に含まれるＯＴ１及び入力確認コードの少なくともいずれか一方が、ＯＴ１又は対象確認コードと異なる場合、同意１が不当と判断し、認可コードを発行しない。また、認可サーバ３０４－１は、同意１に含まれるＯＴ１及び入力確認コードの組合せと、当該対象認可セッションＩＤに関連付けられて記憶されているＯＴ１及び対象確認コードの組合せとが一致する場合、同意１が正当と判断する。そして、認可サーバ３０４－１は、同意１が正当と判断した場合、認可コード１を代理サーバ３０３に発行する（ステップＳ３２６）。

代理サーバ３０３は、認可コード１を受信した場合、当該認可コード１及び対象認可セッションＩＤをＷｅｂブラウザ３０１Ａに送信する（ステップＳ３２７）。Ｗｅｂブラウザ３０１Ａは、認可コード１及び対象認可セッションＩＤをＷｅｂアプリ３０２Ａに送信する（ステップＳ３２８）。Ｗｅｂアプリ３０２Ａは、認可コード１及び対象認可セッションＩＤを認可サーバ３０４－１に送信する（ステップＳ３２９）。

認可サーバ３０４－１は、認可コードを受信した場合、受信した認可コードが自分で発行済の認可コード１と一致するか否かを判定する（ステップＳ３３０）。認可サーバ３０４－１は、受信した認可コードが自分で発行済の認可コード１と一致する場合、アクセストークン１をＷｅｂアプリ３０２Ａに発行する（ステップＳ３３１）。Ｗｅｂアプリ３０２Ａは、アクセストークン１の受取通知１をＷｅｂブラウザ３０１Ａに送信する（ステップＳ３３２）。その結果、Ｗｅｂアプリ３０２Ａは、アクセストークン１を使用して認可サーバ３０４－１が管理するユーザリソースにアクセスできる。

また、認可サーバ３０４－Ｎは、同意Ｎに含まれるＯＴＮ及び入力確認コードの少なくともいずれか一方が、ＯＴＮ又は対象確認コードと異なる場合、同意Ｎが不当と判断し、認可コードＮを発行しない。また、認可サーバ３０４－Ｎは、同意Ｎに含まれるＯＴＮ及び入力確認コードの組合せと、当該対象認可セッションＩＤに関連付けられて記憶されているＯＴＮ及び対象確認コードの組合せとが一致する場合、同意Ｎが正当と判断する。そして、認可サーバ３０４－Ｎは、同意Ｎが正当と判断した場合、認可コードＮを代理サーバ３０３に発行する（ステップＳ３２６Ａ）。

代理サーバ３０３は、認可コードＮを受信した場合、当該認可コードＮ及び対象認可セッションＩＤをＷｅｂブラウザ３０１Ａに送信する（ステップＳ３２７Ａ）。Ｗｅｂブラウザ３０１Ａは、認可コードＮ及び対象認可セッションＩＤをＷｅｂアプリ３０２Ａに送信する（ステップＳ３２８Ａ）。Ｗｅｂアプリ３０２Ａは、認可コードＮ及び対象認可セッションＩＤを認可サーバ３０４－Ｎに送信する（ステップＳ３２９Ａ）。

認可サーバ３０４－Ｎは、認可コードを受信した場合、受信した認可コードが自分で発行済の認可コードＮと一致するか否かを判定する（ステップＳ３３０Ａ）。認可サーバ３０４－Ｎし、受信した認可コードが自分で発行済の認可コードＮと一致する場合、アクセストークンＮをＷｅｂアプリ３０２Ａに発行する（ステップＳ３３１Ａ）。Ｗｅｂアプリ３０２Ａは、アクセストークンＮの受取通知ＮをＷｅｂブラウザ３０１Ａに送信する（ステップＳ３３２Ａ）。その結果、Ｗｅｂアプリ３０２Ａは、アクセストークンＮを使用して認可サーバ３０４－Ｎが管理するユーザリソースにアクセスできる。

認可システム３００では、代理サーバ３０３が認可サーバ３０４から送られる認可確認画面のＨＴＭＬコンテンツを集約することで、集約認可確認画面３１０をＷｅｂブラウザ３０１Ａに送信する。利用者は、複数回の同意操作を行うことなく、集約認可確認画面３１０上の１回の同意操作（確認コード入力操作）で複数のリソースへのアクセスに同意する。その結果、リソースへのアクセスに対する利用者の同意の操作負担を軽減できる。

つまり、先行出願の認可システム３００では、確認コードを用いて代理サーバ３０３が勝手な同意を防止している。確認コードは、Ｗｅｂアプリ３０２Ａがその値を生成し、Ｗｅｂ画面に表示するため、利用者の同意があるまでは代理サーバ３０３側で確認コードの値を認識できない。従って、代理サーバ３０３は、認可サーバ３０４に対して同意を伝えることができない。

しかしながら、Ｗｅｂアプリ３０２Ａと代理サーバ３０３とが共謀した場合には、Ｗｅｂアプリ３０２Ａが生成した確認コードを代理サーバ３０３と共有できるため、共有した確認コードを用いて利用者の同意があったように見せかけることができる。その結果、Ｗｅｂアプリ３０２Ａは、代理サーバ３０３と共謀することで、利用者の同意がない場合でも、ユーザリソースにアクセスできてしまう。

そこで、このような事態に対処する実施の形態につき以下に説明する。

認可システム１では、認可サーバ５が確認コードを発行することで、代理サーバ４及びＷｅｂアプリ３Ａが共謀した場合でも、代理サーバ４及びＷｅｂアプリ３Ａでは確認コードが認識できないため、利用者の同意なしのリソースへの不正アクセスを回避できる。

図１は、本実施例の認可システム１の一例を示す説明図である。図１に示す認可システム１は、端末装置２と、Ｗｅｂサーバ３と、代理サーバ４と、複数の認可サーバ５と、通信網６とを有する。端末装置２は、Ｗｅｂサーバ３で提供されるＷｅｂアプリ３Ａを利用する利用者の端末である。端末装置２は、Ｗｅｂアプリ３Ａの画面を表示するためのＷｅｂブラウザ２Ａを実装している。端末装置２は、例えば、ＰＣ(Personal Computer)、スマートフォン又はタブレット端末等の端末装置である。

Ｗｅｂサーバ３は、例えば、Ｗｅｂアプリ３Ａを提供する、少なくとも１以上のコンピュータである。代理サーバ４は、例えば、Ｗｅｂサーバ３と端末装置２との間の処理を代理する、少なくとも１以上のコンピュータである。認可サーバ５は、例えば、ＯＡｕｔｈの認可処理を実行する、例えば、１以上のコンピュータである。尚、説明の便宜上、認可サーバ５は、Ｗｅｂアプリ３ＡがＷｅｂ ＡＰＩを用いてアクセス対象となる利用者のリソースを管理するリソースサーバを含むものとする。尚、認可サーバ５は、リソースサーバを含むのではなく、リソースサーバと接続しても良く、適宜変更可能である。通信網６は、端末装置２、Ｗｅｂサーバ３、代理サーバ４や認可サーバ５との間を通信で接続する、例えば、インターネット等の通信網である。

図２は、代理サーバ４のハードウェア構成の一例を示す説明図である。図２に示す代理サーバ４は、通信インタフェース１１と、ＨＤＤ（Hard Disk Drive）１２と、ＲＯＭ(Read Only Memory)１３と、ＲＡＭ(Random Access Memory)１４と、ＣＰＵ(Central Processing Unit)１５と、バス１６とを有する。通信インタフェース１１は、通信網６との間の通信を司るインタフェースである。ＨＤＤ１２は、各種情報を記憶する。ＲＯＭ１３は、各種プログラム等を記憶する。ＲＡＭ１４は、各種情報を記憶する。ＣＰＵ１５は、代理サーバ４全体を制御する。バス１６は、通信インタフェース１１、ＨＤＤ１２、ＲＯＭ１３、ＲＡＭ１４及びＣＰＵ１５と相互に接続する制御線等のラインである。代理サーバ４での処理を実現するプログラムは、例えば、ＨＤＤ１２やＲＯＭ１３等に記録されているものとする。ＣＰＵ１５は、例えば、ＲＯＭ１３に記録されたプログラムをＲＡＭ１４に展開し、ＲＡＭ１４上で各種プログラムに対応した機能プロセスを実行することになる。

図３は、代理サーバ４の機能構成の一例を示す説明図である。図３に示す代理サーバ４は、第１の記憶部４Ａと、機能プロセスとして、第１の送信部４Ｂとを有する。第１の記憶部４Ａは、例えば、ＲＡＭ１４に記憶するものとする。第１の記憶部４Ａは、アクセス対象である複数のリソースの数である必要認可数を記憶する。第１の記憶部４Ａは、対象認可セッションＩＤ及び対象必要認可数を受信した場合、対象必要認可数を対象認可セッションＩＤに関連付けて記憶する。認可セッションＩＤは、各Ｗｅｂブラウザ２Ａとのセッションを識別するための情報である。第１の記憶部４Ａは、対象認可セッションＩＤ及び、認可サーバ５が発行した後述するワンタイムトークン（ＯＴ）を受信した場合、ＯＴを、対象認可セッションＩＤ及び認可サーバ３０４のＵＲＬに関連付けて記憶する。

第１の送信部４Ｂは、複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバ５それぞれから受信したアクセスに関する通知である認可確認の数と、必要認可数とを比較する。第１の送信部４Ｂは、認可確認の数と必要認可数との一致に応じて、リソースに関する情報である認可要求内容、または、リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む第１の情報（認可要求内容）を端末装置２のＷｅｂブラウザ２Ａに送信する。認可要求内容は、アクセス対象のリソースへのアクセス同意を利用者に要求する内容である。第１の送信部４Ｂは、Ｗｅｂブラウザ２Ａから受信した、リソースへのアクセスの許可に必要な複数の確認コードを含む結合コードを複数の認可サーバ５それぞれに対して送信する。確認コードは、認可サーバ５毎に発行するコードである。

図４は、端末装置２のハードウェア構成の一例を示す説明図である。図４に示す端末装置２は、通信インタフェース１１Ａと、ＨＤＤ１２Ａと、ＲＯＭ１３Ａと、ＲＡＭ１４Ａと、ＣＰＵ１５Ａと、バス１６Ａとを有する。通信インタフェース１１Ａは、通信網６との間の通信を司るインタフェースである。ＨＤＤ１２Ａは、各種情報を記憶する。ＲＯＭ１３Ａは、各種プログラム等を記憶する。ＲＡＭ１４Ａは、各種情報を記憶する。ＣＰＵ１５Ａは、端末装置２全体を制御する。バス１６Ａは、通信インタフェース１１Ａ、ＨＤＤ１２Ａ、ＲＯＭ１３Ａ、ＲＡＭ１４Ａ及びＣＰＵ１５Ａと相互に接続する制御線等のラインである。端末装置２での処理を実現するプログラムは、例えば、ＨＤＤ１２ＡやＲＯＭ１３Ａ等に記録されているものとする。ＣＰＵ１５Ａは、例えば、ＲＯＭ１３Ａに記録されたプログラムをＲＡＭ１４Ａに展開し、ＲＡＭ１４Ａ上で各種プログラムに対応した機能プロセスを実行することになる。

図５は、端末装置２の機能構成の一例を示す説明図である。図５に示す端末装置２は、機能プロセスとして、出力部２Ｂと、第２の送信部２Ｃとを有する。出力部２Ｂは、代理サーバ４から受信した第１の情報（認可要求内容）と、認可サーバ５それぞれから受信した複数の確認コードとに基づいて生成した画面である、図１１及び図１２に示す集約認可確認画面を出力する。第２の送信部２Ｃは、図１２に示す集約認可確認画面上の確認コード入力欄に入力した複数の確認コードを含む結合コードを代理サーバ４に送信する。

図６は、認可サーバ５のハードウェア構成の一例を示す説明図である。図７に示す認可サーバ５は、通信インタフェース１１Ｂと、ＨＤＤ１２Ｂと、ＲＯＭ１３Ｂと、ＲＡＭ１４Ｂと、ＣＰＵ１５Ｂと、バス１６Ｂとを有する。通信インタフェース１１Ｂは、通信網６との間の通信を司るインタフェースである。ＨＤＤ１２Ｂは、各種情報を記憶する。ＲＯＭ１３Ｂは、各種プログラム等を記憶する。ＲＡＭ１４Ｂは、各種情報を記憶する。ＣＰＵ１５Ｂは、認可サーバ５全体を制御する。バス１６Ｂは、通信インタフェース１１Ｂ、ＨＤＤ１２Ｂ、ＲＯＭ１３Ｂ、ＲＡＭ１４Ｂ及びＣＰＵ１５Ｂと相互に接続する制御線等のラインである。認可サーバ５での処理を実現するプログラムは、例えば、ＨＤＤ１２ＢやＲＯＭ１３Ｂ等に記録されているものとする。ＣＰＵ１５Ｂは、例えば、ＲＯＭ１３Ｂに記録されたプログラムをＲＡＭ１４Ｂに展開し、ＲＡＭ１４Ｂ上で各種プログラムに対応した機能プロセスを実行することになる。

図７は、認可サーバ５の機能構成の一例を示す説明図である。図５に示す認可サーバ５は、機能プロセスとして、第３の送信部５Ａと、判定部５Ｂとを有する。更に、認可サーバ５は、第２の記憶部５Ｃを有する。第２の記憶部５Ｃは、例えば、ＲＡＭ１４Ｂに記憶するものとする。第３の送信部５Ａは、Ｗｅｂブラウザ２Ａからの確認コードの発行要求であるＯＴ発行要求の受信に応じて、Ｗｅｂブラウザ２Ａに対して確認コードを送信する。判定部５Ｂは、代理サーバ４から受信した結合コードに基づいてリソースに対するアクセスを許可するか否かを判定する。判定部５Ｂは、結合コードの一部に自分が発行した確認コードがあるか否かを判定する。判定部５Ｂは、結合コードの一部に自分が発行した確認コードがある場合、リソースに対するアクセスを許可するアクセストークンを発行する。また、判定部５Ｂは、結合コードの一部に自分が発行した確認コードがない場合、リソースに対するアクセスを拒否する。

第２の記憶部５Ｃは、Ｗｅｂブラウザ２Ａから送信された認可セッションＩＤと、認可サーバ５自身が発行した確認コードと、認可サーバ５自身が発行するワンタイムトークン（ＯＴ）とを対応付けて記憶する。ワンタイムトークンは、利用者の代理として、アクセス対象のリソースへのアクセス同意・拒否を行うだけの権限を表すトークンである。

図８は、Ｗｅｂサーバ３のハードウェア構成の一例を示す説明図である。図８に示すＷｅｂサーバ３は、通信インタフェース１１Ｃと、ＨＤＤ１２Ｃと、ＲＯＭ１３Ｃと、ＲＡＭ１４Ｃと、ＣＰＵ１５Ｃと、バス１６Ｃとを有する。通信インタフェース１１Ｃは、通信網６との間の通信を司るインタフェースである。ＨＤＤ１２Ｃは、各種情報を記憶する。ＲＯＭ１３Ｃは、各種プログラム等を記憶する。ＲＡＭ１４Ｃは、各種情報を記憶する。ＣＰＵ１５Ｃは、Ｗｅｂサーバ３全体を制御する。バス１６Ｃは、通信インタフェース１１Ｃ、ＨＤＤ１２Ｃ、ＲＯＭ１３Ｃ、ＲＡＭ１４Ｃ及びＣＰＵ１５Ｃと相互に接続する制御線等のラインである。Ｗｅｂサーバ３での処理を実現するプログラムは、例えば、ＨＤＤ１２ＣやＲＯＭ１３Ｃ等に記録されているものとする。ＣＰＵ１５Ｃは、例えば、ＲＯＭ１３Ｃに記録されたプログラムをＲＡＭ１４Ｃに展開し、ＲＡＭ１４Ｃ上で各種プログラムに対応した機能プロセスを実行することになる。

図９は、Ｗｅｂサーバ３の機能構成の一例を示す説明図である。図９に示すＷｅｂサーバ３は、機能プロセスとして、必要認可数生成部３Ｂと、認可セッションＩＤ生成部３Ｃと、認可画面生成部３Ｄと、第４の送信部３Ｅとを有する。更に、Ｗｅｂサーバ３は、代理サーバ情報記憶部３Ｆと、認可サーバ情報記憶部３Ｇとを有する。代理サーバ情報記憶部３Ｆ及び認可サーバ情報記憶部３Ｇは、例えば、ＲＡＭ１４Ｃ上に記憶するものとする。

必要認可数生成部３Ｂは、一連の認可要求で通信を行う認可サーバ５の数を示す必要認可数を生成する。認可セッションＩＤ生成部３Ｃは、認可要求が一連のものであることを示す認可セッションＩＤを生成する。代理サーバ情報記憶部３Ｆは、認可セッションＩＤ、必要認可数及び代理サーバ４のＵＲＬを対応付けて記憶する。認可サーバ情報記憶部３Ｇは、認可セッションＩＤ、認可サーバ５のＵＲＬ、認可コード及びアクセストークン等を記憶する。認可画面生成部３Ｄは、複数の認可サーバ５からの確認コード及び、代理サーバ４が集約した認可要求の集約認可確認画面のＨＴＭＬコンテンツを生成する。第４の送信部３Ｅは、Ｗｅｂブラウザ２Ａの要求に応じて、アクセス対象の必要認可数及び認可セッションＩＤを代理サーバ４に送信する。

図１０は、確認コードを含むＷｅｂ画面３０の一例を示す説明図である。図１０に示すＷｅｂ画面３０は、認可要求内容を表示するフレーム３１と、確認コードを表示するフレーム３２とを有する。フレーム３１は、代理サーバ４が生成する認可要求内容が表示する領域である。フレーム３２は、認可サーバ５が生成する確認コードが表示する領域である。各認可サーバ５は、Ｗｅｂブラウザ２ＡからのＯＴ発行要求を検出すると、確認コード及びＯＴを生成する。各認可サーバ５は、確認コードを生成した場合、図１０に示すＷｅｂ画面３０上の認可サーバ５に対応するフレーム３２に確認コードを表示するＨＴＭＬコンテンツを生成する。代理サーバ４は、認可要求内容を生成した場合、図１０に示すＷｅｂ画面３０上のフレーム３１に認可要求内容を表示するＨＴＭＬコンテンツを生成する。

図１１は、集約認可確認画面３０Ａの一例を示す説明図である。代理サーバ４は、各認可サーバ５からの認可要求に対する認可確認を検出した場合、認可確認の認可要求内容を記憶する。代理サーバ４は、認可要求に対する認可確認を検出した場合、認可確認数が必要認可数に一致するか否かを判定する。代理サーバ４は、認可確認数が必要認可数に一致した場合、認可要求内容を生成する。代理サーバ４は、全ての認可要求内容を集約した集約認可確認画面３０ＡのＨＴＭＬコンテンツを生成する。代理サーバ４は、集約認可確認画面３０ＡのＨＴＭＬコンテンツに基づき、図１１に示す集約認可確認画面３０Ａを端末装置２のＷｅｂブラウザ２Ａ上に表示する。集約認可確認画面３０Ａは、確認コード４１と、認可要求内容４２と、確認コード入力欄４３と、送信ボタン４４とを有する。確認コード４１は、認可サーバ５でランダムに生成するコードである。認可要求内容４２は、例えば、「ＷｅｂアプリＸＸＸが以下のリソースへのアクセスを要求しています。」等の要求内容４２Ａと、「以下のリソース」の内容を示す「リソース（１）、リソース（２）…」等の詳細内容４２Ｂとを有する。認可要求内容４２は、代理サーバ４が生成する内容である。確認コード入力欄４３は、利用者が認可要求内容４２の内容に同意する場合に表示中の確認コード４１（結合コード）を入力する欄である。送信ボタン４４は、確認コード入力欄４３に入力済みの複数の確認コード４１を含む結合コードを代理サーバ４に送信するボタンである。

図１２は、確認コード入力済みの集約認可確認画面３０Ａの一例を示す説明図である。利用者は、図１２に示す集約認可確認画面３０Ａ上に表示された認可要求内容４２に同意する場合、全ての認可サーバ５からの確認コード４１の組合せ値、すなわち結合コードを集約認可確認画面３０Ａ上の確認コード入力欄４３に入力する。そして、利用者は、確認コード入力欄４３に結合コードを入力した後、送信ボタン４４をボタン操作する。Ｗｅｂブラウザ２Ａは、送信ボタン４４のボタン操作を検出した場合、確認コード入力欄４３に入力した結合コードを各認可サーバ５に送信する。

各認可サーバ５は、Ｗｅｂブラウザ２Ａからの結合コードを検出した場合、結合コード内に自分が発行した確認コードがあるか否かを判定する。各認可サーバ５は、結合コード内に自分が発行した確認コードがある場合、利用者の同意があると判断する。

図１３Ａ及び図１３Ｂは、認可処理に関わる認可システム１の処理動作の一例を示すシーケンス図である。認可処理の前処理としては、利用者がＷｅｂブラウザ２Ａから認可サーバ５にログインしておくものとする。尚、認可サーバ５にログインしていない場合には、Ｗｅｂブラウザ２Ａから認可サーバ５へリクエストが送信されたとき、その要求が正当な利用者から送信されたものかを認可サーバ５側では判断できない。従って、Ｗｅｂブラウザ２Ａから認可サーバ５へのログインが成功した後、以下の処理手順が実行されることになる。

Ｗｅｂブラウザ２Ａは、Ｗｅｂアプリ３Ａにリクエストを要求する（ステップＳ１１）。Ｗｅｂアプリ３Ａは、リクエストを検出した場合（ステップＳ１１：Ｙｅｓ）、必要認可数及び認可セッションＩＤを生成する（ステップＳ１２）。当該処理手順で行われる全ての通信には認可セッションＩＤが紐づけられており、複数のＷｅｂアプリ３Ａが同様の処理手順を行った場合でも、認可セッションＩＤに基づいて、いずれのＷｅｂアプリ３Ａからのリソース要求であるのかが識別できる。Ｗｅｂアプリ３Ａは、必要認可数及び認可セッションＩＤをＷｅｂブラウザ２Ａに送信する（ステップＳ１３）。その結果、Ｗｅｂブラウザ２Ａは、図１０に示す認可サーバ５と通信するための必要認可数相当のフレームを表示するＷｅｂ画面を表示する。尚、認可セッションＩＤは、複数のＷｅｂアプリ３Ａが同様の処理フローを実行した場合、認可セッションＩＤを利用することで、どのＷｅｂアプリ３Ａからのリソース要求であるか否かを識別できる。更に、Ｗｅｂブラウザ２Ａは、必要認可数及び認可セッションＩＤを代理サーバ４に送信する（ステップＳ１４）。代理サーバ４は、対象認可セッションＩＤ及び対象必要認可数を受信した場合、対象必要認可数を対象認可セッションＩＤに関連付けて記憶しておく。

更に、Ｗｅｂブラウザ２Ａは、アクセス対象のリソースを管理する認可サーバ５－１にＯＴ発行要求１を送信する（ステップＳ１５）。尚、ＯＴ発行要求１には、対象認可セッションＩＤが含まれる。説明の便宜上、アクセス対象のリソースのアクセスを認可する認可サーバ５は、例えば、認可サーバ５－１及び５－Ｎとする。Ｗｅｂブラウザ２Ａは、Ｎ個の認可サーバ５に対して、代理サーバ４が利用者の代わりに１回の同意を行う権限を取得するＯＴ発行要求を送信する。

認可サーバ５－１は、ＯＴ発行要求１に応じて、認証セッションＩＤに対応した認可サーバ５－１のＯＴ１及び確認コード１を生成する（ステップＳ１６）。認可サーバ５－１は、ＯＴ１及び確認コード１をＷｅｂブラウザ２Ａに送信する（ステップＳ１７）。

Ｗｅｂブラウザ２Ａは、受信した確認コード１を表示した後、XMLHttpRequest等を使用し、ＯＴ１及び認可セッションＩＤを代理サーバ４に送信する（ステップＳ１８）。代理サーバ４は、認可セッションＩＤ及びＯＴ１を受信した場合、ＯＴ１を、認可セッションＩＤ及び認可サーバ５－１のＵＲＬに関連付けて記憶する。尚、認可サーバ５－１のＵＲＬは、ＯＴ１等の送信元の情報として、ＨＴＴＰに基づいて特定可能である。代理サーバ４は、認可セッションＩＤ及びＯＴ１に応じて認可サーバ５－１のＵＲＬ宛の認可要求１を生成し、認可要求１を認可サーバ５－１に送信する（ステップＳ１９）。認可サーバ５－１は、認可要求１に応じて認可確認１を代理サーバ４に送信する（ステップＳ２０）。

また、Ｗｅｂブラウザ２Ａは、認可サーバ５－ＮにＯＴ発行要求Ｎを送信する（ステップＳ１５Ａ）。認可サーバ５－Ｎは、ＯＴ発行要求Ｎに応じて、認可サーバ５－ＮのＯＴＮ及び確認コードＮを生成する（ステップＳ１６Ａ）。認可サーバ５－Ｎは、ＯＴＮ及び確認コードＮをＷｅｂブラウザ２Ａに送信する（ステップＳ１７Ａ）。

Ｗｅｂブラウザ２Ａは、ＯＴＮ及び認可セッションＩＤを代理サーバ４に送信する（ステップＳ１８Ａ）。代理サーバ４は、認可セッションＩＤ及びＯＴＮを受信した場合、ＯＴＮを、認可セッションＩＤ及び認可サーバ５－ＮのＵＲＬに関連付けて記憶する。代理サーバ４は、認可セッションＩＤ及びＯＴＮに応じて認可サーバ５－ＮのＵＲＬ宛の認可要求Ｎを生成し、認可要求Ｎを認可サーバ５－Ｎに送信する（ステップＳ１９Ａ）。認可サーバ５－Ｎは、認可要求Ｎに応じて認可確認Ｎを代理サーバ４に送信する（ステップＳ２０Ａ）。

つまり、代理サーバ４は、認可サーバ５毎に認可要求を送信し、各認可サーバ５は、認可要求に応じた認可確認を代理サーバ４に送信する。ステップＳ１５～ステップＳ２０までの処理を認可サーバ５毎に実行することになる。代理サーバ４は、各認可サーバ５から受信した認可確認画面のＨＴＭＬコンテンツの数が必要認可数と一致したか否かを判定する（ステップＳ２１）。代理サーバ４は、認可確認画面のＨＴＭＬコンテンツの数が必要認可数と一致した場合、図１１に示す集約認可確認画面３０ＡのＨＴＭＬコンテンツを生成する（ステップＳ２２）。

代理サーバ４は、集約認可確認画面３０ＡのＨＴＭＬコンテンツをＷｅｂブラウザ２Ａに送信する（ステップＳ２３）。その結果、Ｗｅｂブラウザ２Ａは、図１１に示す集約認可確認画面３０Ａを表示する。利用者は、集約認可確認画面３０Ａ上の認可要求内容４２を参照し、Ｗｅｂアプリ３Ａがアクセス要求しようとするアクセス対象のリソースを認識できる。利用者は、認可要求内容４２に同意する場合、Ｗｅｂブラウザ２Ａに表示中の集約認可確認画面３０Ａ上の確認コード入力欄４３に認可サーバ５毎の全ての確認コード４１（結合コード）を入力する（ステップＳ２４）。Ｗｅｂブラウザ２Ａは、確認コード入力欄４３に入力した複数の確認コード４１を含む結合コードを代理サーバ４に送信する（ステップＳ２５）。

代理サーバ４は、認可サーバ５毎に、認可サーバ５毎のＯＴを使用して結合コードを送信する。代理サーバ４は、認可サーバ５－１のＯＴ１を使用して結合コードを認可サーバ５－１に送信する（ステップＳ２６）。また、代理サーバ４は、認可サーバ５－ＮのＯＴＮを使用して結合コードを認可サーバ５－Ｎに送信する（ステップＳ２６Ａ）。代理サーバ４は、全ての認可サーバ５に対する結合コードの送信が完了した場合、同意送信完了をＷｅｂブラウザ２Ａに送信する（ステップＳ２７）。

認可サーバ５－１は、代理サーバ４から結合コードを受信した場合、結合コード内に自分が発行した確認コード１があるか否かを判定する。認可サーバ５－１は、結合コード内に自分が発行した確認コード１がある場合、利用者がリソースへのアクセスに同意したものと判断し、アクセストークン１を発行するための認可コード１を代理サーバ４に発行する（ステップＳ２８）。代理サーバ４は、発行した認可コード１をＷｅｂブラウザ２Ａに送信する（ステップＳ２９）。

Ｗｅｂブラウザ２Ａは、認可コード１を受信した場合、認可セッションＩＤ、認可コード１をＷｅｂアプリ３Ａに送信する（ステップＳ３０）。Ｗｅｂアプリ３Ａは、認可セッションＩＤで認可コード１を認可サーバ５－１に送信する（ステップＳ３１）。

認可サーバ５－１は、Ｗｅｂブラウザ２Ａからの認可コードを受信した場合、受信した認可コードが自分で発行済の認可コード１と一致するか否かを判定する。更に、認可サーバ５－１は、受信した認可コードが自分で発行済の認可コード１と一致する場合（ステップＳ３２）、アクセストークン１をＷｅｂアプリ３Ａに発行する（ステップＳ３３）。Ｗｅｂアプリ３Ａは、認可サーバ５－１からアクセストークン１を取得した場合、アクセストークン１の受取通知１をＷｅｂブラウザ２Ａに送信する（ステップＳ３４）。その結果、Ｗｅｂアプリ３Ａは、アクセストークン１を使用して認可サーバ５－１が管理するユーザリソースにアクセスできる。

同様に、認可サーバ５－Ｎは、代理サーバ４から結合コードを受信した場合、結合コード内に自分で発行した確認コードＮがあるか否かを判定する。認可サーバ５は、結合コード内に自分で発行した確認コードＮがある場合、アクセストークン２を発行するための認可コードＮを代理サーバ４に発行する（ステップＳ２８Ａ）。代理サーバ４は、発行した認可コードＮをＷｅｂブラウザ２Ａに送信する（ステップＳ２９Ａ）。

Ｗｅｂブラウザ２Ａは、認可コードＮを受信した場合、認可セッションＩＤ、認可コードＮをＷｅｂアプリ３Ａに送信する（ステップＳ３０Ａ）。Ｗｅｂアプリ３Ａは、認可セッションＩＤで認可コードＮを認可サーバ５－Ｎに送信する（ステップＳ３１Ａ）。

認可サーバ５－Ｎは、Ｗｅｂブラウザ２Ａからの認可コードＮを受信した場合、受信した認可コードが自分で発行済の認可コードＮと一致するか否かを判定する。更に、認可サーバ５－Ｎは、受信した認可コードが自分で発行済の認可コードＮと一致する場合（ステップＳ３２Ａ）、アクセストークンＮをＷｅｂアプリ３Ａに発行する（ステップＳ３３Ａ）。Ｗｅｂアプリ３Ａは、認可サーバ５－ＮからアクセストークンＮを取得した場合、アクセストークンＮの受取通知ＮをＷｅｂブラウザ２Ａに送信する（ステップＳ３４Ａ）。その結果、Ｗｅｂアプリ３Ａは、アクセストークンＮを使用して認可サーバ５－Ｎが管理するユーザリソースにアクセスできる。

実施例１の代理サーバ４は、複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバ５それぞれから受信したアクセスに関する通知である認可確認の数と、必要認可数との一致に応じて、認可要求内容をＷｅｂブラウザ２Ａに送信する。代理サーバ４は、Ｗｅｂブラウザ２Ａから受信した、リソースへのアクセスの許可に必要な複数の確認コードを含む結合コードを複数の認可サーバ５それぞれに対して送信する。Ｗｅｂブラウザ２Ａは、代理サーバ４から提供された集約認可確認画面３０Ａ上に複数の確認コードを含む結合コードを入力し、結合コードを認可サーバ５に送信する。各認可サーバ５は、確認コードの発行要求に応じて、Ｗｅｂブラウザ２Ａに対して確認コードを送信する。各認可サーバ５は、代理サーバ４から受信した結合コードに基づき、リソースに対するアクセスを許可するか否かを判定する。その結果、各認可サーバ５が確認コードを発行することになるため、代理サーバ４及びＷｅｂアプリ３Ａが共謀した場合でも、代理サーバ４及びＷｅｂアプリ３Ａでは確認コードが認識できない。従って、Ｗｅｂアプリ３Ａが利用者の同意なしによるリソースへの不正アクセスを回避できる。また、リソースへアクセスする際の利用者の操作負担を軽減できる。

また、結合コードは、複数の認可サーバ５から受信した全ての複数の確認コードの情報を含む。つまり、利用者は、集約認可確認画面３０Ａ上の認可要求内容を参照しながら、表示中の認可サーバ５毎の確認コードを確認コード入力欄４３に入力するため、１回の同意操作で複数のリソースへのアクセスに同意できる。

認可サーバ５は、結合コードの一部に自分が発行した確認コードが含まれる場合、認可コードを発行した。その結果、認可サーバ５は、代理サーバ４からの結合コードで認可コードの発行可否を判断できる。

先行発明では、Ｗｅｂアプリが確認コードを生成及び表示し、確認コードの値の一致/不一致を認可サーバが確認している。これに対して、本実施例では、認可サーバ５が確認コードを生成し、確認コードの値をＷｅｂ画面中のフレームに表示することで、利用者に確認コードを提示している。また、認可確認時には、複数の認可サーバ５が生成した確認コードをまとめた値、すなわち結合コードを認可サーバ５に送信する。更に、認可サーバ５は、結合コード内に自身が発行した確認コードがあるか否かを確認することで、認可コードの発行可否を判断できる。

先行発明では、Ｗｅｂアプリと代理サーバとが共謀した場合、Ｗｅｂアプリが利用者の同意なく、勝手にリソースにアクセスできる。これに対して、本実施例では、利用者の同意に必要となる確認コードを認可サーバ５が生成することで、Ｗｅｂアプリ３Ａと代理サーバ４とが共謀した場合でも、確認コードが把握できないため、利用者の同意なくリソースに勝手にアクセスすることができない。従って、利用者の同意なしによるリソースへのアクセスを回避できる。

尚、説明の便宜上、２台の認可サーバ５が管理する２個のリソースにアクセスする場合、各認可サーバ５が発行した各確認コードを集約認可確認画面３０Ａに表示し、集約認可確認画面３０Ａ上に２個の確認コードを含む結合コードを入力する場合を例示した。しかしながら、Ｎ台の認可サーバ５が管理するＮ個のリソースにアクセスする場合、各認可サーバ５が発行したＮ個の確認コードを集約認可確認画面３０Ａに表示し、集約認可確認画面３０Ａ上のＮ個の確認コードを含む結合コードを入力すればよく、適宜変更可能である。

また、本実施例では、Ｗｅｂブラウザ２ＡがＷｅｂアプリ３Ａを使用して認可サーバ５のリソースにアクセスする場合を例示したが、Ｗｅｂブラウザ２Ａが認可サーバ５のリソースにアクセスしても良く、適宜変更可能である。

本実施例では、認可サーバ５が管理するリソースにアクセスする場合を例示したが、認可サーバ５が管理するリソースサーバを備え、リソースサーバ内のリソースにアクセスする形態に適用しても良く、適宜変更可能である。

本実施例では、集約認可確認画面３０ＡをＷｅｂブラウザ２Ａに提示したが、リソースに関する認可要求内容をＷｅｂブラウザ２Ａに通知し、何らかの操作で認可要求内容の同意を代理サーバ４に通知しても良く、適宜変更可能である。

また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）やＦＰＧＡ（Field Programmable Gate Array）等上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ等で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良い。

各種情報を記憶する領域は、例えば、ＲＯＭ（Read Only Memory）や、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）、ＭＲＡＭ（Magnetoresistive Random Access Memory）やＮＶＲＡＭ（Non-Volatile Random Access Memory）等のＲＡＭ（Random Access Memory）で構成しても良い。

１ 認可システム
２ 端末装置
２Ａ Ｗｅｂブラウザ
２Ｂ 出力部
２Ｃ 第２の送信部
３ Ｗｅｂサーバ
３Ａ Ｗｅｂアプリ
３Ｅ 第４の送信部
４ 代理サーバ
４Ａ 第１の記憶部
４Ｂ 第１の送信部
５ 認可サーバ
５Ａ 第３の送信部
５Ｂ 判定部

Claims (14)

1. アクセス対象である複数のリソースの数を記憶する記憶部と、
   前記複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバそれぞれから受信した前記アクセスに関する通知の数と、前記リソースの数との一致に応じて、前記リソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む第１の情報を端末装置へ送信し、
   前記端末装置から受信した、前記リソースへのアクセスの許可に必要な複数の確認コードを含む第２の情報を前記複数の認可サーバそれぞれに対して送信する第１の送信部と、
   を有する代理サーバと、
   前記代理サーバから受信した前記第１の情報と、前記認可サーバそれぞれから受信した複数の前記確認コードとに基づいて生成した画面を出力する出力部と、
   前記出力に対して入力を受け付けた情報に応じて生成された前記第２の情報を、前記代理サーバへ送信する第２の送信部と、
   を有する端末装置と、
   前記端末装置からの前記確認コードの発行要求の受信に応じて、前記端末装置に対して前記確認コードを送信する第３の送信部と、
   前記代理サーバから受信した前記第２の情報に基づいて前記リソースに対するアクセスを許可するか否かを判定する判定部と、
   を有する認可サーバと、
   を有することを特徴とする情報処理システム。
2. 前記第２の情報は、
   前記複数の認可サーバから受信した全ての複数の前記確認コードの情報を含むことを特徴とする請求項１に記載の情報処理システム。
3. 前記判定部は、
   前記第２の情報の一部に前記端末装置に対して送信した前記確認コードが含まれるか否かに応じて判定することを特徴とする請求項１に記載の情報処理システム。
4. 前記端末装置からの要求に応じて前記アクセス対象のリソースの数を前記代理サーバに送信する第４の送信部を有するＷｅｂサーバを有することを特徴とする請求項１に記載の情報処理システム。
5. 代理サーバと、端末装置と、認可サーバとを有する情報処理システム内の代理サーバが、
   アクセス対象である複数のリソースの数を記憶し、
   前記複数のリソースそれぞれに対するアクセスの許可を行う複数の前記認可サーバそれぞれから受信した前記アクセスに関する通知の数と、前記リソースの数との一致に応じて、前記リソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む第１の情報を前記端末装置へ送信し、
   前記端末装置から受信した、前記リソースへのアクセスの許可に必要な複数の確認コードを含む第２の情報を複数の複数の認可サーバそれぞれに対して送信する
   処理を実行し、
   前記端末装置が、
   前記代理サーバから受信した前記第１の情報と、前記認可サーバそれぞれから受信した複数の前記確認コードとに基づいて生成した画面を出力し、
   前記出力に対して入力を受け付けた情報に応じて生成された前記第２の情報を、前記代理サーバへ送信する
   処理を実行し、
   前記認可サーバは、
   前記端末装置からの前記確認コードの発行要求の受信に応じて、前記端末装置に対して前記確認コードを送信し、
   前記代理サーバから受信した前記第２の情報に基づいて前記リソースに対するアクセスを許可するか否かを判定する
   処理を実行することを特徴とする情報処理方法。
6. アクセス対象である複数のリソースの数を記憶する記憶部と、
   前記複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバそれぞれから受信した前記アクセスに関する通知の数と、前記リソースの数との一致に応じて、前記リソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む第１の情報を端末装置へ送信し、
   前記端末装置から受信した、前記リソースへのアクセスの許可に必要な複数の確認コードを含む第２の情報を前記複数の認可サーバそれぞれに対して送信する送信部と、
   を有することを特徴とする情報処理装置。
7. 情報処理装置が、
   アクセス対象である複数のリソースの数を記憶し、
   前記複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバそれぞれから受信した前記アクセスに関する通知の数と、前記リソースの数との一致に応じて、前記リソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む第１の情報を端末装置へ送信し、
   前記端末装置から受信した、前記リソースへのアクセスの許可に必要な複数の確認コードを含む第２の情報を前記複数の認可サーバそれぞれに対して送信する、
   処理を実行することを特徴とする情報処理方法。
8. アクセス対象である複数のリソースの数を記憶し、
   前記複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバそれぞれから受信した前記アクセスに関する通知の数と、前記リソースの数との一致に応じて、前記リソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む第１の情報を端末装置へ送信し、
   前記端末装置から受信した、前記リソースへのアクセスの許可に必要な複数の確認コードを含む第２の情報を前記複数の認可サーバそれぞれに対して送信する、
   処理を情報処理装置に実行させることを特徴とする情報処理プログラム。
9. アクセス対象であるリソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む、代理サーバから受信した第１の情報と、複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバそれぞれから受信した、前記リソースへのアクセスの許可に必要な複数の確認コードとに基づいて生成した画面を出力する出力部と、
   出力した画面に対して入力を受け付けた情報に応じて生成された、前記複数の確認コードを含む第２の情報を、前記代理サーバへ送信する送信部と、
   を有することを特徴とする情報処理装置。
10. 情報処理装置が、
    アクセス対象であるリソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む、代理サーバから受信した第１の情報と、複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバそれぞれから受信した、前記リソースへのアクセスの許可に必要な複数の確認コードとに基づいて生成した画面を出力し、
    出力した画面に対して入力を受け付けた情報に応じて生成された、前記複数の確認コードを含む第２の情報を、前記代理サーバへ送信する
    処理を実行することを特徴とする情報処理方法。
11. アクセス対象であるリソースに関する情報、または、前記リソースに関する情報に基づいて生成した画面の情報、の少なくともいずれかを含む、代理サーバから受信した第１の情報と、複数のリソースそれぞれに対するアクセスの許可を行う複数の認可サーバそれぞれから受信した、前記リソースへのアクセスの許可に必要な複数の確認コードとに基づいて生成した画面を出力し、
    出力した画面に対して入力を受け付けた情報に応じて生成された、前記複数の確認コードを含む第２の情報を、前記代理サーバへ送信する
    処理を情報処理装置に実行させることを特徴とする情報処理プログラム。
12. 端末装置からのアクセス対象のリソースへのアクセス許可に必要な複数の確認コードの発行要求の受信に応じて、前記端末装置に対して前記確認コードを送信する送信部と、
    前記端末装置から入力した複数の確認コードを含む第２の情報を代理サーバ経由で受信し、受信した前記第２の情報に基づいて前記リソースに対するアクセスを許可するか否かを判定する判定部と、
    を有することを特徴とする情報処理装置。
13. 情報処理装置が、
    端末装置からのアクセス対象のリソースへのアクセス許可に必要な複数の確認コードの発行要求の受信に応じて、前記端末装置に対して前記確認コードを送信し、
    前記端末装置から入力した複数の確認コードを含む第２の情報を代理サーバ経由で受信し、受信した前記第２の情報に基づいて前記リソースに対するアクセスを許可するか否かを判定する
    処理を実行することを特徴とする情報処理方法。
14. 端末装置からのアクセス対象のリソースへのアクセス許可に必要な複数の確認コードの発行要求の受信に応じて、前記端末装置に対して前記確認コードを送信し、
    前記端末装置から入力した複数の確認コードを含む第２の情報を代理サーバ経由で受信し、受信した前記第２の情報に基づいて前記リソースに対するアクセスを許可するか否かを判定する
    処理を情報処理装置に実行させることを特徴とする情報処理プログラム。

Images