JP2021026612A - システム、認可サーバー、制御方法、プログラム - Google Patents

Abstract

【課題】 クライアントが権限委譲を求める際に、クライアントがアクセスしたいリソースは分かっているものの、そのリソースの所有者が分からず、ユーザーを指定して権限委譲を求められない場合が考えられる。【解決手段】 クライアントはリソース識別子を指定して認可開始リクエストを行う。認可開始リクエストを受信した認可サーバーは指定されたリソース識別子のリソース所有者をリソースサーバーに問い合わせる。リソース所有者を解決すると、認可サーバーは、解決されたユーザー識別子に対応するユーザー端末に認可確認リクエストを行う。【選択図】 図６

Description

本発明は、ユーザーのリソースの権限委譲を可能とするシステム、認可サーバー、制御方法、プログラムに関する。

クラウドのｗｅｂサービスでＯＡｕｔｈ２．０による権限委譲を実現している。特許文献１では、システム連携を設定する際にユーザーは、クライアントと認可サーバーの両方に対しウェブブラウザを介して操作し認可操作を行うことで、ユーザーの権限をクライアントに委譲できることについて開示している。クライアントは、委譲されたユーザーの権限を用いて、ユーザーのリソースにアクセスしシステム連携が実現する。

特許５６２３２３４

ＯＡｕｔｈ２．０でユーザーの権限をクライアントに委譲するためには、ユーザーがクライアントにウェブブラウザでアクセスすることが必要になる。例えば、マルチテナントシステムで、外部システムから各テナントのデータを解析する際に各テナントの管理者の許可が必要なケースを考える。この場合、解析処理のタイミングでテナントの管理者がクライアントである外部システムにアクセスすることを期待できず、クライアントが自立的に権限委譲の要求を行う必要がある。

クライアントが自立的に権限委譲の要求を行うようにすることで、ユーザーがクライアントにアクセスしていない状態でも、クライアントがユーザーを指定して権限委譲を求めることができるようになる。しかし、権限委譲の許可を求める際に、どのユーザーの端末に対して権限委譲の許可を求めれば良いかを考える必要がある。

本発明は前述の課題を鑑みてなされたもので、クライアントがユーザーを指定して権限委譲を求める場合に、ユーザーの端末を特定し権限委譲の許可を求めることを目的とする。

本発明の一実施形態に係る認可サーバーは、ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーであって、１人のユーザーのユーザー識別子に対して複数のユーザー端末の端末情報を関連付けて記憶する記憶手段と、前記クライアントから認可開始リクエストを受信したことに応じて前記認可開始リクエストからユーザー識別子を特定し、特定されたユーザー識別子に関連付けられた端末情報を特定する特定手段と、複数の端末情報が特定された場合、特定された端末情報を基に認可確認リクエストを前記ユーザーが保有する複数のユーザー端末のそれぞれに対して送信し、前記複数のユーザー端末の内の何れか１台から認可確認の結果を受信する確認手段と、前記確認手段により受信された認可確認の結果に応じて前記アクセストークンの発行を制御し、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ送信する発行手段と、を有することを特徴とする。

本願発明によれば、クライアントがユーザーを指定して権限委譲を求める場合に、ユーザーの端末を特定し権限委譲の許可を求めることができる。

ネットワーク構成を示す図である。 本実施の形態に係る、認可サーバー１５１の構成を示す図である。 本実施の形態に係る、モジュール構成を示す図である。 本実施の形態に係る、認可開始リクエストおよび認可確認リクエストのフローである。 本実施の形態に係る、アクセストークン発行フローである。 本実施の形態に係る、全体のフローである。 本実施の形態に係る、認可確認画面。

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

１５２はユーザーのリソースを管理するリソースサーバーであり、１１１はリソースサーバー１５２上のリソースにアクセスするクライアントである。ここでクライアント１１１がリソースサーバー１５２上のリソースにアクセスするためには、リソース所有者による権限委譲が必要である。１５１はクライアントの求めに応じてリソースへのアクセス許可の証拠となるアクセストークンを発行する認可サーバーである。１７１、および１７２はクライアント１１１が権限委譲を求めた際に認可確認画面を表示するユーザー端末である。なお、夫々のユーザー端末は図１に２台しか存在しないがそれ以上の台数があっても良い。

