JP5858796B2

JP5858796B2 - 権限委譲システム、およびその権限委譲システムにおけるサーバーシステム、および権限委譲システムを制御する制御方法

Info

Publication number: JP5858796B2
Application number: JP2012006204A
Authority: JP
Inventors: 存田村
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2012-01-16
Filing date: 2012-01-16
Publication date: 2016-02-10
Anticipated expiration: 2032-01-16
Also published as: US9071601B2; US20130185784A1; JP2013145505A

Description

保護されたリソースにアクセスするユーザーの権限を他の主体に委譲することが可能な権限委譲システム、およびその権限委譲システムにおけるサーバーシステム、および権限委譲システムを制御する制御方法に関する。

クラウドが一般化するに伴い、複数のサービスを連携させて付加価値を創造する機会はますます増加している。サービスを連携させることでサービス提供者は、ユーザーに付加価値を提供することができる。その一方で、サービスが連携することにより、いくつかの課題が生まれる。

即ち、ユーザーが望んだ以上の情報がサービス間でやりとりされないかといったセキュリティの問題であり、ユーザーデータや個人情報の送受信に関する課題である。例えば、インターネット上には複数のサービスが存在し、様々なサービス間でサービス連携が実現される可能性があるが、ユーザーが望んだサービス以外がユーザーデータや個人情報を操作できてはいけない。またサービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。

ＯＡｕｔｈによれば、例えば、サービスＡが管理するデータに外部サービスＢがアクセスする場合は、外部サービスＢからアクセスされる範囲を明らかにした上で、ユーザーの明示的な認可を得ることになっている。ユーザーが認可すると、外部サービスＢはアクセスを認められたことを証明するトークン（以下、認可トークン）を受け取り、以降のアクセスはその認可トークンを用いて実現できる。特許文献１には、委譲先端末の使用者の属性情報がサービス提供条件を満たすか否かを判断し、条件を満たす場合、委譲元端末がアクセス可能なリソースに対する認可トークンを委譲先端末へ発行する技術が開示されている。

認可トークンを用いると、認可を行ったユーザーの権限でサービスＡにアクセスできるが、ユーザーから認可を受け認可トークンを取得したのは外部サービスＢであるため、外部サービスＢはその認可トークンを厳重かつ適正に管理する責務を負う。

また近年のサービスには、ユーザーの持つデータを解析してユーザーに付加価値を提供するものがある。例えば、Ｗｅｂサイトのアクセス解析サービスは、ユーザーの持つデータ（アクセスログ）を解析することで、ユーザーに対してＷｅｂサイトの更新のための指針を示すことができる。

このようにアクセス解析事業者にアクセスログの閲覧を許可することでユーザーはサービスを享受できる。一方で、アクセスログはユーザーの重要な資産でもあるため、任意のアクセス解析事業者がユーザーのアクセスログを閲覧できることは好ましくない。このような場合ユーザーは、サービスＡが管理するアクセスログの閲覧を外部サービスＢに対して認可するのではなく、外部サービスＢを利用してアクセスログを取得する個々のアクセス解析事業者に対して認可を与える必要がある。

特開２００９−１２９２１４

特許文献１のような従来の方法では、サービスＡが管理するアクセスログを外部サービスＢから閲覧できるよう認可を与えることは可能である。またトークン発行時にトークン利用者の妥当性を確認することもできる。しかし発行された認可トークン利用時の共有に関する制御がない。よって、認可トークンの利用範囲を柔軟に変更することができず利便性に欠ける。

また、アクセスログの解析を依頼したいアクセス解析事業者が複数あれば、個別に認可操作を行う必要が発生するので、業者が多ければ多いほど利便性が低下するという問題があった。本発明はこれらの課題の内少なくとも１つ以上の課題を解決することを目的とする。

本願発明の一実施系に係る権限委譲システムは、特定情報を管理する第１のサーバーシステムと、取得された前記特定情報を利用したサービスを提供する第２のサーバーシステムと、認証装置と、前記サービスを利用可能な第１のユーザーが操作するクライアントと、から構成される権限委譲システムであって、前記第１のサーバーシステムにより管理される前記特定情報の利用を認めるための認可トークンの共有範囲を受け付ける受け付け手段と、受け付けた前記共有範囲を基に、前記共有範囲の内の利用者に対して前記認可トークンの共有を許可するか否かを設定するための設定画面を前記クライアントに送信する送信手段と、送信された前記設定画面を介して前記第１のユーザーにより設定された前記認可トークンの共有範囲と、前記認証装置により発行された前記認可トークンと、を紐付けて管理する管理手段と、第２のユーザーが前記サービスを利用する場合に前記第２のサーバーシステムにより使用される認可トークンの共有範囲に前記第２のユーザーが含まれるか否かを判断する判断手段と、前記第２のユーザーが当該認可トークンの共有範囲に含まれると判断され、かつ当該認可トークンが有効であることが確認されたことに応じて、前記第２のサーバーシステムは前記第１のサーバーシステムから前記特定情報を取得し、取得された前記特定情報を利用した前記サービスを前記第２のユーザーに提供することを特徴とする。

本実発明によれば、複数の代行者がユーザーの代わりに作業を行うシステムにおいて、ユーザーは代行者ごとに認可操作を行うことなく、複数の代行者が認可トークンを共有できるようになる。また、認可トークンを利用できる代行者は認可トークン共有範囲で制限されるため、不特定多数の代行者が認可トークンを利用する状況を未然に防ぐことが可能になる。

ネットワーク構成を示す図である。本発明の第１の実施の形態に係るＰＣの構成図である。本発明の第１の実施の形態に係るモジュール構成図である。本発明の第１の実施の形態に係る共有範囲の設定から認可操作までのフローである。本発明の第１の実施の形態に係る共有範囲提示および認可画面例である。本発明の第１の実施の形態に係る認可トークンの発行フローである。本発明の第１の実施の形態に係る認可トークンを用いた処理依頼フローである。本発明の第１の実施の形態に係る共有範囲および認可トークンを管理するデータ例である。本発明の第２の実施の形態に係るモジュール構成図である。本発明の第２の実施の形態に係る共有範囲の設定から認可トークンの取得までのフローである。本発明の第２の実施の形態に係る認可トークンを用いた処理依頼フローである。本発明の第２の実施の形態に係る共有範囲および認可トークンを管理するデータ例である。本発明の第３の実施の形態に係るモジュール構成図である。本発明の第３の実施の形態に係る共有範囲の許可および更新フローである。本発明の第３の実施の形態に係る認可画面例である。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

本実施の形態に係る権限委譲システムは、図１に示すような構成のネットワーク上に実現される。１００は、ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄＷｉｄｅＷｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ（ＬＡＮ１０１）である。

２００および２０１はそれぞれユーザーおよび代行者が操作するクライアントＰＣである。３００は認可サービス、３５０はリソースサービスである。また４００はユーザーの認可に基づき、代行者がユーザーとしてリソースサービス３５０にアクセスするための代行サービスである。リソースサービスは、ユーザーに紐づくリソースを、他ユーザーに利用されないように保護を行っている。特定情報とはこのリソースの一部であって、この特定情報のデータの実体はどのようなデータであっても良い。例えば、デバイスの稼働状況に関する情報や、プリンタが保有している残トナー量に関する情報等が考えられる。特定情報はこのような情報を包含する上位概念である。