認可サーバー１５１、リソースサーバー１５２はそれぞれＬＡＮ１５０を介してＷＡＮ１００と接続されている。また同様にクライアント１１１はＬＡＮ１１０を介して、ユーザー端末１７１はＬＡＮ１７０を介して、それぞれＷＡＮ１００と接続されている。なお認可サーバー１５１、リソースサーバー１５２はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。同様に、同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。また、認可サーバー１５１、リソースサーバー１５２は図１ではそれぞれが１台として描かれているが複数のサーバーから構成されたサーバーシステムでも良い。例えば、複数台のサーバーをクラスタ化して認可サーバー１５１を構成しても良い。なお、本願発明においてサーバーシステムと称した場合は、少なくとも１台のサーバーから構成された特定のサービスを提供する装置を指すものとする。

実施例１の形態に係るイベント通知システムは、図２に示すような構成のＰＣから成るシステム上に実現される。図２は実施例１の形態に係る、認可サーバー１５１の構成を示す図である。またクライアント１１１、リソースサーバー１５２の構成やユーザー端末１７１の構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のサーバーコンピューターおよび端末には一般的な情報処理装置のハードウェア構成を適用できる。

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

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１やＲＯＭ２０３にインストールされたＯＳやアプリケーション等のプログラムである。ソフトウェア上の主体は、ＣＰＵ２０１がそれらプログラムを実行することで実現する。

図３は本実施の形態に係る、クライアント１１１、認可サーバー１５１、リソースサーバー１５２のモジュール構成を示す図である。図３（Ａ）はクライアント１１１、図３（Ｂ）は認可サーバー１５１、図３（Ｃ）はリソースサーバー１５２のモジュール構成を、それぞれ示す。また図３（Ｄ）はユーザー端末１７１のモジュール構成を示す。

クライアント１１１は認可開始リクエスト発行モジュール３０１、アクセストークン要求モジュール３０２、アクセストークン管理モジュール３０３、リソースアクセスモジュール３０４を持つ。認可サーバー１５１は認可リクエスト管理モジュール３５１、リソース所有者解決モジュール３５２、認可確認モジュール３５３、アクセストークン発行モジュール３５４を持つ。リソースサーバー１５２はリソース管理モジュール３７１を持つ。ユーザー端末１７１は認可操作受付モジュール３９１を持つ。

認可サーバー１５１の認可リクエスト管理モジュール３５１は、クライアント１１１の認可開始リクエスト発行モジュール３０１の要求に従い、認可開始リクエストを処理する。認可開始リクエストにはクライアント１１１がアクセスしようとするリソース情報が含まれる。リソース所有者解決モジュール３５２は認可開始リクエストに含まれるリソース情報を用いて、リソースサーバー１５２に対し、当該リソースのリソース所有者情報を問い合わせる。ここで得られたリソース所有者情報を基に、認可確認モジュール３５３は、特定のユーザー端末１７１に対し認可確認リクエストを行う。認可確認リクエストに対しユーザーが認可操作を行うと、クライアント１１１は、認可サーバー１５１からアクセストークンを取得できるようになり、リソースサーバーが提供するユーザーのリソースへアクセスできるようになる。このように認可サーバー１５１は、クライアント１１１がユーザーに関連づくリソースへアクセスするための認可処理を実行するためのモジュールを備えている。

図４（Ａ）は本実施の形態に係る、クライアント１１１が認可サーバー１５１に対し認可開始リクエストを行うフローである。本フローはクライアント１１１がリソースサーバー１５２上のリソースへのアクセスに先立ち、アクセストークンが必要になった際に開始される。

ステップＳ４０１で認可開始リクエスト発行モジュール３０１は、操作対象のリソース識別子およびスコープを含む認可開始リクエストを、認可サーバー１５１に対して送信する。スコープは、リソースへのアクセス範囲を示すものであり、例えば、リソースの取得を望む場合は“ｇｅｔ−ｄａｔａ”のスコープを指定することになる。

ステップＳ４０２で認可開始リクエスト発行モジュール３０１は、認可サーバー１５１からレスポンスを受信する。このレスポンスには、認可サーバー１５１が発行した認可リクエスト識別子が含まれる。ステップＳ４０３で認可開始リクエスト発行モジュール３０１は、ステップＳ４０２で受信したレスポンスに含まれる認可リクエスト識別子を、ステップＳ４０１の操作対象リソースおよびスコープとともに記憶し、フローを終了する。表１はクライアント１１１が記憶する認可リクエスト管理テーブルの例である。

表１ではリソース識別子“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”で示されるリソースに対し、スコープ“ｇｅｔ−ｄａｔａ”で行った認可開始リクエストが、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”に紐付けて記憶されている。また認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対しては、“ａｃｔｋ１１１２２２３３３”で示されるアクセストークンを取得済みであることを示す。ここでリソース識別子が示すリソースは、ファイルシステム上の１つのファイルを示してもよく、データベース上の特定のレコードを示してもよい。またそれらの集合を示してもよい。

図４（Ｂ）は本実施の形態に係る、認可サーバー１５１における認可開始リクエストの受信フローである。本フローは認可サーバー１５１がクライアント１１１から認可開始リクエストを受信することで開始される。ステップＳ４１１で認可リクエスト管理モジュール３５１は、クライアント１１１から認可開始リクエストを受け付ける。認可開始リクエストには、クライアント１１１のクライアント識別子と、クライアント１１１が操作対象としているリソース識別子が含まれる。

ステップＳ４１２でリソース所有者解決モジュール３５２は、ステップＳ４１１で指定されたリソースの所有者を、リソースサーバー１５２に問い合わせる。ステップＳ４１３でリソース所有者解決モジュール３５２は、ステップＳ４１２の問い合わせの応答として、ステップＳ４１１で指定されたリソースの所有者のユーザー識別子を受信する。ステップＳ４１４で認可リクエスト管理モジュール３５１は、ステップＳ４１１で受信した認可開始リクエストに対応する認可リクエスト識別子を生成する。

ステップＳ４１５で認可リクエスト管理モジュール３５１は、ステップＳ４１４で生成した認可リクエスト識別子に、認可リクエストの情報を紐付けて記憶する。認可リクエストの情報とは、ステップＳ４１１で受信したクライアント識別子、操作対象のリソース識別子、スコープと、ステップＳ４１３で受信したユーザー識別子を含む。表２は認可リクエスト管理モジュール３５１が記憶する認可確認状況管理テーブルの例である。

表２では、クライアント識別子“ｃｌｉｅｎｔ＿ｘｙｚ”で示されるクライアントが、リソース識別子“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”で示されるリソースに対し、スコープ“ｇｅｔ−ｄａｔａ”で行った認可開始リクエストが、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”に紐付けて記憶されている。また認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”にはユーザー識別子“ｕｓｅｒ＿ａｂｃｄｅ”が紐付けられているが、これはリソース“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”のリソース所有者を解決した結果、ユーザー識別子が”ｕｓｅｒ＿ａｂｃｄｅ”だったことを示している。なお認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”の認可結果が“（空欄）”となっているのは、ユーザーがまだ認可操作を行っていないことを示している。

それに対し認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”の認可結果は“ａｐｐｒｏｖｅｄ”で、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿４４４４４”の認可結果は“ｄｉｓａｐｐｒｏｖｅｄ”である。これらはそれぞれ、ユーザーが認可を行ったことと、認可を拒否したことをそれぞれ示している。このように夫々の情報は関連付けられている。

ステップＳ４１６で認可リクエスト管理モジュール３５１は、ステップＳ４１１の応答として、ステップＳ４１４で生成した認可リクエスト識別子をクライアント１１１に返し、フローを終了する。

図４（Ｃ）は本実施の形態に係る、認可サーバー１５１における認可確認リクエストを行うフローである。本フローはステップＳ４１５で認可リクエストの情報を記憶したことを受けて開始される。

ステップＳ４２１で認可確認モジュール３５３は、ステップＳ４１５で記憶した認可リクエスト識別子に紐付くユーザー識別子を取得する。ここで、ステップＳ４１５で記憶した認可リクエスト識別子が“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”であれば、紐付くユーザー識別子は“ｕｓｅｒ＿ａｂｃｄｅ”である。