またクライアントＰＣ２００、２０１、認可サービス３００、リソースサービス３５０、代行サービス４００はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。なおクライアントＰＣ２００、２０１およびそれぞれのサービスはそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣ上に構成されていてもよい。認可サービス３００、リソースサービス３５０、代行サービス４００は、夫々、認可サーバーシステム、リソースサーバーシステム、代行サーバーシステムと同義である。これらのサーバーシステムは、１台のコンピュータから構成されていても良いし、複数台のコンピュータを仮想化し１台のコンピュータとしても良い。また、同じ機能を持つコンピュータを並列に起動し、多数の要求を分散して並列に処理するサーバーシステムであっても良い。

リソースサービス３５０を利用しているユーザーに代わって、代行者が作業の代行をする場合は、代行の許可は以下の手順で実現される。リソースサービス３５０を利用しているユーザーは第１のユーザーに相当し、そのリソースサービス３５０をその第１のユーザーに代わって利用する代行者が第２のユーザーに相当する。第２のユーザーである第後者は、代行サービス４００のサービスを利用し、リソースサービス３５０が提供するデータを加工させ、その出力結果をその第１のユーザーに相当する顧客に提供する。

代行サービス４００は、始めに、どのユーザーの認可トークンを、どの代行者の間で共有するかの設定を代行者が操作するクライアントを介して受け付ける。次に代行サービス４００は第１のユーザーのアクセスを受け付け、第２のユーザーである代行者が設定した認可トークンの共有範囲の許可を求める。ここで第１のユーザーが許可すると、許可された共有範囲で使用されることとなる認可トークンの発行を認可サービス３００に依頼する。発行された認可トークンは、第１のユーザーと前記認可トークンの共有範囲とをペアにして紐付けて記憶する。更に代行サービス４００は代行者の指示に基づき、第１のユーザーの代わりにリソースサービスにアクセスする。ここでリソースサービスへのアクセスとは、例えば、ユーザーが代行サービスに登録したデータを代行者が代行してリソースサービスへ登録することでもよい。またそれ以外のアクセスでもよい。このように、本来であればサービスを利用できるのは利用ユーザーのみではあるが、利用ユーザーに代わってサービスを享受する代行者に対し、利用ユーザーのみが享受できるサービスを限定的に代行者へ享受させる点が本願発明のポイントである。結果、代行者は、その享受したサービスを基に新たな結果を作り上げ、更により充実した結果をユーザーに提供することも可能になる。特に、第１のユーザーが顧客であり、第２のユーザーに相当する代行者が代行サービスを専門とする業者であればこの効果はより顕著に表れる。通常、代行業者は顧客よりもサービス業務に専門的に従事しており、更に質の高い結果を生み出せるからである。以上の観点からも、今後は顧客が代行業者を利用してサービスを受ける機会は更に増えるであろう。

なお、認可トークンとは、権限が委譲された装置が、委譲された権限の範囲内でサービスを利用、もしくはデータにアクセスすることを可能にするための情報である。認可トークンを表現する形式に制限はなく、数字列、文字列、それらの情報を混合させたもの、果てはそれ以外の識別情報を組み合わせたものであっても良い。認可トークンの有効性が認証サービス３００により検証され、その認可トークンが有効であると検証された場合に限り、権限が委譲された装置は、委譲された権限の範囲内でサービス等を利用できる。

図２は本実施の形態に係る、クライアントＰＣ２００の構成を示す図である。またクライアントＰＣ２０１、認可サービス３００、リソースサービス３５０、代行サービス４００を提供するサーバーコンピューター、またはサーバーシステムを構成するコンピュータの構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のクライアントＰＣ２００およびサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等におけるデータアクセスを制御する。ＮＣ２１２はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムである。

図３は本実施の形態に係る、認可サービス３００、リソースサービス３５０、代行サービス４００のモジュール構成を示す図である。先にも述べた通り、これらのモジュール構成を実現するためのプログラムがメモリにロードされ、ＣＰＵにより実行されることで実現するものである。

図３ａは本実施の形態に係る、認可サービス３００のモジュール構成を示す図である。認可サービス３００は代行サービス連携部３０１、認可要求部３０２、認可管理部３０３、認可トークン検証部３０４、検証結果通知部３０５から構成される。認可要求部３０２はユーザーに認可画面１００１を提示して権限委譲の認可を求める。代行サービス連携部３０１は代行サービス４００から受け取った認可操作識別子に応じて認可管理部３０３で記憶している認可トークンを返す。認可トークン検証部３０４はリソースサービス３５０から受け取った認可トークンを検証し、検証結果通知部３０５がリソースサービス３５０に検証結果を返却する。

図３ｂは本実施の形態に係る、リソースサービス３５０のモジュール構成を示す図である。リソースサービス３５０は認可トークン検証依頼部３５１を持つ。認可トークン検証依頼部３５１は、代行サービス４００から受け取った認可トークンが有効であるか否かの検証を認可サービス３００に依頼する。

図３ｃは本実施の形態に係る、代行サービス４００のモジュール構成を示す図である。代行サービス４００は共有範囲指定部４０１、共有範囲管理部４０２、共有範囲取得部４０３、共有範囲許可要求部４０４を持つ。また認可サービス連携部４０５、認可トークン要求部４０６、認可トークン管理部４０７、代行対象ユーザー受付部４０８、共有範囲検証部４０９、リソースサービス連携部４１０を持つ。

共有範囲指定部４０１は代行者から共有範囲を指定されることで認可トークンの共有範囲を受け付け、共有範囲管理部４０２で認可トークンを利用可能な範囲を規定する共有範囲を記憶、および管理する。ユーザーにアクセスされたことに応じて、共有範囲取得部４０３は共有範囲管理部４０２で管理されている共有範囲を取り出し、共有範囲許可要求部４０４がユーザーに共有範囲確認画面１０００を提示して共有範囲の許可を求める。この共有範囲確認画面１０００は共有範囲管理部４０２で認可トークンと紐付けて管理されている共有範囲を基に生成される画面であり、認可トークンの共有範囲を設定することが可能な設定画面である。認可サービス連携部４０５はユーザーのアクセスを認可サービス３００にリダイレクトさせ、応答として認可操作識別子を受け取る。認可トークン要求部４０６は認可サービス連携部４０５が受け取った認可操作識別子を用いて認可サービス３００に認可トークンの発行を求める。発行された認可トークンは認可トークン管理部４０７が記憶する。なお、共有範囲管理部４０２と認可トークン管理部４０７を切り分ける構成としたが管理部として１つにまとめても良い。何れにせよ、認可トークンと、その認可トークンに対応する共有範囲がわかるように紐付けて管理されていれば良い。