ステップＳ４２２で認可確認モジュール３５３は、ステップＳ４２１で取得したユーザー識別子から、ユーザー端末１７１，１７２の複数のユーザー端末を特定する。表３はユーザー識別子とユーザー端末１７１の対応を記憶するユーザー管理テーブルの例である。表３では、１人のユーザーが２台のユーザー端末を保有していることを示すが、１人のユーザーが３台以上のユーザー端末を保有していても良く、その場合、３つ以上のユーザー端末情報が１人のユーザーのユーザー識別子に関連付くことになる。

ここでユーザー識別子“ｕｓｅｒ＿ａｂｃｄｅ”に対応するユーザー端末情報は、”１９２．１６８．０．１”と”１９２．１６８．０．２”であることが特定できる。本実施例では、この２台のユーザー端末がユーザー端末１７１と１７２であるものとして説明する。ステップＳ４２３で認可確認モジュール３５３は、ステップＳ４１５で記憶した認可リクエスト識別子に紐付くクライアント識別子およびスコープを取得する。ここで、ステップＳ４１５で記憶した認可リクエスト識別子が“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”であれば、紐付くクライアント識別子およびスコープはそれぞれ“ｃｌｉｅｎｔ＿ｘｙｚ”および“ｇｅｔ−ｄａｔａ”である。

ステップＳ４２４で認可確認モジュール３５３は、ステップＳ４２２で特定したユーザー端末１７１とユーザー端末１７２に対し、ステップＳ４２３で取得したクライアント識別子およびスコープを含めて認可確認リクエストを送信する。なお認可確認リクエストの送信方法は、ユーザー端末１７１のエンドポイントを指定した通信方法でもよく、またＭＱＴＴをはじめとするＰＵＳＨ通知を用いた方法でもよい。またその他の方法でもよい。認可確認リクエストを受け付けたユーザー端末１７１およびユーザー端末１７２の認可操作受付モジュール３９１は、図７に示すような認可確認画面１００１を表示し、ユーザーに認可を求める。ここでポイントとなるのは、ユーザーが保有するすべてのユーザー端末で認可確認画面１００１が表示されるという点である。ユーザーが認可確認画面１００１で“許可”のボタンを押して認可を指示することになる。

ステップＳ４２５で認可確認モジュール３５３は、ステップＳ４２４で送信した認可確認リクエストの応答として、ユーザー端末１７１またはユーザー端末１７２の所定のユーザー端末から認可結果を受信する。ステップＳ４２６で認可確認モジュール３５３は、ステップＳ４２５で受信した認可結果を、ステップＳ４１５で記憶した認可リクエスト識別子に紐付けて記憶し、フローを終了する。表２では、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対し、認可されたことを示す“ａｐｐｒｏｖｅｄ”が記憶されている。

ステップＳ４２７で認可確認モジュール３５３は、所定のユーザー端末以外のユーザー端末に認可確認の取り下げリクエストを送信する。例えば、ユーザーが”１９２．１６８．０．１”のユーザー端末から認可操作を行った場合、ユーザーに紐づく別のユーザー端末”１９２．１６８．０．２”に対して認可確認の取り下げを要求する。なお、ユーザーが３台以上のユーザー端末を保有している場合、認可操作を行ったユーザー端末以外の全てのユーザー端末に対して認可確認の取り下げを要求することになる。また、ユーザーの認可操作が“許可”であろうが“拒否”であろうが、認可操作の結果に依らず所定のユーザー端末以外のユーザー端末に認可確認の取り下げを要求する。ユーザーは今回の認可リクエストに対する認可操作を行えば、誤って他のユーザー端末で同じ認可リクエストに対する認可操作をすることがなくなる。

図４（Ｄ）は本実施の形態に係る、リソースサーバー１５２におけるリソース所有者を返すフローである。本フローはリソースサーバー１５２が認可サーバー１５１から、リソース所有者の問い合わせを受けて開始される。

ステップＳ４５１でリソース管理モジュール３７１は、認可サーバー１５１からリソース所有者の問い合わせを受信する。この問い合わせにはリソース識別子を含む。ステップＳ４５２でリソース管理モジュール３７１は、ステップＳ４１５で指定されたリソースの所有者のユーザー識別子を取得し、認可サーバー１５１に返し、フローを終了する。表４はリソース管理モジュール３７１におけるリソース管理テーブルの例である。