代行対象ユーザー受付部４０８は代行者のアクセスを受け付ける。共有範囲検証部４０９は、アクセスしてきた第２のユーザーである代行者が共有範囲管理部４０２で管理している認可トークンの共有範囲に含まれるか否かを検証する。リソースサービス連携部４１０は認可トークン管理部４０７から取り出した認可トークンを用いてリソースサービス３５０に処理を依頼する。但し、共有範囲検証部４０９による検証の結果、アクセスしてきた第２のユーザーである代行者が共有範囲管理部４０２で管理している認可トークンの共有範囲に含まれないと判断された場合、リソースサービス連携部４１０は認可トークン管理部４０７で管理されている認可トークンを利用することができない。

図４は本実施の形態に係る、代行者による共有範囲の設定からユーザーによる認可操作までのフローである。まず代行者が代行サービス４００にアクセスし、ユーザーを指定して認可トークンの共有範囲を設定する。次に第１のユーザーが代行サービス４００にアクセスすると、前記設定された共有範囲が画面表示される。第１のユーザーが前記設定された範囲での認可トークンの共有を許可すると、第１のユーザーが操作するクライアントは認可サービス３００へとリダイレクトされる。認可サービス３００でユーザーが認可操作を行うと認可操作識別子が発行され、クライアントは認可サービス３００により代行サービス４００にリダイレクトするよう指示され、そして、認可サービス３００で発行された認可操作識別子が代行サービス４００に渡される。

図４ａは本実施の形態に係る、代行サービス４００における代行者による認可トークン共有範囲の設定フローである。ステップＳ１１０１で代行サービス４００の共有範囲指定部４０１は、どのユーザーの認可トークンを共有したいかを示すユーザー識別子と、そのユーザーの認可トークンを共有する利用者、即ち代行者の共有範囲を、代行者のクライアントを介して受け付ける。ステップＳ１１０２で共有範囲管理部４０２は、ステップＳ１１０１で受け付けた代行者の共有範囲の設定を認可トークンの共有範囲とし、ステップＳ１１０１で受け付けたユーザー識別子と紐付けて記憶する。

図４ｂは本実施の形態に係る、代行サービス４００における第１のユーザーによる認可トークン共有範囲の確認および許可フローである。代行者が共有範囲準備を済ませると、第１のユーザーは共有範囲の確認と許可を行う。なお代行者が共有範囲準備を済ませたことは電話や電子メールでユーザーに通知してもよく、その他の手段で通知してもよい。その通知を受けた第１のユーザーが代行サービス４００にアクセスを試みることとする。

以下のフローは代行サービス４００がユーザーに認可トークンの共有範囲の許可を求めるフローである。このフローは第１のユーザーがクライアントのＷｅｂブラウザを用いて代行サービス４００にアクセスすることで開始される。後続のフローで発行される認可トークンは、第１のユーザーによる権限委譲の許可が出されたことで発行されるトークンであり、かつ許可された範囲内の代行者間で共有されて利用される。

ステップＳ１２０１で、代行サービス４００はアクセスしてきた第１のユーザーを特定する。ステップＳ１２０２で、共有範囲取得部４０３は共有範囲管理部４０２から認可トークンの共有範囲情報を取得する。ここで取得する共有範囲情報は、ステップＳ１２０１で特定されたユーザーに紐付けて管理されている共有範囲である。ステップＳ１２０３で、共有範囲許可要求部４０４はステップＳ１２０２で取得した認可トークンの共有範囲情報をユーザーに提示し、共有範囲に対する許可を求める。即ち、共有範囲の内の利用者に対して前記認可トークンの共有を許可するか否かを設定するための設定画面を第１のユーザーが操作するクライアントに送信する。そして、送信された設定画面を介して設定された設定を認可トークンの共有範囲とする。例えば、図５ａに示される共有範囲確認画面１０００は、代行者Ｘ、代行者Ｙ、代行者Ｚが認可トークンの共有をすることをユーザーに許可を求める際の画面であり、共有範囲を設定可能な設定画面である。このユーザーを、ユーザーＡと称する。なお、この設定画面の表示の仕方に制限はなく、その他の表示の仕方でも良い。詳細については別の実施例で説明する。実施例１では、代行者Ｘは、代行者Ｙ、および代行者Ｚが所属する系列企業の親会社に所属する存在であり、これら代行者の代表としてＳ１１０１で共有範囲の指定を行ったものとする。

ステップＳ１２０４で、共有範囲許可要求部４０４は、ステップＳ１２０３でユーザーが共有範囲を許可したか否かを判断する。判断の結果、ユーザーが許可していた場合はステップＳ１２０５に遷移する。ユーザーが許可していなかった場合はここでフローを終了する。ステップＳ１２０５で、共有範囲管理部４０２は、共有範囲識別子を生成し、ユーザー識別子と共有範囲のペアに前記共有範囲識別子を紐付けて記憶する。なお共有範囲識別子はステップＳ１２０５でなく、ステップＳ１１０２でユーザー識別子と共有範囲のペアを記憶する時点で生成しておいてもよい。ステップＳ１２０６で、認可サービス連携部４０５は第１のユーザーからのアクセスを認可サービス３００にリダイレクトさせ、本フローは終了する。その際、リダイレクトをさせるとともに、共有範囲識別子を含め指示を送る。

図４ｃは本実施の形態に係る、認可サービス３００におけるユーザーによる認可の確認フローである。このフローはユーザーが操作するＷｅｂブラウザが、代行サービス４００から認可サービス３００にリダイレクトされることにより開始される。ユーザーが認可を行うと、代行サービス４００に指示を行う代行者が、認可を行ったユーザーとしてリソースサービス３５０にアクセスできるようになる。

ステップＳ１３０１で、認可サービス３００は、代行サービス４００からリダイレクトされアクセスしてきたユーザーを特定する。ステップＳ１３０２で代行サービス連携部３０１は、前記アクセスから共有範囲識別子を取得する。ステップＳ１３０３で認可要求部３０２は、代行サービス４００に指示を行う代行者が、そのユーザーとしてリソースサービス３５０にアクセスするための認可を、ユーザーに求める。ここでは、図５ｂに示される認可画面１００１のような画面が表示される。

ステップＳ１３０４で、認可要求部３０２は、ステップＳ１３０３でユーザーが認可したか否か判断する。ユーザーが認可していた場合はステップＳ１３０５に遷移する。ユーザーが認可していなかった場合はここでフローを終了する。なお、図５ｂの画面でユーザーが許可を押した場合に認可され、拒否を押した場合に認可されなかったこととなる。ステップＳ１３０５で、認可管理部３０３は、ステップＳ１３０３でユーザーが認可したことに対応する認可操作識別子を生成し、記憶する。なお認可に関する付加情報があれば、あわせて認可管理部３０３が記憶してもよい。ステップＳ１３０６で、代行サービス連携部３０１が、ユーザーからのアクセスを代行サービス４００にリダイレクトさせ、本フローは終了する。その際、リダイレクトの指示には、ステップＳ１３０５で生成した認可操作識別子と、ステップＳ１３０２で取り出した共有範囲識別子が含まれる。

図６は本実施の形態に係る、代行サービス４００が認可サービス３００に認可トークンの発行を依頼し、認可サービス３００が認可トークンを発行するフローである。図６ａは本実施の形態に係る、代行サービス４００が認可サービス３００に認可トークンの発行を依頼し、認可トークンを取得するフローである。このフローはユーザーが操作するＷｅｂブラウザが、認可サービス３００での認可操作を終え、認可サービス３００から代行サービス４００にリダイレクトされることにより開始される。ステップＳ１４０１で、代行サービス４００は、認可サービス３００からリダイレクトされアクセスしてきたユーザーを特定する。

ステップＳ１４０２で、認可サービス連携部４０５は、リダイレクトの指示から認可操作識別子と共有範囲識別子を取り出す。ステップＳ１４０３で、認可トークン要求部４０６は、ステップＳ１４０２で取り出した認可操作識別子を認可サービス３００に渡し、応答として認可トークンを受け取る。ステップＳ１４０４で、認可トークン管理部４０７は、ステップＳ１４０２で取り出した共有範囲識別子を用いて、共有範囲管理部４０２で記憶しているユーザー識別子と認可トークンの共有範囲のペアを特定する。ステップＳ１４０５で、認可トークン管理部４０７は、ステップＳ１４０４で特定したユーザー識別子と認可トークンの共有範囲のペアに、ステップＳ１４０３で取得した認可トークンを紐付けて管理する。認可トークンの記憶が完了することで、本フローは終了する。

図６ｂは本実施の形態に係る、認可サービス３００が認可トークンを発行するフローである。ステップＳ１５０１で、認可サービス３００は、代行サービス４００からの認可トークン発行依頼を受け付ける。ステップＳ１５０２で、認可サービス３００は、ステップＳ１５０１で受け付けた認可トークン発行依頼から認可操作識別子を取り出す。ステップＳ１５０３で、認可管理部３０３は、ステップＳ１５０２で取り出した認可操作識別子を、認可管理部３０３で記憶している認可操作識別子と比較する。ステップＳ１５０４で、認可管理部３０３は、ステップＳ１５０３の比較の結果、一致する認可操作識別子を記憶していたか判断する。一致する認可操作識別子を記憶していた場合はステップＳ１５０５に遷移する。記憶していなかった場合は、本フローはここで終了する。ステップＳ１５０５で、認可管理部３０３は、認可トークンを生成して記憶する。また、ステップＳ１５０１で受け付けた認可トークン発行依頼に対する応答として、生成した認可トークンを代行サービス４００に返す。認可トークンを返すと本フローは終了する。

図７は本実施の形態に係る、発行された認可トークンを用いて代行サービス４００がリソースサービス３５０を呼び出して処理を実行させるフローである。まず代行者が代行サービス４００にアクセスし、認可トークンを用いてリソースサービス３５０を呼び出すよう指示する。この呼び出しは認可トークンを用いて行うため、リソースサービス３５０に対する呼び出しは認可トークンに紐付けられたユーザーからの指示であるとして処理される。代行サービス４００が認可トークンを用いてリソースサービス３５０に処理を指示すると、リソースサービス３５０は受け取った認可トークンの検証を認可サービス３００に依頼する。認可トークンが有効なものであれば、リソースサービス３５０は処理を実行する。

図７ａは本実施の形態に係る、代行サービスがリソースサービスを呼び出すフローである。ステップＳ１６０１で、代行サービス４００は代行サービスを利用するためにアクセスしてきた第２のユーザーである代行者を特定する。ステップＳ１６０２で、代行対象ユーザー受付部４０８は、アクセスしてきた代行者がどのユーザーの代行を行うかの指示を受け付ける。ステップＳ１６０３で、共有範囲検証部４０９は、ステップＳ１６０２で指定されたユーザーのユーザー識別子を用いて、共有範囲管理部４０２に問い合わせを行う。共有範囲管理部４０２は、ユーザー識別子に紐付けられた認可トークンの共有範囲設定が存在するか確認する。さらに、その共有範囲にステップＳ１６０１でアクセスしてきた第２のユーザーである代行者が含まれるか否かを確認する。

ステップＳ１６０４で、共有範囲検証部４０９は、ステップＳ１６０３の確認の結果を基に判断を行う。ユーザー識別子に紐付けられた認可トークンの共有範囲設定が存在し、かつその共有範囲にステップＳ１６０１でアクセスしてきた代行者が含まれていた場合はステップＳ１６０５に遷移する。そうでなければステップＳ１６５０に遷移する。ステップＳ１６０５で、認可トークン管理部４０７は、前記ユーザー識別子と認可トークンの共有範囲のペアに紐付けられた認可トークンを記憶しているか確認する。ステップＳ１６０６で、認可トークン管理部４０７は、認可トークンを記憶しているか否かを判断する。認可トークンを記憶していた場合はステップＳ１６０７に遷移する。また記憶していなかった場合はステップＳ１６５０に遷移する。このようにして、第２のユーザーである代行者が代行サービスを利用する場合に代行サービスのサーバーシステムにより使用される認可トークンの共有範囲に、第２のユーザーであるその代行者が含まれているか否かを判断する。判断の方法はこれに限るものではなく、その他の方法は別の実施例で説明する。

ステップＳ１６０７で、認可トークン管理部４０７は、記憶している認可トークンを取り出す。ステップＳ１６０８で、リソースサービス連携部４１０は、ステップＳ１６０７で取り出した認可トークンを使用して、リソースサービス３５０にアクセスを行う。アクセスが完了すると本フローは終了する。ステップＳ１６５０で、代行サービス４００は、代行者に対し代行が行えない旨を通知して処理を終了する。代行が行えなかった理由として考えられるのは、そもそもその代行者は共有範囲を設定する段階で対象外であったか、共有範囲内として設定はされていたが第１のユーザーにより許可されなかった状況が考えられる。本願発明は、以上の構成および処理により、認可トークンを共有できる範囲を柔軟に設定することができる。

図７ｂは本実施の形態に係る、リソースサービス３５０の処理のフローである。ステップＳ１７０１で、リソースサービス３５０は、代行サービス４００からのアクセスを受け付ける。ステップＳ１７０２で、認可トークン検証依頼部３５１は、ステップＳ１７０１のアクセスから認可トークンを取り出す。ステップＳ１７０３で、認可トークン検証依頼部３５１は、ステップＳ１７０２で取り出した認可トークンの有効性の検証を認可サービス３００に依頼し、検証結果を受け取る。ステップＳ１７０４で、認可トークン検証依頼部３５１は、ステップＳ１７０３で受け取った検証結果を確認する。認可トークンが有効なものだという検証結果であればステップＳ１７０５に遷移する。また有効でないという結果であればステップＳ１７５０に遷移する。

ステップＳ１７０５で、リソースサービス３５０は、ステップＳ１７０１で受け付けた代行サービス４００からのアクセスを処理する。処理が完了すると結果を代行サービス４００に返し、フローを終了する。ステップＳ１７５０で、リソースサービス３５０は、ステップＳ１７０１で受け付けた代行サービス４００からのアクセスを拒否し、フローを終了する。

図７ｃは本実施の形態に係る、認可サービス３００における認可トークンの有効性検証のフローである。ステップＳ１８０１で、認可サービス３００は、リソースサービス３５０から認可トークンを受け取る。ステップＳ１８０２で、認可トークン検証部３０４は、ステップＳ１８０１で受け取った認可トークンが有効なものであるか否かを判断する。ここでの判断は、例えば、認可トークンが認可管理部３０３で管理されているものと同一であるか否か、管理されているとすればその認可トークンは有効期限内であるか否か、などの判断が行われる。このように、認可トークンは内容の確認のみではなく、その認可トークンの使用期限も確認することもできる。