表４では、リソースを識別するための識別情報としてリソース識別子を採用しており、リソース識別子が“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”で示されるリソースの所有者が、ユーザー識別子“ｕｓｅｒ＿ａｂｃｄｅ”であることが示されている。

図５（Ａ）は本実施の形態に係る、認可サーバー１５１がクライアント１１１に認可完了通知を行うフローである。本フローはステップＳ４２６で認可結果を記憶したことを受けて開始される。

ステップＳ５０１で認可確認モジュール３５３は、ステップＳ４２６で記憶した認可リクエスト識別子を取得する。ステップＳ５０２で認可確認モジュール３５３は、ステップＳ５０１で取得した認可リクエスト識別子に紐付くクライアントの接続先情報であるクライアントエンドポイントを取得する。表５はクライアント識別子とクライアントエンドポイントの対応を管理する、クライアント管理テーブルの例である。

表５では、クライアント識別子“ｃｌｉｅｎｔ＿ｘｙｚ”のクライアントエンドポイントが、”１０．０．０．１”であることを示している。ステップＳ５０３で認可確認モジュール３５３は、ステップＳ５０２で取得したクライアントエンドポイントに対し、ユーザーがリソースへのアクセスを許可したこと、すなわち認可したことを通知し、フローを終了する。なおここでクライアントエンドポイントに通知する内容は、ステップＳ５０１で取得した認可リクエスト識別子でもよく、またユーザーの認可に対応して発行したアクセストークンでもよい。アクセストークンを発行する際は後述の図５（Ｃ）に示されるようなフローを実行する。

図５（Ｂ）は実施例１の形態に係る、クライアント１１１が認可サーバー１５１にアクセストークンリクエストを行うフローである。本フローはクライアント１１１が認可サーバー１５１からステップＳ５０３の認可完了通知を受けて開始される。または本フローは、クライアント１１１が、定期的に実行してもよい。

ステップＳ５１１でアクセストークン要求モジュール３０２は、アクセストークンリクエストを行う認可リクエスト識別子を決定する。ここで本フローが定期的に実行される場合には、認可リクエスト識別子は、表１に示される認可リクエスト管理テーブルでアクセストークン未取得のものから選ばれる。また本フローが認可サーバー１５１からの通知を受けて開始される場合は、認可サーバー１５１からの通知に含まれる認可リクエスト識別子が用いられる。

ステップＳ５１２でアクセストークン要求モジュール３０２は、ステップＳ５１１で決定した認可リクエスト識別子を指定して、認可サーバー１５１に対してアクセストークンリクエストを行う。ステップＳ５１３でアクセストークン管理モジュール３０３は、ステップＳ５１２の応答として受信したアクセストークンを記憶し、フローを終了する。表１では、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対して取得できた、アクセストークン“ａｃｔｋ１１１２２２３３３”を記憶している様子を示す。

図５（Ｃ）は本実施の形態に係る、認可サーバー１５１がアクセストークンを発行するフローである。本フローは認可サーバー１５１がクライアント１１１からアクセストークンリクエストを受信したことで開始される。

ステップＳ５２１でアクセストークン発行モジュール３５４は、クライアント１１１から受信したアクセストークンリクエストから、認可リクエスト識別子を取得する。ステップＳ５２２でアクセストークン発行モジュール３５４は、アクセストークン発行可否を判断する。

ステップＳ５２３でアクセストークン発行モジュール３５４は、ステップＳ５２２の結果、アクセストークンを発行可能であると判断されたか確認する。アクセストークンを発行可能と判断された場合はステップＳ５２４に遷移する。またアクセストークンを発行不可能と判断された場合はステップＳ５２５に遷移する。

ステップＳ５２４でアクセストークン発行モジュール３５４は、ステップＳ５２１で取得した認可リクエスト識別子に紐付けられたユーザー識別子およびスコープに対応するアクセストークンを発行する。また発行したアクセストークンをクライアント１１１に返し、フローを終了する。表６はアクセストークン発行モジュール３５４で発行されたアクセストークンを管理する、アクセストークン管理テーブルの例である。