ステップＳ１８０３で、認可トークン検証部３０４は、ステップＳ１８０２の判断の結果、ステップＳ１８０１で受け取った認可トークンが有効なものであればステップＳ１８０４に遷移する。また、有効な認可トークンでなければステップＳ１８０５に遷移する。
ステップＳ１８０４で、検証結果通知部３０５は、認可トークンが有効なものだったと代行サービス４００に通知して処理を終了する。ステップＳ１８０５で、検証結果通知部３０５は、認可トークンが有効なものでなかったと代行サービス４００に通知して処理を終了する。

図８は本実施の形態に係る、代行サービス４００で管理されるデータの例である。この例では、ユーザーＫの認可トークンを代行者Ｘおよび代行者Ｙが共有し、その共有範囲は共有範囲識別子ａｂｃ０００１で特定される様子を示している。また前記ユーザー識別子と認可トークンの共有範囲のペアに、認可操作識別子１１１１１０−１２２３３４と認可トークン９８７６５４３２１が紐付けて記憶されている様子も示している。この場合、代行者Ｘおよび代行者Ｙは認可トークン９８７６５４３２１を用いて、ユーザーＫの代わりに、代行サービス４００からリソースサービス３５０に処理を指示することが可能である。しかし代行者Ｚは認可トークン共有範囲に含まれないため、ユーザーＫの代わりに、代行サービス４００からリソースサービス３５０に処理を指示することができない。例えば、代行者Ｚは、図７ａのＳ１６５０のステップを経由したものである。なお、図５に示すように代行者Ｘ，代行者Ｙ、代行者Ｚの利用許可をユーザーＡに対し求めた場合は、ユーザーＡに対応するユーザー識別子と、認可トークン共有範囲として３人の代行者が紐付くことになる。結果、３人の代行者は、ユーザーＡに対して代行サービスを提供可能となる。

本実施の形態によれば、複数の代行者がユーザーの代わりに作業を行う場合でも、ユーザーは代行者ごとに認可操作を行うことなく、複数の代行者が認可トークンを共有できるようになる。また認可トークンを利用できる代行者は認可トークン共有範囲で制限されるため、不特定多数の代行者が認可トークンを利用する問題も発生しない。また認可トークンの共有範囲をユーザーに明示して許可を求めるため、代行者に対する認可をユーザーが意識することもできる。

次に、本発明を実施するための第２の形態について図面を用いて説明する。第２の実施例においては、認可トークンの共有範囲の設定および検証を、認可サービス３００で行う。認可サービス３００に集約することで、代行サービス４００が認可トークンの共有範囲の検証を行う場合と比べ、代行サービス４００が意図せず、あるいは意図して共有範囲の検証を誤り、利用ユーザーが望まない代行者がリソースサービス３５０にアクセスする事態を防げる。

なお、一般的なＯＡｕｔｈの仕組みでは、利用ユーザーである第１のユーザーも、代行者である第２のユーザーも、代行サービス４００を直接操作する。そのため、代行サービス４００は利用ユーザーおよび代行者を識別する識別子を保持している。それに対して、認可サービス３００およびリソースサービス３５０は、代行者に代行者自身の識別子を用いてアクセスされることがないため、代行者の識別子を保持していない。しかし、例えば、代行サービス４００が認可サービス３００およびリソースサービス３５０と同一のセキュリティドメインに属するなどの理由により、認可サービス３００が代行者の識別子も保持している場合を考える。この場合においては、認可サービス３００でも認可トークンの共有範囲の設定および検証を行える。実施例２ではこのような状況を想定している。

次に、実施例２の説明に入るが、第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。図９は本実施の第２の形態に係る、認可サービス３００、リソースサービス３５０、代行サービス４００のモジュール構成を示す図である。

図９ａは本実施の第２の形態に係る、認可サービス３００のモジュール構成を示す図である。認可サービス３００は認可要求部３０２、認可管理部３０３、認可トークン検証部３０４、検証結果通知部３０５を持つ。また第２の共有範囲指定部３０６、第２の共有範囲管理部３０７、第２の代行サービス連携部３０８を持つ。また第２の共有範囲取得部３０９、第２の共有範囲許可要求部３１０、第２の共有範囲検証部３１１を持つ。

第２の共有範囲指定部３０６は代行者から共有範囲の指示を受け、第２の共有範囲管理部３０７で共有範囲を記憶する。利用ユーザーが代行サービス４００からリダイレクトで認可サービス３００にアクセスすると、第２の共有範囲取得部３０９は第２の共有範囲管理部３０７で記憶した共有範囲を取り出し、第２の共有範囲許可要求部３１０がユーザーに共有範囲確認画面１０００を提示して共有範囲の許可を求める。第２の共有範囲検証部３１１はリソースサービス３５０の要求に応じて認可トークンを検証する際に、認可トークンを使用する代行者が共有範囲に含まれるか否かを検証する。

図９ｂは本実施の第２の形態に係る、リソースサービス３５０のモジュール構成を示す図である。リソースサービス３５０は第２の認可トークン検証依頼部３５２を持つ。第２の認可トークン検証依頼部３５２は代行サービス４００から受け取った認可トークンが有効なものか、認可サービス３００に検証を依頼する。

図９ｃは本実施の第２の形態に係る、代行サービス４００のモジュール構成を示す図である。代行サービス４００は認可トークン要求部４０６、代行対象ユーザー受付部４０８を持つ。また第２の認可サービス連携部４１１、第２の認可トークン管理部４１２、第２のリソースサービス連携部４１３を持つ。第２の認可サービス連携部４１１は認可サービス３００から認可トークンを取得し、取得した認可トークンは第２の認可トークン管理部４１２が記憶する。また第２のリソースサービス連携部４１３は、記憶した認可トークンと、代行者情報をリソースサービス３５０に渡して処理を依頼する。

図１０は実施例２に係る、代行者による共有範囲の設定から認可トークンの取得までのフローである。始めに、代行者が認可サービス３５０にアクセスし、利用者である第１のユーザー、およびその第１のユーザーが利用する代行サービスを指定して認可トークンの共有範囲を設定する。次に、第１のユーザーが代行サービス４００にアクセスすると、第１のユーザーが操作するクライアントは認可サービス３００へとリダイレクトされる。認可サービス３００では、代行者により設定された共有範囲が画面表示される。第１のユーザーが、設定された範囲での認可トークンの共有を許可すると、認可画面が表示される。第１のユーザーが認可操作を行うと認可操作識別子が発行され、認可操作識別子が代行サービス４００に渡される。代行サービス４００は認可操作識別子を用いて、認可サービス３００から認可トークンを取得する。