表６では、ユーザー“ｕｓｅｒ＿ａｂｃｄｅ”がスコープ“ｇｅｔ−ｄａｔａ”の権限委譲を行ったことを示すアクセストークンが、アクセストークン識別子“ａｃｔｋ１１１２２２３３３”として発行されていることを示す。なおステップＳ５２４でクライアント１１１に返すアクセストークンは、アクセストークン識別子だけでもよく、またアクセストークン識別子に加えユーザー識別子およびスコープを含む構造化されたデータでもよい。ステップＳ５２５でアクセストークン発行モジュール３５４は、アクセストークンを発行できないことをクライアント１１１に通知し、フローを終了する。

図５（Ｄ）は本実施の形態に係る、アクセストークン発行可否判断を行うステップＳ５２２の詳細フローである。ステップＳ５３１でアクセストークン発行モジュール３５４は、表２の認可確認状況管理テーブルを参照し、指定された認可リクエスト識別子に対応する認可結果を確認する。

ステップＳ５３２でアクセストークン発行モジュール３５４は、ステップＳ５３１の確認した認可結果が、認可されていることを表しているか判断する。認可されていることを表していた場合はステップＳ５３３に遷移し、その他の場合はステップＳ５３４に遷移する。ステップＳ５３３でアクセストークン発行モジュール３５４は、アクセストークンを発行可能と判断し、フローを終了する。ステップＳ５３４でアクセストークン発行モジュール３５４は、アクセストークンを発行不可能と判断し、フローを終了する。

図６は本実施の形態に係る、クライアントが認可開始リクエストを行ってからアクセストークンを入手し、リソースアクセスする際の全体のフローである。クライアント１１１は（１）で認可サーバーに対し認可開始リクエストを行い、応答として（２）で認可リクエスト識別子を取得する。（１）はステップＳ４０１およびステップＳ４１１に、（２）はステップＳ４０２およびステップＳ４１６にそれぞれ対応する。

認可サーバー１５１は認可開始リクエストを受けると、認可開始リクエストに含まれるリソース識別子のリソース所有者を解決するため、（３）でリソースサーバー１５２にリソース所有者の問い合わせを行う。また応答として（４）でリソース所有者のユーザー識別子を受信する。（３）はステップＳ４１２およびステップＳ４５１に、（４）はステップＳ４１３およびステップＳ４５２に、それぞれ対応する。

認可サーバー１５１はリソース所有者の解決が済むと、（５）でリソース所有者に紐付けられたユーザー端末１７１に対し認可確認リクエストを行う。ユーザー端末１７１およびユーザー端末１７２では図７で示される認可確認画面１００１が表示され、ユーザーが何れか１台のユーザー端末で認可操作を行う。ユーザーは、クライアントにユーザーのリソースへのアクセスを許可する場合は認可確認画面１００１で“許可”、拒否する場合は認可確認画面１００１で“拒否”を選択することで認可操作を行う。ユーザーが認可操作を行った結果は、（６）として認可サーバーに返される。（５）はステップＳ４２４に、（６）はステップＳ４２５に、それぞれ対応する。

認可サーバー１５１は（６）で認可結果を受信すると、（７）でユーザーが認可操作を行ったユーザー端末以外のユーザー端末であって、ユーザーが保有するすべてのユーザー端末に対して認可確認の取り下げリクエストを送信する。認可確認の取り下げリクエストを受信したユーザー端末は、表示中の認可確認画面１００１の表示を中止する。そして、（８）でクライアント１１１に認可完了通知を行う。（８）はＳ５０３に対応する。

クライアント１１１は（８）で認可完了通知を受信するか、もしくは定期的に、（９）で認可サーバー１５１に対してアクセストークンリクエストを行う。また応答として（１０）でアクセストークンを受信する。（９）はステップＳ５１２およびステップＳ５２１に、（１０）はステップＳ５１３およびステップＳ５２４に、それぞれ対応する。

（５）もしくは（１０）でアクセストークンを受信したクライアント１１１は、（１１）でリソースサーバー１５２に対しリソースアクセスを行い、応答として（１２）でリソースを取得する。リソースサーバー１５２は、アクセストークンの検証要求を認可サーバー１５１に対して送信し検証する、もしくはリソースサーバー１５２自身がアクセストークンを検証し、クライアント１１１がユーザーのリソースへアクセスすることが許可されているかを確認するものとする。なお、リソースへのアクセス範囲はスコープで決定するものであり、例えば、“ｇｅｔ−ｄａｔａ”スコープであれば、リソースサーバー１５２はユーザーのリソースをクライアント１１１へ提供することになる。