図１０ａは本実施の第２の形態に係る、認可サービス３００における代行者による認可トークン共有範囲の設定フローである。ここでは認可サービス３００が代行者の識別子を保持している。そして、利用ユーザーが望まない代行者がリソースサービス３５０にアクセスする事態を防ぐため、認可サービス３００が認可トークンの共有範囲の設定および検証を行う。ステップＳ２１０１で、認可サービス３００の第２の共有範囲指定部３０６は、どのユーザーの認可トークンを共有したいかを示すユーザー識別子と、そのユーザーの認可トークンを共有する代行者の範囲を、それぞれ代行者から受け付ける。また前記認可トークンを用いてリソースサービス３５０を呼び出し、代行サービスを示す代行サービス識別子も受け付ける。ステップＳ２１０２で、第２の共有範囲管理部３０７は、ステップＳ２１０１で受け付けた代行者の範囲を認可トークン共有範囲として、ステップＳ２１０１で受け付けたユーザー識別子および代行サービス識別子と紐づけて記憶し、フローを終了する。

図１０ｂは本実施の第２の形態に係る、代行サービス４００におけるユーザーによる認可処理の開始フローである。代行者が共有範囲準備を済ませると、ユーザーは共有範囲の確認と許可を行う。なお、代行者が共有範囲準備を済ませたことは電話や電子メールでユーザーに通知してもよく、その他の手段で通知してもよい。以下のフローは代行サービス４００がユーザーに認可処理の実施を求めるフローである。このフローは第１のユーザーがＷｅｂブラウザを用いて代行サービス４００にアクセスすることで開始される。後続のフローで発行される認可トークンは、ユーザーによる許可を受け、ここで許可された範囲の代行者間で共有して利用可能となる。ステップＳ２２０１で、代行サービス４００は、アクセスしてきたユーザーを特定する。ステップＳ２２０２で、第２の認可サービス連携部４１１は、ユーザーからのアクセスを認可サービス３００にリダイレクトさせる、本フローは終了する。その際、リダイレクトの指示には代行サービスを特定するための代行サービス識別子を含まれている。

図１０ｃは本実施の第２の形態に係る、認可サービス３００におけるユーザーによる共有範囲と認可の確認フローである。このフローは第１のユーザーが操作するＷｅｂブラウザが、代行サービス４００から認可サービス３００にリダイレクトされることにより開始される。第１のユーザーが認可を行うと、代行サービス４００のサービスを利用する代行者がリソースサービス３５０にアクセスできるようになる。

ステップＳ１３０１で、認可サービス３００は、代行サービス４００からリダイレクトされアクセスしてきたユーザーを特定する。ステップＳ２３０１で、第２の代行サービス連携部３０８は、アクセスに含まれる代行サービス識別子を取り出す。ステップＳ２３０２で、第２の共有範囲取得部３０９は、ステップＳ１３０１で特定されたユーザーおよびステップＳ２３０１で取り出した代行サービスに紐付けられた、認可トークンの共有範囲を取得する。ステップＳ２３０３で、第２の共有範囲許可要求部３１０は、ステップＳ２３０２で取得した認可トークンの共有範囲情報をユーザーに提示し、共有範囲に対する許可を求める。ここで表示される画面は、図５ａに示される共有範囲確認画面１０００のような画面である。

ステップＳ２３０４で、第２の共有範囲許可要求部３１０は、ステップＳ２３０３でユーザーが共有範囲を許可したか否かを判断する。判断の結果、ユーザーが許可していた場合はステップＳ１３０３に遷移する。ユーザーが許可していなかった場合はここでフローを終了する。ステップＳ２３０５で、第２の代行サービス連携部３０８が、ユーザーからのアクセスを代行サービス４００にリダイレクトさせ、本フローは終了する。その際のリダイレクトには、ステップＳ１３０５で生成された認可操作識別子が含まれる。

図１０ｄは本実施の第２の形態に係る、代行サービス４００が認可サービス３００から認可トークンを取得するフローである。このフローはユーザーが操作するＷｅｂブラウザが、認可サービス３００での認可操作を終え、認可サービス３００から代行サービス４００にリダイレクトされることにより開始される。ステップＳ１４０１で、代行サービス４００は、認可サービス３００からリダイレクトされアクセスしてきたユーザーを特定する。ステップＳ２４０１で、第２の認可サービス連携部４１１は、前記アクセスから認可操作識別子を取り出す。ステップＳ１４０３で、認可トークン要求部４０６は、ステップＳ２４０１で取り出した認可操作識別子を認可サービス３００に渡し、応答として認可トークンを受け取る。ステップＳ２４０２で、第２の認可トークン管理部４１２は、ステップＳ１４０３で取得した認可トークンを記憶する。認可トークンの記憶が完了することで、本フローは終了する。

図１１は本実施の第２の形態に係る、発行された認可トークンを用いて代行サービス４００がリソースサービス３５０を呼び出して処理を実行させるフローである。まず代行者が代行サービス４００にアクセスし、認可トークンを用いてリソースサービス３５０を呼び出すよう指示する。この呼び出しは認可トークンを使用して行うため、リソースサービス３５０に対する呼び出しは認可トークンに紐付けられたユーザーからの指示であるとして処理される。代行サービス４００が認可トークンを用いてリソースサービス３５０に処理を指示すると、リソースサービス３５０は受け取った認可トークンの検証を認可サービス３００に依頼する。認可トークンが有効なものであれば、リソースサービス３５０は処理を実行する。

図１１ａは本実施の第２の形態に係る、代行サービスがリソースサービスを呼び出すフローである。ステップＳ２６０１で、第２の認可トークン管理部４１２は、ステップＳ１６０２で代行者が指定したユーザーのユーザー識別子に紐付けられた認可トークンを記憶しているか確認する。ステップＳ２６０２で、第２の認可トークン管理部４１２は、認可トークンを記憶しているか判断する。認可トークンを記憶していた場合はステップＳ１６０７に遷移する。また記憶していなかった場合はステップＳ１６５０に遷移する。ステップＳ２６０３で、第２のリソースサービス連携部４１３は、ステップＳ１６０７で取り出した認可トークンを用いて、リソースサービス３５０にアクセスを行う。またアクセスの際に送るデータには、ステップＳ１６０１で特定した代行者の代行者識別子も含める。アクセスが完了すると本フローは終了する。

図１１ｂは本実施の第２の形態に係る、リソースサービス３５０での処理のフローである。ステップＳ２７０１で、第２の認可トークン検証依頼部３５２は、ステップＳ１７０１のアクセスから認可トークンと代行者識別子を取り出す。ステップＳ２７０２で、第２の認可トークン検証依頼部３５２は、ステップＳ２７０１で取り出した認可トークンの有効性の検証を認可サービス３００に依頼し、検証結果を受け取る。

図１１ｃは本実施の第２の形態に係る、認可サービス３００における認可トークンの有効性検証のフローである。ステップＳ２８０１で、第２の共有範囲検証部３１１は、リソースサービス３５０から認可トークンを受け取る。また代行者識別子も受け取る。ステップＳ２８０２で、第２の共有範囲検証部３１１は、ステップＳ２８０１で受け取った認可トークンに対応する共有範囲に、ステップＳ２０８１で受け取った代行者識別子で示される代行者が含まれるか判断する。代行者が共有範囲に含まれる場合はステップＳ１８０２に遷移し、含まれない場合はステップＳ１８５０に遷移する。

図１２は本実施の第２の形態に係る、認可サービス３００および代行サービス４００で管理されるデータの例である。図１２ａは本実施の第２の形態に係る、認可サービス３００で管理される認可トークンの共有範囲に関するデータの例である。図１２ａは、ユーザーＫの認可トークンを代行者Ｘおよび代行者Ｙが共有できることを示している。また認可トークンの共有範囲は、外部サービスＢに対して設定されたものであることも示している。この場合、代行者Ｘおよび代行者Ｙは認可トークン９８７６５４３２１を用いて、ユーザーＫの代わりに、外部サービスＢからリソースサービス３５０に処理を指示することが可能である。しかし代行者Ｚは認可トークン共有範囲に含まれないため、ユーザーＫの代わりに、外部サービスＢからリソースサービス３５０に処理を指示することができない。

図１２ｂは本実施の第２の形態に係る、代行サービス４００が管理する認可トークンのデータ例である。この例ではユーザーＫの認可操作は認可操作識別子１１１１１０−１２２３３４で識別され、前記認可操作識別子と認可トークン９８７６５４３２１が紐付けて記憶されている様子も示している。

本実施の第２の形態によれば、認可トークンの共有範囲の検証を、認可トークンを発行した認可サービス３００が実施するため、より厳密な共有範囲検証を実現できる。また、認可サービス３００で権限委譲の共有範囲を管理するので、複数の代行サービスが存在する場合に効果的である。即ち、実施例１では、夫々の代行サービスに共有範囲を設定し、運用する構成を導入する必要があったが、実施例２では認可サービス３００にその構成のほとんどを集約させたので、代行サービスの実装負担が軽減されるのである。よって、代行サービスが多ければ多いほど、実施例２は効果的である。

次に、本発明を実施するための第３の形態について図面を用いて説明する。本実施の第１の形態および本実施の第２の形態において利用ユーザーは、代行者があらかじめ設定した認可トークンの共有範囲を、そのまま許可するか、あるいは拒否することしかできなかった。本実施の第３の形態においては、利用ユーザーが望む範囲の代行者が、認可トークンを共有範囲させることを目的とする。

なお、実施例１と共通の部分については説明を省略し、以下では差異部分のみ説明する。なお、実施例３においては、代行サービス４００が第２の共有範囲確認画面３０００を表示させている。しかし、認可サービス３００が第２の共有範囲確認画面３０００を表示させる構成としてもよい。実施例３は、実施例１および実施例２のどちらの形態にも適用可能である。

図１３は本実施の形態に係る、認可サービス３００、リソースサービス３５０、代行サービス４００のモジュール構成を示す図である。図１３ａは本実施の形態に係る、認可サービス３００のモジュール構成を示す図である。認可サービス３００は代行サービス連携部３０１、認可要求部３０２、認可管理部３０３、認可トークン検証部３０４、検証結果通知部３０５から構成される。認可要求部３０２はユーザーに認可画面１００１を提示して認可を求める。代行サービス連携部３０１は代行サービス４００から受け取った認可操作識別子に応じて認可管理部３０３で記憶している認可トークンを返す。認可トークン検証部３０４はリソースサービス３５０から受け取った認可トークンを検証し、検証結果通知部３０５がリソースサービス３５０に検証結果を返却する。

図１３ｂは本実施の形態に係る、リソースサービス３５０のモジュール構成を示す図である。リソースサービス３５０は認可トークン検証依頼部３５１を持つ。認可トークン検証依頼部３５１は代行サービス４００から受け取った認可トークンが有効なものか、認可サービス３００に検証を依頼する。

図１３ｃは本実施の形態に係る、代行サービス４００のモジュール構成を示す図である。代行サービス４００は共有範囲指定部４０１、共有範囲管理部４０２、共有範囲取得部４０３を持つ。また認可サービス連携部４０５、認可トークン要求部４０６、認可トークン管理部４０７、代行対象ユーザー受付部４０８、共有範囲検証部４０９、リソースサービス連携部４１０を持つ。また第３の共有範囲許可要求部４１４、共有範囲更新部４１５を持つ。

共有範囲指定部４０１は代行者から共有範囲の指示を受け、共有範囲管理部４０２で共有範囲を記憶する。ユーザーにアクセスされると共有範囲取得部４０３は共有範囲管理部４０２で記憶した共有範囲を取り出し、共有範囲許可要求部４０４がユーザーに共有範囲確認画面１０００を提示して共有範囲の許可を求める。認可サービス連携部４０５はユーザーのアクセスを認可サービス３００にリダイレクトさせ、応答として認可操作識別子を受け取る。認可トークン要求部４０６は認可サービス連携部４０５が受け取った認可操作識別子を用いて認可サービス３００に認可トークンの発行を求める。発行された認可トークンは認可トークン管理部４０７が記憶する。

代行対象ユーザー受付部４０８は代行者のアクセスを受け付ける。共有範囲検証部４０９は、アクセスしてきた代行者が共有範囲管理部４０２で記憶している認可トークンの共有範囲に含まれるか検証する。リソースサービス連携部４１０は認可トークン管理部４０７から取り出した認可トークンを用いてリソースサービス３５０に処理を依頼する。

図１４は本実施の第３の形態に係る、代行サービス４００におけるユーザーによる認可トークン共有範囲の確認および許可フローである。代行者が共有範囲準備を済ませると、ユーザーは共有範囲の確認と許可を行う。なお代行者が共有範囲準備を済ませたことは電話や電子メールでユーザーに通知してもよく、その他の手段で通知してもよい。

以下のフローは代行サービス４００がユーザーに認可トークンの共有範囲の許可を求めるフローである。このフローはユーザーがＷｅｂブラウザを用いて代行サービス４００にアクセスすることで開始される。後続のフローで発行される認可トークンは、ユーザーによる許可を受け、ここで許可された範囲の代行者間で共有して利用可能となる。

ステップＳ３２０１で第３の共有範囲許可要求部４１４は、ステップＳ１２０２で取得した認可トークンの共有範囲情報を基に設定画面をユーザーに提示し、共有範囲の指示と許可を求める。図１５に示される第２の共有範囲確認画面３０００は、代行者Ｘ、代行者Ｙ、代行者Ｚが認可トークンの共有をすることをユーザーに許可を求める際の画面であり、共有範囲を設定可能な設定画面である。またここではユーザーが、提示された代行者の内で代行者Ｙと代行者Ｚを指定して認可トークンの共有を許可する場合を示している。

ステップＳ３２０２で第３の共有範囲許可要求部４１４は、ステップＳ３２０１でユーザーが共有範囲を許可したか判断する。判断の結果、ユーザーが許可していた場合はステップＳ３２０３に遷移する。ユーザーが許可していなかった場合はここでフローを終了する。ステップＳ３２０３で共有範囲更新部４１５は、ステップＳ３２０１のユーザーの指定に従い、認可トークン管理部４０７で管理する認可トークンの共有範囲を更新する。