実施例１によれば、クライアントがアクセスしたいリソースは分かっているものの、そのリソースの所有者が分からない場合でも、認可開始リクエストを行えるようになる。また、ユーザーの端末を特定し権限委譲の許可を求めることができる。

〔その他の実施例〕
実施例１では、認可開始リクエストに含まれるリソース識別子をリソースサーバー１５２に問い合わせユーザー識別子を取得する形式で説明した。しかし、認可開始リクエストにユーザー識別子が含まれている場合は、Ｓ４１２の処理を省略し、Ｓ４１３で認可開始リクエストからユーザー識別子を特定する形態としても良い。また、認可開始リクエストにユーザー識別子そのものではなくとも、認可サーバー１５１がユーザー識別子とメールアドレスなどのような関連付け情報を保有する場合は、メールアドレスを認可開始リクエストに含む形態であっても良い。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１１１ クライアント
１５１ 認可サーバー
１５２ リソースサーバー
１７１ ユーザー端末

Claims (14)

1. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーであって、
   １人のユーザーのユーザー識別子に対して複数のユーザー端末の端末情報を関連付けて記憶する記憶手段と、
   前記クライアントから認可開始リクエストを受信したことに応じて前記認可開始リクエストからユーザー識別子を特定し、特定されたユーザー識別子に関連付けられた端末情報を特定する特定手段と、
   複数の端末情報が特定された場合、特定された端末情報を基に認可確認リクエストを前記ユーザーが保有する複数のユーザー端末のそれぞれに対して送信し、前記複数のユーザー端末の内の何れか１台から認可確認の結果を受信する確認手段と、
   前記確認手段により受信された認可確認の結果に応じて前記アクセストークンの発行を制御し、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ発行した前記アクセストークンを送信する発行手段と、を有することを特徴とする認可サーバー。
2. 前記確認手段により前記認可確認リクエストが前記複数のユーザー端末のそれぞれに対して送信されることで、前記複数のユーザー端末のそれぞれのディスプレイに認可確認画面が表示されることを特徴とする請求項１に記載の認可サーバー。
3. 前記確認手段は、前記複数のユーザー端末の内の何れか１台から認可確認の結果を受信したことに応じて、認可確認の結果を送信した１台のユーザー端末を除く前記ユーザーが保有するユーザー端末に対して認可確認の取り下げリクエストを送信することを特徴とする請求項１または２に記載の認可サーバー。
4. 前記確認手段は、認可確認の結果に依らず、認可確認の結果を送信した１台のユーザー端末を除く前記ユーザーが保有するユーザー端末に対して認可確認の取り下げリクエストを送信することを特徴とする請求項３に記載の認可サーバー。
5. 前記確認手段により前記認可確認の取り下げリクエストが前記ユーザー端末に送信されることで、認可確認の結果を送信した１台のユーザー端末を除く前記ユーザーが保有するユーザー端末のそれぞれのディスプレイに表示されていた認可確認画面の表示が中止されることを特徴とする請求項３または４に記載の認可サーバー。
6. 前記特定手段は、前記認可開始リクエストに含まれる前記クライアントがアクセスする前記リソースの識別情報からユーザー識別子を特定し、その後、特定されたユーザー識別子に関連付けられた端末情報を特定することを特徴とする請求項１乃至５の何れか１項に記載の認可サーバー。
7. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムであって、
   前記認可サーバーは、
   １人のユーザーのユーザー識別子に対して複数のユーザー端末の端末情報を関連付けて記憶する記憶手段と、
   前記クライアントから認可開始リクエストを受信したことに応じて前記認可開始リクエストからユーザー識別子を特定し、特定されたユーザー識別子に関連付けられた端末情報を特定する特定手段と、
   複数の端末情報が特定された場合、特定された端末情報を基に認可確認リクエストを前記ユーザーが保有する複数のユーザー端末のそれぞれに対して送信し、前記複数のユーザー端末の内の何れか１台から認可確認の結果を受信する確認手段と、
   前記確認手段により受信された認可確認の結果に応じて前記アクセストークンの発行を制御し、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ発行した前記アクセストークンを送信する発行手段と、
   前記ユーザー端末は、
   前記認可確認リクエストを受信したことに応じて、前記クライアントが前記リソースへアクセスすることを許可するか拒否するかの指示を受け付ける認可確認画面を表示する表示手段と、
   許可された場合は許可されたことを示す認可確認の結果を、拒否された場合は拒否されたことを示す認可確認の結果を前記認可サーバーへ送信する送信手段と、を有することを特徴とするシステム。
8. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーを制御するプログラムであって、
   １人のユーザーのユーザー識別子に対して複数のユーザー端末の端末情報を関連付けて記憶する記憶ステップと、
   前記クライアントから認可開始リクエストを受信したことに応じて前記認可開始リクエストからユーザー識別子を特定し、特定されたユーザー識別子に関連付けられた端末情報を特定する特定ステップと、
   複数の端末情報が特定された場合、特定された端末情報を基に認可確認リクエストを前記ユーザーが保有する複数のユーザー端末のそれぞれに対して送信し、前記複数のユーザー端末の内の何れか１台から認可確認の結果を受信する確認ステップと、
   前記確認ステップにおいて受信された認可確認の結果に応じて前記アクセストークンの発行を制御し、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ発行した前記アクセストークンを送信する発行ステップと、を含むことを特徴とするプログラム。
9. 前記確認ステップにより前記認可確認リクエストが前記複数のユーザー端末のそれぞれに対して送信されることで、前記複数のユーザー端末のそれぞれのディスプレイに認可確認画面が表示されることを特徴とする請求項８に記載のプログラム。
10. 前記確認ステップは、前記複数のユーザー端末の内の何れか１台から認可確認の結果を受信したことに応じて、認可確認の結果を送信した１台のユーザー端末を除く前記ユーザーが保有するユーザー端末に対して認可確認の取り下げリクエストを送信することを特徴とする請求項８または９に記載のプログラム。
11. 前記確認ステップは、認可確認の結果に依らず、認可確認の結果を送信した１台のユーザー端末を除く前記ユーザーが保有するユーザー端末に対して認可確認の取り下げリクエストを送信することを特徴とする請求項１０に記載のプログラム。
12. 前記確認ステップにより前記認可確認の取り下げリクエストが前記ユーザー端末に送信されることで、認可確認の結果を送信した１台のユーザー端末を除く前記ユーザーが保有するユーザー端末のそれぞれのディスプレイに表示されていた認可確認画面の表示が中止されることを特徴とする請求項１０または１１に記載のプログラム。
13. 前記特定ステップは、前記認可開始リクエストに含まれる前記クライアントがアクセスする前記リソースの識別情報からユーザー識別子を特定し、その後、特定されたユーザー識別子に関連付けられた端末情報を特定することを特徴とする請求項８乃至１２の何れか１項に記載のシステム。
14. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムの制御方法であって、
    前記認可サーバーでは、
    １人のユーザーのユーザー識別子に対して複数のユーザー端末の端末情報を関連付けて記憶する記憶ステップと、
    前記クライアントから認可開始リクエストを受信したことに応じて前記認可開始リクエストからユーザー識別子を特定し、特定されたユーザー識別子に関連付けられた端末情報を特定する特定ステップと、
    複数の端末情報が特定された場合、特定された端末情報を基に認可確認リクエストを前記ユーザーが保有する複数のユーザー端末のそれぞれに対して送信し、前記複数のユーザー端末の内の何れか１台から認可確認の結果を受信する確認ステップと、
    前記確認ステップにおいて受信された認可確認の結果に応じて前記アクセストークンの発行を制御し、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ発行した前記アクセストークンを送信する発行ステップが実行され、
    前記ユーザー端末では、
    前記認可確認リクエストを受信したことに応じて、前記クライアントが前記リソースへアクセスすることを許可するか拒否するかの指示を受け付ける認可確認画面を表示する表示ステップと、
    許可された場合は許可されたことを示す認可確認の結果を、拒否された場合は拒否されたことを示す認可確認の結果を前記認可サーバーへ送信する送信ステップと、が実行されることを特徴とする制御方法。

Images