実施例３は、有範囲の内の利用者に対して前記認可トークンの共有を許可するか否かを設定するための設定画面を、共有範囲の内のどの利用者に前記認可トークンの共有を許可するかを設定することが可能な設定画面として提供する実施例である。そして、実施例３によれば、代行者が指定した認可トークンの共有範囲の内で、ユーザーが望む代行者にのみ認可トークンの共有を許可したいといった要望にも対応できる。これにより、たとえ、複数の代行者がサービスの代行を行うことを想定していても、利用者であるユーザーに一部の代行者が認可されなかった場合は、その認可されなかった利用者は代行を行うことができない。よって、実施例１、および実施例２と比較して、実施例３は柔軟な権限委譲に対応することが出来る。

以上、各実施例では、複数の代行者がユーザーの代わりに作業を行うシステムにおいて、ユーザーは代行者ごとに認可操作を行うことなく、複数の代行者が認可トークンを共有できるための発明について説明してきた。しかしながら、各実施例で説明してきた構成を別の形態で実施しても良い。

３００認可サービス
３０６第２の共有範囲指定部
３０７第２の共有範囲管理部
３１１第２の共有範囲検証部
３５０リソースサービス
４００代行サービス
４０１共有範囲指定部
４０２共有範囲管理部
４０９共有範囲検証部

Claims

特定情報を管理する第１のサーバーシステムと、取得された前記特定情報を利用したサービスを提供する第２のサーバーシステムと、認証装置と、前記サービスを利用可能な第１のユーザーが操作するクライアントと、から構成される権限委譲システムであって、
前記第１のサーバーシステムにより管理される前記特定情報の利用を認めるための認可トークンの共有範囲を受け付ける受け付け手段と、
受け付けた前記共有範囲を基に、前記共有範囲の内の利用者に対して前記認可トークンの共有を許可するか否かを設定するための設定画面を前記クライアントに送信する送信手段と、
送信された前記設定画面を介して前記第１のユーザーにより設定された前記認可トークンの共有範囲と、前記認証装置により発行された前記認可トークンと、を紐付けて管理する管理手段と、
第２のユーザーが前記サービスを利用する場合に前記第２のサーバーシステムにより使用される認可トークンの共有範囲に前記第２のユーザーが含まれるか否かを判断する判断手段と、
前記第２のユーザーが当該認可トークンの共有範囲に含まれると判断され、かつ当該認可トークンが有効であることが確認されたことに応じて、前記第２のサーバーシステムは前記第１のサーバーシステムから前記特定情報を取得し、取得された前記特定情報を利用した前記サービスを前記第２のユーザーに提供する提供手段と、を有する権限委譲システム。
前記共有範囲の内の利用者に対して前記認可トークンの共有を許可するか否かを設定するための設定画面とは、前記共有範囲の内のどの利用者に前記認可トークンの共有を許可するかを設定することが可能な設定画面であり、当該設定画面を介して前記認可トークンの共有を許可する利用者を前記第１のユーザーにより設定されることで、前記管理手段により前記認可トークンの共有範囲が管理されることを特徴とする請求項１に記載の権限委譲システム。
前記受け付け手段により受け付けられた認可トークンの共有範囲は前記第２のユーザーが操作するクライアントから受け付けた設定であり、かつ受け付けられたことで前記管理手段により管理される設定であって、
前記共有範囲の内のどの利用者に前記認可トークンの共有を許可するかを設定することが設定可能な設定画面を介して前記第１のユーザーにより設定された認可トークンの共有範囲が、前記第２のユーザーが操作するクライアントから受け付けた認可トークンの共有範囲と異なる場合は、前記設定画面を介して前記第１のユーザーにより設定された認可トークンの共有範囲に更新するよう制御し、前記管理手段は、前記共有範囲の内のどの利用者に前記認可トークンの共有を許可するかを設定することが設定可能な設定画面を介して前記第１のユーザーにより設定された認可トークンの共有範囲が、前記第２のユーザーが操作するクライアントから受け付けた認可トークンの共有範囲と同一である場合は、前記第２のユーザーが操作するクライアントから受け付けた認可トークンの共有範囲を更新しないように制御する更新手段を更に有することを特徴とする請求項２に記載の権限委譲システム。
前記認証装置は、送信された前記設定画面を介して前記第１のユーザーにより設定された前記認可トークンの共有範囲を識別する共有範囲識別子を前記第２のサーバーシステムから前記クライアントを介して取得し、認可画面を介して認可トークンの発行が許可されたことに応じて、前記共有範囲識別子と認可操作識別子とを前記クライアントを介して前記第２のサーバーシステムへ送信し、
前記第２のサーバーシステムが有する管理手段は、前記認可操作識別子を基に前記認証装置から認可トークンを発行してもらい、発行された認可トークンは前記共有範囲識別子を基にして当該認可トークンの共有範囲と紐付けて管理することを特徴とする請求項１乃至３の何れか１項に記載の権限委譲システム。
特定情報を管理する第１のサーバーシステムと、認証装置と、サービスを利用可能な第１のユーザーが操作するクライアントと通信可能な第２のサーバーシステムであって、
前記第１のサーバーシステムにより管理される前記特定情報の利用を認めるための認可トークンの共有範囲を受け付ける受け付け手段と、
受け付けた前記共有範囲を基に、前記共有範囲の内の利用者に対して前記認可トークンの共有を許可するか否かを設定するための設定画面を前記クライアントに送信する送信手段と、
送信された前記設定画面を介して前記第１のユーザーにより設定された前記認可トークンの共有範囲と、前記認証装置により発行された前記認可トークンと、を紐付けて管理する管理手段と、
第２のユーザーが前記サービスを利用する場合に前記第２のサーバーシステムにより使用される認可トークンの共有範囲に前記第２のユーザーが含まれるか否かを判断する判断手段と、
前記第２のユーザーが当該認可トークンの共有範囲に含まれると判断され、かつ当該認可トークンが有効であることが確認されたことに応じて、前記第１のサーバーシステムから前記特定情報を取得し、取得された前記特定情報を利用した前記サービスを前記第２のユーザーに提供する提供手段と、を有する権限委譲システム。
特定情報を管理する第１のサーバーシステムと、取得された前記特定情報を利用したサービスを提供する第２のサーバーシステムと、認証装置と、前記サービスを利用可能な第１のユーザーが操作するクライアントと、から構成される権限委譲システムを制御する制御方法であって、
受け付け手段は、前記第１のサーバーシステムにより管理される前記特定情報の利用を認めるための認可トークンの共有範囲を受け付け、
送信手段は、受け付けた前記共有範囲を基に、前記共有範囲の内の利用者に対して前記認可トークンの共有を許可するか否かを設定するための設定画面を前記クライアントに送信し、
管理手段は、送信された前記設定画面を介して前記第１のユーザーにより設定された前記認可トークンの共有範囲と、前記認証装置により発行された前記認可トークンと、を紐付けて管理し、
判断手段は、第２のユーザーが前記サービスを利用する場合に前記第２のサーバーシステムにより使用される認可トークンの共有範囲に前記第２のユーザーが含まれるか否かを判断し、
提供手段は、前記第２のユーザーが当該認可トークンの共有範囲に含まれると判断され、かつ当該認可トークンが有効であることが確認されたことに応じて、前記第２のサーバーシステムは前記第１のサーバーシステムから前記特定情報を取得し、取得された前記特定情報を利用した前記サービスを前記第２のユーザーに提供することを特徴とする権限委譲システムの制御方法。