JP2017220113A - 認可サーバー、制御方法、およびプログラム。 - Google Patents

Abstract

【課題】 ＯＡｕｔｈ ２．０において、特定のスコープに対して権限委譲を実施したのちに、新しいスコープに対応したリソースへのＡＰＩを実行する場合は、再度、ユーザーに対して認可確認を実施する必要があり、ユーザーの利便性を損なっていた。
【解決手段】 権限委譲をする際に、複数のスコープをまとめたスコープグループとして権限委譲を行うことにより解決する。スコープグループとして権限委譲することで、スコープグループ内でスコープが増減した場合に、ユーザーに再度認可確認を要求することなくＡＰＩの利用を継続することができる。また、ユーザーの権限に変更があった場合においても、スコープグループ内での権限変更においては、ユーザーに再度認可確認を要求することなく、ＡＰＩの利用を継続することができる。
【選択図】 図７

Description

本発明は、データへのアクセス権限を検証するための認可サーバー、制御方法、およびプログラムに関する。

近年、インターネット上に展開された所謂クラウドサービスの利用が拡大している。また、これらクラウドサービスは個々にＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ ）を公開しており、他のアプリケーションやクラウドサービスからＡＰＩを介してサービスが提供する機能を利用する事が可能となっている。これらＷｅｂサービスＡＰＩではＯＡｕｔｈ ２．０と呼ばれる、認可の連携を実現させるための標準プロトコルの採用が進んでいる。非特許文献１にはＯＡｕｔｈ ２．０を利用した技術が開示されているが、詳細については以降で説明する。

ＯＡｕｔｈ ２．０によれば、例えばあるサービスＡが管理するユーザーのデータを取得するＡＰＩに対して、そのユーザーから認められた範囲にてサービスＢがアクセスすることができる。このときサービスＡは、サービスＢからアクセスされる範囲を明らかにした上で、サービスＢによるＡＰＩへのアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。また、このアクセスされる範囲をＯＡｕｔｈ ２．０ではスコープと呼称し、スコープによりデータへのアクセス許容量が決定される。

ユーザーが認可操作を行うと、サービスＢは、サービスＡにおけるユーザーが許可した範囲のデータへのアクセスが認められたことを証明するトークン （以下、認可トークンと称する） を受け取り、以降のサービスＡのＡＰＩへのアクセスはその認可トークンを用いて実現できる。このユーザーの認可操作によりサービスＢがユーザーのリソースに対しアクセスすることを認可したことを権限委譲と称する。

"Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ"、［ｏｎｌｉｎｅ］ Ｄ． Ｈａｒｄｔ、２０１２年８月 ＜ＵＲＬ ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＞

権限移譲を可能とするプロトコルには、サービスにおけるリソースの変更、およびユーザーの権限の変更に対応する柔軟性が欠如している可能性がある。例えば、ＯＡｕｔｈ ２．０の認可トークンは、ユーザーが認可操作する際に確認したスコープのみが権限委譲されている。そのため、ユーザーが権限委譲可能なスコープの変化や、ＡＰＩを利用するためのスコープの増減、変更があった場合に、当該ＡＰＩを利用するためには、ユーザーに再度、認可操作を強いる可能性がり、利便性が損なわれる可能性がある。

本発明は上記課題を鑑みてなされたものであり、ユーザーの利便性を損なうことなく、ユーザーの権限やスコープの定義を変更可能な認可サーバーを提供する事を目的とする。

本発明の一実施形態に係る認可サーバーは、Ｗｅｂサービスを提供するリソースサーバーにおける認証処理および認可処理を実行する認可サーバーであって、前記Ｗｅｂサービスを利用する範囲が定義されたスコープであって、少なくとも１つ以上のスコープを関連付けたスコープグループを指定する認可要求をクライアントから受信する受信手段と、前記クライアントを有する端末により表示された認可確認画面を介し、認証済みユーザーの前記Ｗｅｂサービスにおける権限をクライアントへ移譲するための認可操作を前記ユーザーが行ったことに応じて、前記スコープグループに関連付けられた認可情報を発行する発行手段と、前記クライアントが前記Ｗｅｂサービスを利用するために送信した前記認可情報の検証要求を前記リソースサーバーから受信した際、前記スコープグループと関連付く少なくとも１つ以上のスコープを取得し、前記検証要求が指定する検証対象のスコープが取得された少なくとも１つ以上のスコープに含まれており、かつ前記ユーザーが有する権限で利用できる範囲を定義しているスコープが取得された少なくとも１つ以上のスコープに含まれている場合、前記クライアントは前記検証対象のスコープで定義された範囲で前記Ｗｅｂサービスを利用する権限が移譲されている旨を前記リソースサーバーに送信することを特徴とする。

本発明によれば、ユーザーの利便性を損なうことなく、ユーザーの権限やスコープの定義を変更可能な認可サーバーを提供する事が可能になる。

システム構成図。 各装置のハードウェア構成図。 各装置のソフトウェアモジュール構成図。 ＯＡｕｔｈ ２．０ シーケンス。 ログイン画面例。 ＯＡｕｔｈ ２．０ リフレッシュシーケンス。 認可確認処理フロー。 認可確認画面例。 権限検証処理フロー。 権限、スコープ変更の時系列 第二の実施形態におけるＯＡｕｔｈ ２．０設定画面例。 第二の実施形態における認可確認処理フロー。 第三の実施形態における認可確認画面例。

課題に説明した通り、端末からアクセスされるリソースの範囲、即ちサービスを利用する範囲が定義されたスコープ、およびユーザーの権限は変化するため、ＯＡｕｔｈ２．０を始めとする権限移譲プロトコルには柔軟性が求められる。始めに、スコープおよびユーザーの権限の変化について説明する。エンタープライズの分野では、ユーザーが所有する権限はユーザーの立場によって異なることがある。例えば、会社の特定の機密を含む情報にアクセスできる立場と、そうでない立場によってユーザーが所有する権限に差異があり、ＯＡｕｔｈ ２．０におけるスコープとユーザーが所有する権限には密接な関係がある。つまり、サービスにおけるリソースの範囲を意味するスコープに対しアクセスを可能とする権限、という定義を行い、その権限を特定のユーザーに付与する運用が想定される。なお、ユーザーの立場は当人の社内での役割の変化や業務の変更により変更されるものであるため、ユーザーの権限は何かしらの要因によって都度変更される。つまり、ある時点でのユーザーの権限と、その後の時点でのユーザーの権限は変化しており、ユーザーがサービスに権限委譲することができるスコープの範囲も変化しているのである。

一方、クラウドサービスにおいては、継続的インテグレーション（ｃｏｎｔｉｎｕｏｕｓ ｉｎｔｅｇｒａｔｉｏｎ）、継続的デリバリー、継続的デプロイメントと言われる短期間での新機能リリースを実施する手法やアーキテクチャが注目されている。そして、この短期間で新機能をリリースしていくことは、各種ツールや開発プロセス、設計手法が提供されることによって、さらに拡大していくことが予想される。この短期間でリリースしていくことは、ＷｅｂサービスのＡＰＩの増加や、当該ＡＰＩが取り扱うデータの範囲の拡大、もしくは範囲の変更が短期間で行われることを意味する。

まとめると、ユーザーの権限の変更を要因としたユーザーによる権限委譲可能なスコープの変化、短サイクルリリースによるスコープの増減、およびスコープ定義の変更が行われることが想定される。こう言ったケースが発生し、かつ権限移譲が行われ認可トークンが発行されてしまっている場合、再度ユーザーに認可操作を行わせることでユーザーの権限の変化および／またはスコープの変化に対応した認可トークンを発行する必要がある。本願発明は、この認可操作の手間を省き利便性を高めつつ、ユーザーの権限の変化および／またはスコープの変化に対応した認可トークンの運用を可能にすることを目的としている。

では、始めに本願発明の各実施例にて用いられる用語の定義について説明する。サービスとは、サーバー上で起動するソフトウェアがクライアントからの要求に従い実行されることでそのクライアントに対して提供される機能のことを指す。なお、そのソフトウェアであるＷｅｂアプリケーションのこともサービスと呼ぶ場合もある。本実施の形態においては、クラウドサービスとしてリソースサーバーが提供するサービスがあり、ユーザーは、端末を介してリソースサーバーが提供するサービスを利用している想定で説明している。また、クライアントとは端末上で起動するソフトウェアであり、端末のＷｅｂブラウザーを介してアクセスすることが可能なように構成される、もしくはＷｅｂブラウザーの機能を備えたソフトウェアを起動／制御することが可能なように構成されている。また、リソースサーバーはＷｅｂサービスとしてＡＰＩを公開しており、クライアントはこのＡＰＩを利用する事でユーザーに対してサービスを提供している想定にて説明する。

無論、これは本実施の形態を説明する上での想定であり、クライアントはリソースサーバーと連携する別のサービスとして構成することもできる。なお、リソースサーバー、および端末は各々単数で構成される事を限定しているわけではない。例えば、複数台から構成されたサーバー群がサービスを提供していても良い。よって、本願発明でサーバーシステムと称した場合、１台または複数台から構成されるサーバーを指すこととする。

なお、クライアントがリソースサーバーのＡＰＩを利用するためには、後述するＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔ によるユーザーの認可操作を伴った権限委譲が必要となる。換言すると、ユーザーから権限委譲を受けたクライアントは、リソースサーバーのＡＰＩを利用する事ができるようになる。

次に、本願発明の各実施例にて用いられるリソースサーバーが提供するサービスの例を説明する。リソースサーバーは、不図示の複合機もしくはプリンターからのリクエストに応じて、複合機もしくはプリンターに配信する各種データを配信する機能を備える。ここで、各種データとは、複合機やプリンターがどのような動作をするかを決定するための設定値、複合機やプリンターにインストールするファームウェアやアプリケーションの情報、および、複合機やプリンターに設定することができるオプション機能が考えらえる。また、各種データをどのような順序で設定すべきかといった制御情報や、アプリケーションをインストールするためのライセンス情報、等も含むことができる。

また、本願発明の実施例では、クライアントアプリケーションの機能の例として以下を備えるものとして説明する。クライアントアプリケーションは、複合機やプリンターに配信する各種データを作成し、個々の複合機やプリンター用のデータとしてリソースサーバーにアップロードする機能を備える。

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

２００はＯＡｕｔｈ ２．０を実現するための認可サーバーであり、認可サーバーモジュールが設置されている。３００はリソースサーバーであり、Ｗｅｂサービスとして公開されるＡＰＩを備えるリソースサーバーモジュールが設置されている。４００は端末であり、Ｗｅｂブラウザー４１０、クライアントアプリケーション４２０を備える。端末４００は、例えばＰＣやスマートフォンと呼ばれる携帯端末等である。クライアントアプリケーション４２０は、リソースサーバー３００が備えるリソースサーバーモジュールが公開するＡＰＩを利用する事で、自身が提供する機能と合わせたサービスをユーザーに提供する。ユーザーはＷｅｂブラウザー４１０を用いて認可サーバー２００と通信する。また認可サーバー２００、リソースサーバー３００はＬＡＮ１０１を介して接続されている。また、認可サーバー２００、リソースサーバー３００、および端末４００は、それぞれＷＡＮ１００を介して通信可能に接続されている。また認可サーバー２００は不図示のデータベースサーバーとＬＡＮ１０１を介して接続しており、認可サーバーモジュールが利用するデータを格納するよう構成してもよい。さらには、リソースサーバー３００、認可サーバー２００も同一のサーバー上に構成されていてもよい。

本実施の形態に係る権限移譲システムは、図２に示すような構成のサーバーおよび端末から成るシステム上に実現される。図２は、認可サーバー２００、リソースサーバー３００および端末４００のハードウェア構成を示す。なお、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の各サーバーおよび端末には一般的な情報処理装置のハードウェア構成やＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供される情報処理装置の仮想的なハードウェア構成を適用できる。

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

なお、ＩａａＳとして提供される仮想的な情報処理装置の場合においては、ＫＢＣ２００５、ＣＲＴＣ２００６等を備えず、ＮＣ２００８を介して接続される端末に備えるキーボード２００９や、ＣＲＴディスプレイ２０１０から操作されるよう構成される。尚、後述の全ての説明においては、特に断りのない限りサーバーや端末における実行のハード上の主体はＣＰＵ２００１であり、ソフトウェア上の主体は外部メモリ２０１１にインストールされたアプリケーションプログラムである。

図３は本実施の形態に係る、認可サーバー２００、リソースサーバー３００それぞれのモジュール構成を示す図であり、各々がモジュールを実行することでサービスを提供する。なお認可サーバー２００、リソースサーバー３００は図２のものと同一である。端末４００のソフトウェアモジュールを含め、権限移譲システム内の装置が有するソフトウェアモジュールは、各装置のＣＰＵ２００１がＲＡＭ２００２にロードされたプログラムを実行することで実現される。

図中２００は認可サーバー２００である。認可サーバー２００は認可サーバーモジュール２１０、ＨＴＴＰサーバーモジュール２２０を持つ。ＨＴＴＰサーバーモジュール２２０はＷＡＮ１００を介して接続する端末４００に設置されたＷｅｂブラウザー４１０、クライアントアプリケーション４２０とのＨＴＴＰ通信を行うためのモジュールである。また、ＳＳＬ／ＴＬＳによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施例では、後述する認可要求を受け付けた場合に、要求元に対してユーザーＩＤ、パスワードによるユーザー認証を要求するよう構成している。次に、認可サーバーモジュール２１０はＨＴＴＰサーバーモジュール２２０上もしくは、連携して動作するＷｅｂアプリケーションであり、ＨＴＴＰサーバーモジュール２２０を介してＷｅｂブラウザー４１０からの要求を受け付け、処理し、応答する。その際、本実施例では、ＨＴＴＰサーバーモジュール２２０にてユーザー認証を受け付け、要求元の認証に成功した場合、認証したユーザー情報を紐づけた認証トークンを生成し認可サーバーモジュール２１０に認証トークンを通知するよう構成されている。

ここで、認証トークンとはユーザーを認証しユーザーがログインしている事を示す、もしくはユーザーが認証されているかを検証するためのトークンであり、この認証トークンを利用する事でユーザーを識別する事が可能となる。後述の認可コードは、認証されたユーザーの認可操作により権限移譲されたクライアントが、ユーザーの権限をもってユーザーに成り代わりアクセスすることを許可した事を示すためのトークンであり、両者は異なる。特に顕著なのは、認証トークンの場合はユーザーの確認を目的としているが、認可トークンは権限の確認を目的としている点である。

また、認可トークンは、クライアントが認可コードを用いて取得し、クライアントがＡＰＩを利用するための権限を持つことを示すトークンである。さらには、リフレッシュトークンは、同じく認可コードを用いて取得し認可トークンを再発行することが可能であることを示すトークンである。ＨＴＴＰサーバーモジュール２２０、および認可サーバーモジュール２１０における処理の詳細は後述する。認可サーバーモジュール２１０はＬＡＮ１０１を介してリソースサーバーモジュール３１０からの認可トークンの権限検証処理を受け付け、処理し、クライアントによるリソースサーバー３００へのアクセス可否に関する応答を行うよう構成されている。この認可トークンの権限検証処理は、ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）として構成する事も可能であるし、ＨＴＴＰサーバーモジュール２２０を介してＬＡＮ１０１内で通信可能なＷｅｂサービスのＡＰＩとして構成する事も可能である。

図中３００はリソースサーバー３００である。リソースサーバー３００はリソースサーバーモジュール３１０を持つ。リソースサーバーモジュールは不図示のＨＴＴＰサーバーモジュール上で動作するよう構成する事も可能である。リソースサーバーモジュール３１０はＷｅｂサービスとして公開するＡＰＩを備えており、後述するクライアントアプリケーション４２０からのリソース要求を受け付け、処理し、応答する。また、リソースサーバーモジュール３１０は認可サーバーモジュール２１０に対してＬＡＮ１０１を介して後述の認可トークンの権限検証処理を要求する。

次に、図４、図５および各表を用いて、クライアントアプリケーション４２０が、リソースサーバーモジュール３１０が公開するＡＰＩを利用するまでの本実施形態のシーケンスを説明する。なお、図中“Ｒｅｆ”は参照を示しており、別図で説明する。また、“Ａｌｔ”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。

まず、認可サーバーモジュール２１０のユーザーテーブルおよびクライアントテーブルのデータ例を示す。

また、認可サーバーモジュール２１０のスコープ定義テーブルのデータ例を示す。

本実施形態では、ユーザーの権限として上述の設定値に対する全ての操作が可能な管理者権限、設定値を編集可能な設定値編集者権限、設定値を参照することができる設定値参照者権限、および、設定値を反映する複合機やプリンターなどのデバイスを特定するための情報を設定値に設定するデバイス設定者権限、が定義されている。通常、権限とスコープは対応付けて定義し、スコープによりデータへのアクセス範囲が決定される。スコープはリソースサーバーモジュール３１０が提供するサービスを利用する範囲を定義しており、これによりデータへのアクセス許容量が決定される。

例えば、設定値参照者の権限に対応する「ｒｅａｄ」というスコープが定義されていた場合、クライアントアプリケーション４２０は、この「ｒｅａｄ」というスコープを用いて権限移譲プロトコルを実施し、「ｒｅａｄ」スコープに対応する認可トークンを取得することが可能である。そしてこの認可トークンを用いることで、リソースサーバーモジュール３１０の各種設定値を参照するためのＡＰＩを利用することが可能となる。しかしながら、この認可トークンでは設定値を編集するＡＰＩを利用することはできない。クライアントアプリケーション４２０が設定値を編集するためには、その権限に対応する「ｅｄｉｔ」というスコープを指定して認可トークンを取得する必要がある。

そこで権限移譲プロトコルを実施する際に、クライアントアプリケーション４２０に「ｒｅａｄ」、「ｅｄｉｔ」の両方のスコープを指定することが考えられる。しかしながら、ユーザー自身に設定値編集者の権限が付与されていない場合、認可確認の処理でエラーとなり、認可トークンを取得することができない。

本実施形態では、複数のスコープをグルーピングし、そのグループ内のスコープに対応する権限のうち少なくとも一つの権限を所持している場合は、認可確認処理にて認可トークンの発行を許可するスコープグループという定義を追加する。より具体的には、例えば、「ａｄｍｉｎ」、「ｅｄｉｔ」、「ｒｅａｄ」、「ｄｅｖｉｃｅ」というスコープをまとめた「ｇｒｏｕｐ」というスコープグループを定義する。「ｇｒｏｕｐ」は、表３で示された全てのスコープと関連付いているため、グループ権限が与えられたユーザーは現時点におけるリソースサーバーモジュール３１０が提供する全ての機能を使用できる。そして、「ｇｒｏｕｐ」スコープを指定して権限移譲プロトコルを実施することで、設定値参照者権限しか所持していないユーザーであっても認可トークンを取得することができるようになる。

ただし、ユーザーは設定値編集権限を所持しないため、「ｇｒｏｕｐ」を指定した認可トークンであっても、リソースサーバーモジュール３１０の設定値を編集するＡＰＩが利用できてはならない。そこでリソースサーバーモジュール３１０は取得した認可トークンと、設定値を編集するＡＰＩのスコープである「ｅｄｉｔ」を指定して、認可サーバーモジュール２１０に対して、ユーザーが権限を所持しているかを検証するための権限検証処理を依頼する。権限検証処理の詳細については後述する。

スコープグループの処理により、ユーザーは自身の権限に変更があったとしても、「ｇｒｏｕｐ」を指定して取得した認可トークンであれば、ユーザーの権限に即したＡＰＩ利用が可能となる。また、リソースサーバーモジュール３１０にて、例えば、設定値の制御順序を変更するためのスコープ「ｏｒｄｅｒ」が必要なＡＰＩを新規追加し、認可サーバーモジュール２１０にてスコープ定義「ｏｒｄｅｒ」を追加した場合、通常は、「ｏｒｄｅｒ」スコープを指定して、再度権限移譲プロトコルを実施する必要がある。しかしながら、「ｏｒｄｅｒ」スコープをスコープグループ「ｇｒｏｕｐ」に紐づけて定義することで、ユーザーに権限が付与されている限り、「ｇｒｏｕｐ」を指定して取得した認可トークンは設定値の制御順序を変更するためのＡＰＩを利用するためのトークンとして利用できる。

なお、認可サーバーモジュール２１０は、リソースサーバー３００に追加された新しい機能を呼び出すＡＰＩの実装に伴い送信されるそのＡＰＩに対応する新たなスコープを定義する要求を受信したことに応じて、スコープ定義テーブルに新たなスコープを定義する。その際に、「ｇｒｏｕｐ」に対して新たなスコープを関連付けることもできるが、場合によっては、「ｇｒｏｕｐ」に新たなスコープを関連付けないことも可能である。新たなスコープを定義する要求は、端末４００と同じ構成を有する不図示のコンピュータから送信できる。以下、これら処理の詳細について説明する。

本実施形態のシーケンスで説明するユーザーは、ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」および、そのパスワードを利用するとして説明する。また、本シーケンスで説明するクライアントアプリケーション４２０は、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」の各種データである、シークレット、リダイレクトＵＲＩを保持している。このリダイレクトＵＲＩは、クライアントアプリケーション４２０が、認可応答を受け付けるためのＵＲＩである。これらデータは、あらかじめ認可サーバーモジュール２１０に登録されている必要があるが、登録手段については不図示の画面を用いた方法や、認可サーバーモジュール２１０が公開するＡＰＩによって実施する手段が考えられる。

Ｓ１．１にて、ユーザーはＷｅｂブラウザー４１０に表示されている不図示の連携開始操作を実行する。Ｓ１．２にてＷｅｂブラウザー４１０からクライアントアプリケーション４２０に連携開始が通知される。なお、Ｓ１．１、Ｓ１．２の処理については、ユーザーがクライアントアプリケーション４２０から操作し、クライアントアプリケーション４２０がＷｅｂブラウザー４１０を呼び出すよう構成することもできる。連携開始を受けたクライアントアプリケーション４２０はＳ１．３にて、Ｗｅｂブラウザー４１０、ＨＴＴＰサーバーモジュール２２０を介して認可サーバーモジュール２１０に対して認可要求を行う。

本実施例では、権限移譲プロトコルとしてＯＡｕｔｈ ２．０に定義されているＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔフローをベースに本願発明の特徴的な構成を説明する。なお、認可要求には、少なくとも、前述のクライアントアプリケーション４２０が保持しているクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」およびリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」を含み、クライアントアプリケーション４２０がユーザーから権限委譲されるリソースの範囲を示すスコープを含む。ここで、スコープとしては、「ｒｅａｄ」を指定した場合と、スコープグループ「ｇｒｏｕｐ」を指定した場合とをそれぞれ説明する。なお、リダイレクトＵＲＩは前述したとおり、認可サーバー２００にて発行された認可コードを受け付けるクライアントアプリケーション４２０のＵＲＬである。

Ｓ１．４にて、Ｗｅｂブラウザー４１０から認可要求を受け付けたＨＴＴＰサーバーモジュール２２０は、Ｗｅｂブラウザー４１０からの通知に、ＨＴＴＰ Ｃｏｏｋｉｅとして有効な認証トークンが含まれているか検証する。含まれている場合、ＨＴＴＰサーバーモジュール２２０は、認証トークンを認可サーバーモジュール２１０に通知し、Ｓ１．９に移行する。含まれていない場合は、以下の処理を実行する。

Ｓ１．５にて、ＨＴＴＰサーバーモジュール２２０は、ユーザー認証をするためにログイン画面をＷｅｂブラウザー４１０に応答する。ここで図５はＨＴＴＰサーバーモジュール２２０が応答するログイン画面例である。本実施例ではユーザーはユーザーＩＤおよびパスワードを入力し、それらの組が認可サーバーモジュール２１０のユーザーテーブルに登録されている情報の組と一致する場合に認証するよう構成されている。なおユーザーを認証する手段として他の手段、例えば、Ｘ．５０９の証明書や、パスワードを複数回入力する多段階認証等、別の手段を構成する事も可能であり、本手段に限定するものではない。

図５のログイン画面５０００は、ユーザーＩＤを入力するユーザーＩＤ入力欄５００１、パスワードを入力するパスワード入力欄５００２、およびログイン操作を実行するためのログインボタン５００３から成る。ユーザーはＷｅｂブラウザー４１０に表示されたログイン画面５０００に必要な情報を入力し、ログインボタン５００３を押下する。Ｗｅｂブラウザー４１０は入力された情報をＨＴＴＰサーバーモジュール２２０に送信する。ＨＴＴＰサーバーモジュール２２０はユーザーＩＤ、パスワードを取得し、ユーザーテーブルのユーザーＩＤ、パスワードの情報の組と比較し一致するかを検証する事でユーザーを認証する。

本実施形態では、ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」、パスワード「ｕｓｅｒ」がログイン画面５０００に入力され、ＨＴＴＰサーバーモジュール２２０は、それらデータを検証し、認証する。なお、ＨＴＴＰサーバーモジュール２２０は、ユーザー認証に失敗、つまり、ユーザーテーブルに情報が登録されていない場合は、不図示の認証エラー画面をＷｅｂブラウザー４１０に応答する。ユーザー認証に成功した場合、ＨＴＴＰサーバーモジュール２２０は認証トークンを生成する。この認証トークンはＨＴＴＰサーバーモジュール２２０の不揮発メモリ上に、ユーザーＩＤに対応するＵＵＩＤと対応付けて保存される。なおＵＵＩＤとは、Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒであり、重複しないユニークなＩＤである。

本実施例では、ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」に対応するＵＵＩＤ「１００００００１」に対応付けて保存される。そして、ＨＴＴＰサーバーモジュール２２０は、認証トークンを認可サーバーモジュール２１０に通知する。なお、この認証トークンはＨＴＴＰ Ｃｏｏｋｉｅとして設定され、ＨＴＴＰサーバーモジュール２２０からＷｅｂブラウザー４１０への応答に設定され通知される。以後、Ｗｅｂブラウザー４１０から認可サーバーモジュール２１０へのアクセスは上記のとおり、ＨＴＴＰサーバーモジュール２２０による認証トークンの検証、認証処理、および認証トークンの認可サーバーモジュール２１０への通知が実行されるとして説明を省略する。

Ｓ１．９にて、認証トークンを含む認可要求を受け付けた認可サーバーモジュール２１０は、Ｓ１．１０にて、受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＩの組が正しいか検証する。より具体的には、クライアントテーブルに登録されているクライアントＩＤとリダイレクトＵＲＩの組が一致するか検証する。不一致の場合、認可サーバーモジュール２１０は不図示のエラー画面を、ＨＴＴＰサーバーモジュール２２０を介してＷｅｂブラウザー４１０に応答する。一致した場合、認可サーバーモジュール２１０はＳ２．１で認可確認処理を実施する。この認可確認処理Ｓ２．１については後述する。

次に、認可サーバーモジュール２１０において、認可確認処理Ｓ２．１の結果が［許可応答］であった場合のシーケンスについて説明する。Ｓ３．１にて認可サーバーモジュール２１０は、認可コードを発行する。より具体的には、トークンＩＤ「ｃｄ＿０００００１」、もしくは「ｃｄ＿０００００２」を発行し、認可要求に含まれるクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」とリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」、スコープ、認証済みのユーザーのユーザーＩＤに対応するＵＵＩＤ「１００００００１」を認可サーバーモジュールのトークンテーブルに登録する。およびその際、トークン種別を認可コードとし、有効期限として当該認可コードが有効である期限の日時を登録する。

以下に、認可サーバーモジュール２１０のトークンテーブルの例を示す。例では、トークンが有効か否かを示す状態を「有効」として登録しているが、有効期限を検証することで有効性を毎度確認する構成としてもよい。なおスコープとしては、「ｒｅａｄ」、もしくはスコープグループ「ｇｒｏｕｐ」がそれぞれ設定される。

そして、Ｓ３．２、Ｓ３．３にて認可サーバーモジュール２１０は発行した認可コードのトークンＩＤ「ｃｄ＿０００００１」もしくは「ｃｄ＿０００００２」を付与してＷｅｂブラウザー４１０を介し、クライアントアプリケーション４２０に認可を応答する。より具体的には、認可要求時に取得したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」に対してＷｅｂブラウザー４１０をリダイレクトするようＷｅｂブラウザー４１０にリダイレクト応答する。

Ｓ３．４にてクライアントアプリケーション４２０は、認可サーバーモジュール２１０に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード「ｃｄ＿０００００１」もしくは「ｃｄ＿０００００２」、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」、および認可要求時に送信したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」が含まれる。

Ｓ３．５にて認可サーバーモジュール２１０は取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」の組をもってクライアントを認証する。より具体的には、クライアントテーブルの組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合はクライアントアプリケーション４２０に認証エラーを応答する。クライアント認証に成功した場合、Ｓ３．６にて認可サーバーモジュール２１０は、取得した認可コード「ｃｄ＿０００００１」もしくは「ｃｄ＿０００００２」を検証する。認可コードの検証としては、取得した認可コードがトークンテーブルに登録されているか、登録されている場合は、有効かを検証する。さらには、認可トークン要求にて取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」とリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」がトークンテーブルのクライアントＩＤ、リダイレクトＵＲＩと一致するかを検証する。

認可コード検証の結果が無効であった場合、認可サーバーモジュール２１０はクライアントアプリケーション４２０にトークン不正エラーを応答する。そして、認可コード検証の結果が有効であった場合、認可サーバーモジュール２１０はＳ３．７にて認可トークンを発行する。より具体的には、トークンＩＤ「ａｔ＿０００００１」もしくは「ａｔ＿０００００２」を発行し、認可コードに紐づくユーザーのＵＵＩＤ「１００００００１」、スコープ「ｒｅａｄ」もしくは「ｇｒｏｕｐ」、および認証したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークンテーブルに登録する。その際、トークン種別は認可トークンとし、有効期限として当該認可トークンが有効である期限の日時を登録する。さらに認可サーバーモジュール２１０はＳ３．８にてリフレッシュトークンを発行する。より具体的には、トークンＩＤ「ｒｔ＿０００００１」もしくは「ｒｔ＿０００００２」を発行し、それぞれの認可トークンに紐づくユーザーのＵＵＩＤ「１００００００１」、スコープ、および認証したクライアントＩＤをトークンテーブルに登録する。その際、トークン種別はリフレッシュトークンとし、有効期限として当該リフレッシュトークンが有効である期限の日時を登録する。

なお、ＯＡｕｔｈ ２．０の場合は、認可コードは一度しか利用できないように制御することが推奨されているため、トークンＩＤ「ｃｄ＿０００００１」、「ｃｄ＿０００００２」の認可コードの状態を「無効」にする。無効にする処理として、状態を利用するのではなく、有効期限を過去の日時に更新することで無効扱いとすることや、テーブルのレコードそのものを削除することで無効にするという方法でもよい。

以下に認可サーバーモジュール２１０のトークンテーブルの例を示す。例では、表４で示した認可サーバーモジュール２１０のトークンテーブルに対してデータが追加された状態を示している。

そして、Ｓ３．９にて認可サーバーモジュール２１０は発行した認可トークンのトークンＩＤ「ａｔ＿０００００１」もしくは「ａｔ＿０００００２」、リフレッシュトークンのトークンＩＤ「ｒｔ＿０００００１」もしくは「ｒｔ＿０００００２」をクライアントアプリケーション４２０に応答する。

認可トークンを取得したクライアントアプリケーション４２０は、Ｓ３．１０にてリソースサーバーモジュール３１０が公開するＡＰＩに対してリソース要求を行う。より具体的には、それぞれの認可トークンを用いて設定値を参照するためのＡＰＩを呼び出したとして説明する。

リソース要求を受けたリソースサーバーモジュール３１０は、Ｓ３．１１にて認可サーバーモジュール２１０に対して権限検証を要求する。その際、リソースサーバーモジュール３１０は、取得した認可トークン「ａｔ＿０００００１」もしくは「ａｔ＿０００００２」および検証対象である要求されたリソースのスコープである「ｒｅａｄ」を認可サーバーモジュール２１０に渡す。Ｓ４．１の認可サーバーモジュール２１０における権限検証処理については後述する。

Ｓ３．１２にてリソースサーバーモジュール３１０は認可サーバーモジュール２１０から権限検証の結果を取得する。結果、許可であった場合はＳ３．１３にてリソース、より具体的には要求された設定値をリソースサーバーモジュール３１０は取得し、Ｓ３．１４にてクライアントアプリケーション４２０に応答する。権限検証の結果、拒否であった場合は、Ｓ３．１３をスキップし、Ｓ３．１４にてクライアントアプリケーション４２０にエラーを応答する。

次に、認可サーバーモジュール２１０において、認可確認処理Ｓ２．１の結果が［拒否応答］であった場合のシーケンスについて説明する。Ｓ５．１、Ｓ５．２にて認可サーバーモジュール２１０は、Ｗｅｂブラウザー４１０を介し、クライアントアプリケーション４２０に拒否応答を応答する。より具体的には、認可要求時に取得したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」に対してＷｅｂブラウザー４１０をリダイレクトするようＷｅｂブラウザー４１０にリダイレクト応答する。

以上が、クライアントアプリケーション４２０が、リソースサーバーモジュール３１０が公開するＡＰＩを利用するまでの、権限移譲プロトコルを利用した本実施形態のシーケンスである。ＯＡｕｔｈ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔ を例に認可トークンの発行処理について説明したが、権限移譲プロトコルであればこれに限るモノではない。例えば、必ずしも認可コードの発行の必要はなく、最終的に認可情報である認可トークンが発行されさえすれば良い。

次に、図６を用いて、クライアントアプリケーション４２０が認可トークンをリフレッシュし、リソースサーバーモジュール３１０が公開するＡＰＩを利用するための権限移譲プロトコルにおけるリフレッシュシーケンスを説明する。なお、図中“Ａｌｔ”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。また、“Ｏｐｔ”はオプションであり、処理を省くことも可能である。

なお本シーケンスは、Ｓ６．１のユーザー操作から開始されるケースと、クライアントアプリケーション４２０が自身の処理中にて開始するケースとがある。そのため、Ｓ６．１、Ｓ６．２はオプションとして記載している。

Ｓ６．１にてユーザーは、Ｗｅｂブラウザー４１０に表示されている不図示の再実行操作を行う。Ｓ６．２にてＷｅｂブラウザー４１０からクライアントアプリケーション４２０に再実行が通知される。再実行を受け付けたクライアントアプリケーション４２０は、Ｓ７．１にて、リソースサーバーモジュール３１０が公開するＡＰＩに対して、すでに取得済みの認可トークン「ａｔ＿０００００１」、もしくは「ａｔ＿０００００２」を用いてリソース要求を行う。ここで、それぞれの認可トークンは有効期限に達しており、無効状態になっているとして説明する。

Ｓ７．２にて、リソースサーバーモジュール３１０は、認可サーバーモジュール２１０に対して認可トークンが有効であるか否かを問い合わせるための認可トークン検証要求を行う。認可サーバーモジュール２１０は、トークンテーブルを参照し、認可トークンが有効か否かを確認し、結果を応答する。前述の通り無効であるため、認可サーバーモジュール２１０は、Ｓ７．３にて、リソースサーバーモジュール３１０に対して、認可トークン無効応答を送信する。そして、Ｓ７．４にてリソースサーバーモジュール３１０はクライアントアプリケーション４２０に対して認可トークンが無効であるとして認可トークン無効応答を返す。

Ｓ７．５にて、クライアントアプリケーション４２０は認可サーバーモジュール２１０に対して認可トークンリフレッシュ要求を行う。その際、認可トークン、リフレッシュトークン応答にて取得したトークンＩＤ「ｒｔ＿０００００１」もしくは「ｒｔ＿０００００２」、および、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」を送信する。

Ｓ７．６にて認可サーバーモジュール２１０は取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」の組をもってクライアントを認証する。より具体的には、クライアントテーブルの組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合はクライアントアプリケーション４２０に認証エラーを応答する。クライアント認証に成功した場合、Ｓ７．７にて認可サーバーモジュール２１０は、取得したリフレッシュトークンを検証する。認可コードの検証としては、取得したリフレッシュトークンがトークンテーブルに登録されているか、登録されている場合は、有効かを検証する。さらには、認可トークンリフレッシュ要求にて取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」がトークンテーブルのクライアントＩＤと一致するかを検証する。リフレッシュトークン検証の結果が［無効］であった場合の処理は後述する。ここで、リフレッシュトークン検証の結果が［有効］であった場合、認可サーバーモジュール２１０はＳ８．１で認可確認処理を実施する。この認可確認処理Ｓ８．１については、先述のＳ２．１の認可確認処理と合わせて後述する。

次に、リフレッシュトークン検証の結果が［有効］であり、かつ認可確認処理Ｓ８．１の結果が［許可］であった場合、認可サーバーモジュール２１０はＳ９．１にて認可トークンを発行する。より具体的には、トークンＩＤ「ａｔ＿０００００３」、もしくは「ａｔ＿００００４」を発行し、リフレッシュトークンに紐づくユーザーのＵＵＩＤ「１００００００１」、スコープ「ｒｅａｄ」もしくは「ｇｒｏｕｐ」、および認証したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークンテーブルに登録する。その際、トークン種別は認可トークンとし、有効期限として当該認可トークンが有効である期限の日時を登録する。さらに認可サーバーモジュール２１０はＯＡｕｔｈ ２．０ のオプションの仕様としてＳ９．２にてリフレッシュトークンを再発行するよう構成することもできる。その場合は、Ｓ９．３にて利用したリフレッシュトークンを無効化する。より具体的には、トークンＩＤ「ｒｔ＿０００００３」、「ｒｔ＿００００４」をそれぞれ発行し、さらに、「ｒｔ＿０００００１」、「ｒｔ＿００００２」のリフレッシュトークンの状態を「無効」にする。本実施の形態では、リフレッシュトークンの再発行処理は実施しない方式で説明する。

そして、Ｓ９．４にて認可サーバーモジュール２１０は発行した認可トークンのトークンＩＤをクライアントアプリケーション４２０に応答する。認可トークンを取得したクライアントアプリケーション４２０は、Ｓ９．５にてリソースサーバーモジュール３１０が公開するＡＰＩに対してリソース要求を行う。これ以降の処理については、図４中のＳ４．１および、Ｓ３．１２からＳ３．１４までの処理と同様であるため説明を省略する。

次に、認可サーバーモジュール２１０において、認可確認処理Ｓ８．１の結果が［無効］もしくは認可確認証にて［拒否］であった場合のシーケンスを説明する。Ｓ９．１にて認可サーバーモジュール２１０はクライアントアプリケーション４２０に対してリフレッシュトークンが無効であると応答する。リフレッシュトークンの無効応答を受信したクライアントアプリケーション４２０は、前述のＳ１．３認可要求を実施する。その後の処理は図４を用いて説明したシーケンスと同様出るため説明を省略する。

以上が、クライアントアプリケーション４２０が認可トークンをリフレッシュし、リソースサーバーモジュール３１０が公開するＡＰＩを利用するための権限移譲プロトコルにおけるリフレッシュシーケンスである。

続いて、本実施の形態の特徴の一つである、図４を用いて説明した認可確認処理Ｓ２．１について図７、図８を用いて説明する。この認可確認処理Ｓ２．１を用いることで、前述のスコープグループによる認可トークンの発行が可能となる。

認可確認処理Ｓ２．１にて、認可サーバーモジュール２１０は、Ｓ１０．１にてユーザーＩＤに対応するＵＵＩＤ、スコープを取得する。ここでＵＵＩＤ「１００００００１」で、スコープ「ｒｅａｄ」、もしくはスコープ「ｇｒｏｕｐ」であったとして説明する。次に、認可サーバーモジュール２１０はＳ１０．２にて、Ｓ１０．１にて取得したＵＵＩＤを用いて、ユーザーの権限を取得する。より具体的には、ＵＵＩＤ「１００００００１」を用いて認可サーバーモジュール２１０のユーザーテーブルから権限情報「デバイス設定者」、「設定値参照者」を取得する。

Ｓ１０．３にて認可サーバーモジュール２１０は、Ｓ１０．１で取得したスコープが複数だった場合のループ処理を説明しているが、本実施例では「ｒｅａｄ」、もしくは「ｇｒｏｕｐ」とそれぞれ単独でスコープが指定された場合として説明する。

認可サーバーモジュール２１０は、Ｓ１０．４にてスコープがスコープグループか否かで処理を分岐する。その際、認可サーバーモジュール２１０のスコープ定義テーブルの権限情報を確認し、ここが「グループ」であった場合はスコープグループであるとして説明するが、その方式に限るわけではない。例えば、別途スコープかスコープグループかを区別するための項目を増やすことも考え得るし、スコープＩＤの形式としてプレフィックスやポストフィックスを付与したスコープＩＤとして、その付与された情報で判別可能とすることもできる。結果、「ｒｅａｄ」の場合は、スコープグループではないのでＳ１０．５へ、「ｇｒｏｕｐ」の場合はスコープグループであるため、Ｓ１０．８へ処理を分岐する。

Ｓ１０．５にて認可サーバーモジュール２１０はスコープとユーザーの権限の確認を行う。より具体的には、スコープ定義テーブルの権限情報が、Ｓ１０．２で取得したユーザーの権限に含まれているか否かを確認する。より具体的には、「ｒｅａｄ」スコープは権限情報として「設定値参照者」が定義されているため、Ｓ１０．２で取得したユーザーの権限に「設定値参照者」が含まれているかが確認される。Ｓ１０．６にて権限ありとなった場合は、Ｓ１０．３のループ処理を継続し、すべてのスコープに対して権限ありとなった場合、Ｓ１０．１１へ処理を継続する。Ｓ１０．６にて権限なし、となった場合はＳ１０．７にて権限エラーを応答し、処理を終了する。本実施例ではユーザーの権限に「設定値参照者」が含まれているため、権限あり、としてＳ１０．１１ へ処理を継続する。

Ｓ１０．４の判定の結果、スコープグループだった場合、認可サーバーモジュール２１０はＳ１０．８にてスコープグループに紐づく全スコープを取得する。より具体的には、表３で示すスコープ定義テーブルからグループ情報を取得する。本実施例では「ｇｒｏｕｐ」スコープのグループ情報は「ａｄｍｉｎ， ｅｄｉｔ， ｒｅａｄ， ｄｅｖｉｃｅ」が定義されている。次に、Ｓ１０．９に取得した全スコープの各々に対してＳ１０．５で説明したスコープとユーザーの権限の確認処理を実施する。そして、Ｓ１０．１０にて、全スコープのうち１個でもユーザーが権限を有している場合は、権限あり、としてＳ１０．３のループ処理を継続し、すべてのスコープに対して権限ありとなった場合、Ｓ１０．１１へ処理を継続する。

Ｓ１０．１０にて全て権限なし、となった場合はＳ１０．７にて権限エラーを応答し、処理を終了する。本実施例ではユーザーの権限に「設定値参照者」、「デバイス設定者」が含まれており、さらに、「ｒｅａｄ」スコープ、「ｄｅｖｉｃｅ」スコープの権限情報がそれぞれ一致するため、２個権限を有していることになる。結果、Ｓ１０．１０にて権限あり、としてＳ１０．１１ へ処理を継続する。なお、１個でも権限を有している場合に権限ありと判断するため、Ｓ１０．８で取得するスコープ全てに対して権限を確認せず、途中、１個でも権限あり、と判断された場合に処理を中断し、Ｓ１０．１０にて権限あり、と判断するよう処理を構成することもできる。

Ｓ１０．１１にて認可サーバーモジュール２１０は認可確認画面をＷｅｂブラウザー４１０に応答する。図８ａはスコープグループではないスコープが指定された場合に応答される認可確認画面の例である。また、図８ｂはスコープグループが指定された場合に応答される認可確認画面の例である。これら画面の共通の部分に関しては、同一の番号を付与している。認可確認画面８０００、８１００は、認可要求に含まれるクライアントＩＤをキーとしてクライアントテーブルから取得したクライアント名を表示する領域であるアクセス元表示領域８００１を備える。さらに、認可要求で取得したスコープに対応する説明を表示する領域である委譲権限表示領域８００２を備える。本実施例の場合、リソースサーバーモジュール３１０の提供するサービスの内の全ての機能に対応するスコープがスコープグループを示す「ｇｒｏｕｐ」に関連付いているので、全てのスコープに対応する権限の内のユーザーが所持している権限が権限移譲の範囲である旨を説明している。

なお、全てのスコープに対応する権限の内のユーザーが所持している権限が権限移譲の範囲である旨を必ずしも認可確認画面８０００に表示する必要はない。しかし、表示しない場合であっても、スコープグループに関連付く少なくとも１つ以上のスコープの範囲、本実施例の場合「ａｄｍｉｎ， ｅｄｉｔ， ｒｅａｄ， ｄｅｖｉｃｅ」の範囲でクライアントアプリケーション４２０がリソースサーバーモジュール３１０が提供するＷｅｂサービスを利用する可能性があることを表示させる必要はある。また、認可確認画面８０００、８１００は、ユーザーが上記情報の内容について認可操作を実行する許可ボタン８００３、および拒否を実行する拒否ボタン８００４を備える。さらに図８ｂが示すように、スコープグループが指定された場合は、委譲権限表示領域８００２で示した移譲する権限の範囲がユーザーの権限の変化によって動的に変更される旨を説明する領域であるスコープグループ説明領域８１０１を備える事もできる。

Ｓ１０．１２にて、Ｗｅｂブラウザー４１０は、取得した認可確認画面８０００もしくは８１００をユーザーに提示する。そして、Ｓ１０．１３にて、ユーザーが許可ボタン８００３、もしくは拒否ボタン８００４を押下した場合は、その認可確認結果を取得し認可サーバーモジュール２１０に通知する。

Ｓ１０．１４にて、認可サーバーモジュール２１０は認可確認結果を取得する。次に、認可サーバーモジュール２１０は、Ｓ１０．１５にて、Ｓ１０．１４で取得した認可確認結果が許可であった場合は、Ｓ１０．１６にて認可確認処理の結果を「許可応答」として処理を終了する。そして、認可確認結果が拒否であった場合は、Ｓ１０．１７にて認可確認処理の結果を「拒否応答」として処理を終了する。

以上が、本実施の形態の特徴の一つである認可確認処理である。この認可確認処理を用いることで、スコープグループによる認可トークンの発行が可能となる。なお、図６で説明したリフレッシュシーケンスにおけるＳ８．１の認可確認処理は、当該処理のうち、Ｓ１０．１のユーザーＵＵＩＤ、スコープ取得を、リフレッシュトークンから行い、さらに、Ｓ１０．３のループ処理が終了した際に、許可応答を返し、Ｓ１０．７の権限エラーの場合に拒否応答を返す処理であることを除いて、その他処理について同様であるため説明を省略する。

続いて、本実施の形態の特徴の一つである、図４を用いて説明した権限検証処理Ｓ４．１について図９を用いて説明する。この権限検証処理Ｓ４．１を用いることで、スコープグループを指定して取得した認可トークンであれば、そのスコープグループ内に含まれるスコープの範囲内にて、権限検証が実施される。そして、そのスコープに対応する権限をユーザーが所持していた場合は権限検証の結果、権限ありと判断される。

Ｓ１１．１にて認可サーバーモジュール２１０は取得した認可トークンから紐づく全スコープ、ユーザーのＵＵＩＤを取得する。本実施の形態では「ａｔ＿０００００１」もしくは、「ａｔ＿０００００２」が認可トークンとして取得された場合をそれぞれ説明する。認可トークン「ａｔ＿０００００１」の場合、認可サーバーモジュール２１０の表５に示すトークンテーブルにて、ユーザーのＵＵＩＤ「１００００００１」、スコープ「ｒｅａｄ」が取得される。認可トークン「ａｔ＿０００００２」の場合、認可サーバーモジュール２１０のトークンテーブルにて、ユーザーのＵＵＩＤ「１００００００１」、スコープ「ｇｒｏｕｐ」が取得される。

次に、Ｓ１１．２にて認可サーバーモジュール２１０は取得されたスコープの数だけループ処理を実施するが、本実施の形態では、それぞれ１個のスコープが取得された場合を説明する。Ｓ１１．３にて認可サーバーモジュール２１０は取得したスコープがスコープグループであるか否かで処理を分岐する。その際、認可サーバーモジュール２１０のスコープ定義テーブルの権限情報を確認し、ここが「グループ」であった場合はスコープグループであるとして説明するが、その方式に限るわけではない。

例えば、別途スコープかスコープグループかを区別するための項目を増やすことも考え得るし、スコープＩＤの形式としてプレフィックスやポストフィックスを付与したスコープＩＤとして、その付与された情報で判別可能とすることもできる。スコープが「ｒｅａｄ」の場合は、スコープグループではないのでＳ１１．２のループ処理を継続し、すべてのスコープに対する処理が完了するとＳ１１．５へ遷移する。また、スコープが「ｇｒｏｕｐ」の場合はスコープグループであるため、Ｓ１１．４へ処理を分岐する。

Ｓ１１．４にて、認可サーバーモジュール２１０はスコープグループに紐づく全スコープを取得する。より具体的には、スコープ定義テーブルからグループ情報を取得する。本実施例では「ｇｒｏｕｐ」スコープのグループ情報は「ａｄｍｉｎ， ｅｄｉｔ， ｒｅａｄ， ｄｅｖｉｃｅ」が定義されている。そして取得したグループ情報を分解し、それぞれスコープを後続の処理対象として記憶する。そして、Ｓ１１．２のループ処理を継続し、すべてのスコープに対する処理が完了するとＳ１１．５へ遷移する。

Ｓ１１．５にて認可サーバーモジュール２１０はＳ１１．１にて取得したＵＵＩＤを用いて、ユーザーの権限を取得する。より具体的には、ＵＵＩＤ「１００００００１」を用いて認可サーバーモジュール２１０のユーザーテーブルから権限情報「デバイス設定者」、「設定値参照者」を取得する。

Ｓ１１．６にて認可サーバーモジュール２１０は権限検証リクエストに含まれる検証対象のスコープの数分ループ処理を実施する。本実施の形態では、検証対象のスコープとして設定値を参照するためのスコープである「ｒｅａｄ」が指定されたとして説明する。

Ｓ１１．７にて認可サーバーモジュール２１０は検証対象のスコープがＳ１１．２のループ処理でスコープグループを分解した結果を含む、トークンから取得した一つないし複数のスコープに含まれているかを検証する。ここで含まれていない場合は、Ｓ１１．８にて本検証対象のスコープに対しては権限がないと判断し、その旨応答として記憶する。そしてＳ１１．７のループ処理を継続する。

一方、Ｓ１１．７の判断にて検証対象のスコープがトークンから取得したスコープに含まれていると判断された場合、Ｓ１１．９にて検証対象のスコープとユーザーの権限の確認を行う。本実施の形態では、検証対象のスコープ「ｒｅａｄ」は、認可トークン「ａｔ＿０００００１」から取得されたスコープが「ｒｅａｄ」であるため、含まれると判断され、Ｓ１１．９に処理を分岐する。また、認可トークン「ａｔ＿０００００２」から取得されたスコープは、「ａｄｍｉｎ」，「ｅｄｉｔ」， 「ｒｅａｄ」， 「ｄｅｖｉｃｅ」であるため、含まれると判断され、Ｓ１１．９に処理を分岐する。

Ｓ１１．９にて認可サーバーモジュール２１０は検証対象のスコープとユーザーの権限の確認を行う。より具体的には、スコープ定義テーブルの権限情報が、Ｓ１１．５で取得したユーザーの権限に含まれているか否かを確認する。より具体的には、検証対象のスコープ「ｒｅａｄ」スコープは権限情報として「設定値参照者」が定義されているため、Ｓ１１．５で取得したユーザーの権限に「設定値参照者」が含まれているかが確認される。Ｓ１１．９にて権限ありとなった場合は、Ｓ１１．１０にて、本検証対象のスコープに対しては権限があるとして記憶する。また、含まれていない場合は、本検証対象のスコープに対しては権限がないとして記憶する。そして、Ｓ１１．７のループ処理を継続し、すべての検証対象のスコープに対して権限検証が終了すると、Ｓ１１．１１にてそれら権限検証の結果を応答し、処理を終了する。その際、記憶された権限検証の結果を全て応答する。例えば、検証リクエストに複数のスコープが含まれていた場合は、それぞれのスコープに対する検証結果が応答される。本実施の形態では、「ａｔ＿００００１」、「ａｔ＿００００２」双方とも、権限あり、という結果が応答される。

以上の処理が、認可サーバーモジュール２１０における権限検証処理である。この処理により、スコープグループを指定して取得した認可トークンであれば、そのスコープグループが分解され検証される。そのため、スコープグループ内のスコープの範囲内であれば、ユーザーの認可処理を実施することなく、ユーザーの権限の検証判断、つまり、Ｓ１１．９の処理を実施することが可能となる。つまり、ユーザーの権限の変更に対し、ユーザーに再度認可確認処理を強いることなく、ユーザーの権限に即した権限検証処理を実施することが可能となる。

次に、図１０を用いてＯＡｕｔｈ２．０を例にスコープ定義に変更があった場合においても、ユーザーの再認可を必要することなくＡＰＩ利用が継続できるケースと、ユーザーの権限に変更があった場合においても、ユーザーの再認可を必要とすることなくＡＰＩ利用が継続できるケースとを時系列で説明する。

図１０ａはスコープ定義の変更とＡＰＩ実行の可否の振る舞いを時系列で示した図である。図中右方向の矢印は時間軸である。また時間軸に対する矢印は矢印がさす特定の時間におけるスコープ定義や、ユーザーの権限、およびクライアントアプリケーション４２０からリソースサーバーモジュール３１０へのＡＰＩ利用および、その結果を示している。

まず、図に示す通り、ユーザー「ｕｓｅｒ＠ｘｘ．ｃｏｍ」は、その権限情報として「デバイス設定者」、「設定値参照者」を所持している。次に、スコープ定義としては図で示している通りである。特にスコープＩＤ「ｇｒｏｕｐ」は、そのメンバーとして「ｒｅａｄ」、「ｄｅｖｉｃｅ」スコープが含まれている。

その状態で、クライアントアプリケーション４２０にてスコープ「ｇｒｏｕｐ」で認可トークン１を取得したとする。認可トークンを取得するためのシーケンスおよびフローについては前述したとおりである。

次に、クライアントアプリケーション４２０は取得した認可トークン１を利用してリソースサーバーモジュール３１０のスコープ「ｒｅａｄ」を要求するリソースへのＡＰＩを実行する。結果、スコープグループ「ｇｒｏｕｐ」にはスコープ「ｒｅａｄ」が含まれており、さらにユーザーはスコープ「ｒｅａｄ」に紐づく権限である「設定値参照者」の権限を有しているため、ＡＰＩの実行は成功する。

次に、クライアントアプリケーション４２０は取得した認可トークン１を利用してリソースサーバーモジュール３１０のスコープ「ｏｒｄｅｒ」を要求するリソースへのＡＰＩを実行する。結果、スコープグループ「ｇｒｏｕｐ」にはスコープ「ｏｒｄｅｒ」が含まれていないため、ユーザーの権限検証されることなく、ＡＰＩの実行は拒否される。ここまでが課題として説明した状態である。つまり、スコープ「ｏｒｄｅｒ」を指定してＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを再度処理し、別の認可トークンを取得しなければこのＡＰＩを利用することができず、ユーザーは認可操作をもう一度実施しなければならない。

次に、スコープ定義のスコープ「ｇｒｏｕｐ」のメンバーにスコープ「ｏｒｄｅｒ」を追加したとする。その後に、クライアントアプリケーション４２０は取得した認可トークン１を利用して再度リソースサーバーモジュール３１０のスコープ「ｏｒｄｅｒ」を要求するリソースへのＡＰＩを実行する。結果、スコープグループ「ｇｒｏｕｐ」にはスコープ「ｏｒｄｅｒ」が含まれており、さらにユーザーはスコープ「ｏｒｄｅｒ」に紐づく権限である「デバイス設定者」の権限を有しているため、ＡＰＩの実行は成功する。

つまりユーザーに権限が付与されている限り、「ｇｒｏｕｐ」を指定して取得した認可トークンは、そのままスコープ「ｏｒｄｅｒ」を必要とするＡＰＩを利用することができる。結果、リソースサーバーモジュール３１０に新しい機能が実装された場合、その機能を呼び出すＡＰＩをクライアントアプリケーション４２０は認可トークンをユーザーに再発行させる処理を要求することなく利用できる。

図１０ｂはユーザー権限の変更とＡＰＩ実行の可否の振る舞いを時系列で示した図である。図中右方向の矢印は時間軸である。また時間軸に対する矢印は矢印がさす特定の時間におけるスコープ定義や、ユーザーの権限、およびクライアントアプリケーション４２０からリソースサーバーモジュール３１０へのＡＰＩ利用および、その結果を示している。

まず、図に示す通り、ユーザー「ｕｓｅｒ＠ｘｘ．ｃｏｍ」は、その権限情報として「デバイス設定者」、「設定値参照者」を所持している。次に、スコープ定義としては図で示している通りである。特にスコープＩＤ「ｇｒｏｕｐ」は、そのメンバーとして「ｒｅａｄ」、「ｄｅｖｉｃｅ」および「ｏｒｄｅｒ」スコープが含まれている。また、「ｏｒｄｅｒ」スコープに紐づく権限情報として「設置作業者」が関連づいている。

その状態で、クライアントアプリケーション４２０にてスコープ「ｇｒｏｕｐ」で認可トークン１を取得したとする。認可トークンを取得するためのシーケンスおよびフローについては前述したとおりである。なお、図示していないが、ここでスコープ「ｏｒｄｅｒ」を指定して認可トークン１の取得を実施しようとした場合、フローで説明したとおりユーザーに権限がないため、取得に失敗する。

次に、クライアントアプリケーション４２０は取得した認可トークン１を利用してリソースサーバーモジュール３１０のスコープ「ｒｅａｄ」を要求するリソースへのＡＰＩを実行する。結果、スコープグループ「ｇｒｏｕｐ」にはスコープ「ｒｅａｄ」が含まれており、さらにユーザーはスコープ「ｒｅａｄ」に紐づく権限である「設定値参照者」の権限を有しているため、ＡＰＩの実行は成功する。

次に、クライアントアプリケーション４２０は取得した認可トークン１を利用してリソースサーバーモジュール３１０のスコープ「ｏｒｄｅｒ」を要求するリソースへのＡＰＩを実行する。結果、スコープグループ「ｇｒｏｕｐ」にはスコープ「ｏｒｄｅｒ」が含まれているが、ユーザーはスコープ「ｏｒｄｅｒ」に紐づく権限である「設置作業者」の権限を有していないため、ＡＰＩの実行は拒否される。ここまでが前提の状態である。

次に、ユーザー「ｕｓｅｒ＠ｘｘ．ｃｏｍ」に「設置作業者」の権限を付与する。その後、クライアントアプリケーション４２０は取得した認可トークン１を利用して再度リソースサーバーモジュール３１０のスコープ「ｏｒｄｅｒ」を要求するリソースへのＡＰＩを実行する。結果、スコープグループ「ｇｒｏｕｐ」にはスコープ「ｏｒｄｅｒ」が含まれており、さらにユーザーはスコープ「ｏｒｄｅｒ」に紐づく権限である「設置作業者」の権限を有しているため、ＡＰＩの実行は成功する。つまり、ユーザーの権限の変更があった場合に、再度ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを処理することなく、そのままスコープ「ｏｒｄｅｒ」を必要とするＡＰＩを利用することができる。

以上、本実施形態によれば、スコープグループを定義しスコープグループを利用して権限委譲することによって、ユーザーの権限の変更があったとしても、ユーザーに再度認可操作を求めることなく変更されたユーザーの権限の範囲内でＡＰＩ利用を継続することができる。また、サービスの新たな機能の実装に伴いスコープに変更があったとしても、同じくユーザーに再度認可操作を求めることなく、ユーザーの権限に応じて新たな機能に対応するＡＰＩを含むＡＰＩ利用を継続することができる。

＜第２の実施形態＞
図７で説明した認可確認処理においてスコープグループが指定された場合、認可確認処理を必要とすることなく取得した認可トークンもしくはリフレッシュした認可トークンを用いることで、ユーザーの権限の範囲内でリソースサーバーモジュール３１０のＡＰＩを利用することが可能であった。

しかしながら、権限委譲するにあたり、例えば、エンタープライズ用途の場合であって組織のセキュリティ要求が厳しいケースや、セキュリティ意識が高いユーザーが利用する場合、認可確認画面にて詳細に明示されていない範囲の権限を委譲することや、現状保持していない権限を委譲することが許可されないケースも考慮される。

そのようなケースの場合に、特定の条件によっては、クライアントアプリケーション４２０がスコープグループを指定して権限移譲プロトコルの処理を開始したとしても、スコープグループとしてではなく、自身が所持している権限の範囲内でのスコープに制限して権限委譲をする手段を第２の実施形態として説明する。

図１１は認可サーバーモジュール２１０における上述の特定の条件、つまりスコープグループを指定されたとしても、グループとしての権限委譲ではなく、その中でユーザーが権限を有する範囲のみに権限委譲をするための条件を設定するＯＡｕｔｈ ２．０設定画面の例である。認可サーバーモジュール２１０が提示するＯＡｕｔｈ ２．０設定画面１１０００は、全体としての設定を行う、全体設定１１００１と、クライアントごとに設定するクライアント設定１１００２と、スコープグループごとに設定するスコープグループ設定１１００３からなる。なお、この設定は、エンタープライズでの利用の場合は、組織全体の設定として備える事も可能であるし、ユーザーごとの設定として備える事も可能である。また、保存ボタン１１００４を押下する事で、認可サーバーモジュール２１０に設定を行う。閉じるボタン１１００５は認可サーバーモジュール２１０に設定を行わずにＯＡｕｔｈ ２．０設定画面を閉じるためのボタンである。

ここで、全体設定１１００１が有効になっている場合は、スコープグループが指定されたとしても、必ず、ユーザーが所持している権限の範囲のみ権限が委譲される設定である。次に、クライアント設定１１００２が有効になっている場合は、有効になっている特定のクライアントからの認可要求の場合は、スコープグループが指定されたとしても、ユーザーが所持している権限の範囲のみ権限が委譲される設定である。最後に、スコープグループ設定１１００３が有効になっている場合は、有効になっている特定のスコープグループが指定されている場合は、そのスコープグループの範囲内において、ユーザーが所持している権限の範囲のみ権限が委譲される設定である。

図１２は図７を用いて説明した認可サーバーモジュール２１０における認可確認処理において、第２の実施形態における処理を追加したフローである。なお、図７と同様の処理を実施する箇所については同じ処理番号を付与しており説明を省略する。 Ｓ１２．１にて、認可サーバーモジュール２１０はユーザー情報やスコープの取得の後、さらにクライアント情報、より具体的には認可要求を行ったクライアントアプリケーション４２０のクライアントＩＤを取得する。本実施の形態では、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」が取得される。次に、Ｓ１２．２にて図１１を用いて説明したＯＡｕｔｈ ２．０設定画面にて特定の条件の設定情報を取得する。

その後、スコープグループに対してＳ１０．８からＳ１０．１０の処理を実施したのちに、Ｓ１２．３にて、認可サーバーモジュール２１０は特定の条件に合致するかを検証する。より具体的には、全体設定１１００１が設定されているか、もしくはＳ１２．１で取得したクライアントＩＤに対応するクライアントがクライアント設定１１００２にて設定されているか、もしくは現在検証しているスコープグループが、スコープグループ設定１１００３にて設定されているか、を確認する。どれが一つの設定が合致した場合は、認可確認必須設定がなされている、としてＳ１２．４へ処理を分岐する。一つも合致しない場合は、Ｓ１０．３のループ処理へ処理を分岐し、以降は図７を用いて説明した通りである。

Ｓ１２．４にて認可サーバーモジュール２１０はＳ１０．９にて確認した際に、スコープとユーザーの権限の確認の結果、権限あり、と判断されたスコープのみを抽出する。そして、認可要求として検証しているスコープグループではなく、抽出した権限を有するスコープのみが認可要求されたとしてスコープを置き換え、Ｓ１０．３のループ処理を継続する。つまり、Ｓ１０．１１の認可確認画面応答において、スコープグループの場合は図１０ｂを応答するとして説明したが、スコープグループではなく、権限を有するスコープに置き換えて応答するため、図１０ａで説明した認可確認画面が応答されることになる。

以降の処理は図７を用いて説明した通りである。

以上、特定の条件によっては、クライアントアプリケーション４２０がスコープグループを指定して権限移譲プロトコルの処理を開始したとしても、スコープグループとしてではなく、自身が所持している権限の範囲内でのスコープに制限して権限委譲をすることができる。

＜第３の実施形態＞
図１２で説明した認可確認処理では、特定の条件を設定した場合のみ、認可確認を強制するとして説明した。しかしながら、例えば、コンシューマー利用の場合はあらかじめＯＡｕｔｈ ２．０設定を実施しておくことは煩雑であり、設定が漏れた場合は自動的にスコープグループとして認可確認処理が実施される。それは悪意あるシステム管理者によって、認可サーバーモジュール２１０のスコープ定義を変更することによって、ユーザーが意図していない権限委譲を実施したことにすることが可能となってしまう。

例えば、ユーザーが認可することに抵抗が少ないスコープグループを定義し、ユーザーに認可操作を行わせ、その後、ユーザーが認可をためらうようなスコープをそのスコープグループに所属させるといったことを行うことが可能となってしまう。そこで、第３の実施形態として、ユーザーが認可操作をするごとに、スコープグループとして権限を委譲するか、自身の権限の範囲内のみで権限を委譲するかを選択することを可能とした形態を説明する。なお、第３の実施形態は、第１の実施形態もしくは第２の実施形態の権限移譲システムにて実施される。

図１３は、図７もしくは図１２で説明した認可確認処理のうち、スコープグループが権限委譲されるケースにおけるＳ１０．１１にて応答する認可確認画面の例である。ここで、図８ｂとして説明した認可確認画面８１００に対して、ユーザー確認項目１３００１としてスコープグループとして権限を委譲するか否かを選択可能とする項目を設ける。ここでユーザー確認項目１３００１を選択すると、認可サーバーモジュール２１０は、Ｓ１０．９にて確認した際に、スコープとユーザーの権限の確認の結果、権限あり、と判断されたスコープのみを抽出し、そのスコープを委譲権限表示領域８００２に再表示する。結果、図１３で示した認可確認画面１３０００の委譲権限表示領域８００２の状態から、図８ａで示した認可確認画面８０００の委譲権限表示領域８００２の状態に変更される。

その後に、許可ボタン８００３が押下されると、認可サーバーモジュール２１０はＳ１０．１６の処理にて、許可応答を返すとともに、Ｓ３．１にて認可コードを発行する際に紐づけるスコープを、スコープグループではなく、Ｓ１０．９にて確認した際に、スコープとユーザーの権限の確認の結果、権限あり、と判断されたスコープを用いる。つまりＳ１０．１１にて、Ｓ１０．１にて取得されるスコープがＳ１０．９で権限ありと判断されたスコープとなり、Ｓ１０．２、Ｓ１０．３、Ｓ１０．４、Ｓ１０．５、Ｓ１０．６の処理が実施されたことと同じ結果が得られる。

以降の処理は図４を用いて説明した通りであり、Ｓ１０．９にて権限ありと判断されたスコープのみがＳ３．１の認可コード発行処理における認可サーバーモジュール２１０のトークンテーブルに登録されるスコープとなる。結果、発行される認可トークンに紐づくスコープは、スコープグループではなく、Ｓ１０．９にて権限ありと判断されたスコープとなる。また、認可確認画面１３０００にて、ユーザー確認項目１３００１がチェックされていない状態で許可ボタン８００３が押下された場合はスコープグループとして権限委譲がなされる。つまり、Ｓ３．１の認可コード発行処理における認可サーバーモジュール２１０のトークンテーブルに登録されるスコープはスコープグルーとなる。結果、発行さえる認可トークンに紐づくスコープがスコープグループとなる。

以上の処理によって、ユーザーは、認可サーバーモジュール２１０に対して認可確認画を用いることによってスコープグループとして権限委譲するか、もしくは自身が権限を所持している範囲にて権限委譲するかを選択することが可能となる。結果、悪意あるシステム管理者によってスコープグループの設定を変更することで、ユーザーが意図しない権限委譲が行われたとするような行為を防ぐことが可能となる。

［その他の実施例］
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２００ 認可サーバー
３００ リソースサーバー
４００ 端末
２１０ 認可サーバーモジュール
３１０ リソースサーバーモジュール
４１０ Ｗｅｂブラウザー
４２０ クライアントアプリケーション

Claims (15)

1. Ｗｅｂサービスを提供するリソースサーバーにおける認証処理および認可処理を実行する認可サーバーであって、
   前記Ｗｅｂサービスを利用する範囲が定義されたスコープであって、少なくとも１つ以上のスコープを関連付けたスコープグループを指定する認可要求をクライアントから受信する受信手段と、
   前記クライアントを有する端末により表示された認可確認画面を介し、認証済みユーザーの前記Ｗｅｂサービスにおける権限をクライアントへ移譲するための認可操作を前記ユーザーが行ったことに応じて、前記スコープグループに関連付けられた認可情報を発行する発行手段と、
   前記クライアントが前記Ｗｅｂサービスを利用するために送信した前記認可情報の検証要求を前記リソースサーバーから受信した際、前記スコープグループと関連付く少なくとも１つ以上のスコープを取得し、前記検証要求が指定する検証対象のスコープが取得された少なくとも１つ以上のスコープに含まれており、かつ前記ユーザーが有する権限で利用できる範囲を定義しているスコープが取得された少なくとも１つ以上のスコープに含まれている場合、前記クライアントは前記検証対象のスコープで定義された範囲で前記Ｗｅｂサービスを利用する権限が移譲されている旨を前記リソースサーバーに送信する検証手段と、
   を有する認可サーバー。
2. 前記認可確認画面を前記端末へ提供する前記発行手段は、前記スコープグループを指定する認可要求が受信された場合には、前記スコープグループに関連付く少なくとも１つ以上のスコープの範囲で前記クライアントにより前記Ｗｅｂサービスが利用される旨を表示する前記認可確認画面を前記端末へ提供することを特徴とする請求項１に記載の認可サーバー。
3. 前記認可確認画面を前記端末へ提供する前記発行手段は、前記クライアントは前記ユーザーから移譲された権限で前記Ｗｅｂサービスを利用する旨を表示する前記認可確認画面を前記端末へ提供することを特徴とする請求項１または２に記載の認可サーバー。
4. 前記発行手段は、ユーザーに付与された権限に変更があった場合に前記認可操作を再び行うか否かを指定させる項目を含む設定画面を前記端末へ提供し、前記クライアントを有する端末により表示された前記設定画面を介し、前記認可操作を再び行うことが指定されたことに応じて、前記スコープグループに関連付く少なくとも１つ以上のスコープの内、前記ユーザーが有する権限で利用できる範囲を定義しているスコープのみに関連付けられた認可情報を発行することを特徴とする請求項１乃至３の何れか１項に記載の認可サーバー。
5. 前記認可確認画面を前記端末へ提供する前記発行手段は、ユーザーに付与された権限に変更があった場合に前記認可操作を再び行うか否かを指定させる項目を含む前記認可確認画面を前記端末へ提供し、前記クライアントを有する端末により表示された前記認可確認画面を介し、前記認可操作を再び行うことが指定されたことに応じて、前記スコープグループに関連付く少なくとも１つ以上のスコープの内、前記ユーザーが有する権限で利用できる範囲を定義しているスコープのみに関連付けられた認可情報を発行することを特徴とする請求項１乃至４の何れか１項に記載の認可サーバー。
6. 前記Ｗｅｂサービスは複合機もしくはプリンターに設定する設定値を配信する機能を備え、前記クライアントは前記設定値を作成し前記Ｗｅｂサービスにアップロードする機能を備えていることを特徴とする請求項１乃至５の何れか１項に記載の認可サーバー。
7. 前記スコープグループには、前記設定値に対する全ての操作が可能な管理者権限、前記設定値を編集可能な設定値編集者権限、設定値を参照することができる設定値参照者権限、および前記設定値を反映する複合機もしくはプリンターを特定するための情報を設定値に設定するデバイス設定者権限の何れか１つの権限で利用できる範囲を定義しているスコープの内、少なくとも１つ以上のスコープが関連付くことを特徴とする請求項６に記載の認可サーバー。
8. Ｗｅｂサービスを提供するリソースサーバーにおける認証処理および認可処理を実行する認可サーバーの制御方法であって、
   前記Ｗｅｂサービスを利用する範囲が定義されたスコープであって、少なくとも１つ以上のスコープを関連付けたスコープグループを指定する認可要求をクライアントから受信する受信ステップと、
   前記クライアントを有する端末により表示された認可確認画面を介し、認証済みユーザーの前記Ｗｅｂサービスにおける権限をクライアントへ移譲するための認可操作を前記ユーザーが行ったことに応じて、前記スコープグループに関連付けられた認可情報を発行する発行ステップと、
   前記クライアントが前記Ｗｅｂサービスを利用するために送信した前記認可情報の検証要求を前記リソースサーバーから受信した際、前記スコープグループと関連付く少なくとも１つ以上のスコープを取得し、前記検証要求が指定する検証対象のスコープが取得された少なくとも１つ以上のスコープに含まれており、かつ前記ユーザーが有する権限で利用できる範囲を定義しているスコープが取得された少なくとも１つ以上のスコープに含まれている場合、前記クライアントは前記検証対象のスコープで定義された範囲で前記Ｗｅｂサービスを利用する権限が移譲されている旨を前記リソースサーバーに送信する検証ステップと、
   を含む制御方法。
9. 前記認可確認画面を前記端末へ提供する前記発行ステップにおいて、前記スコープグループを指定する認可要求が受信された場合には、前記スコープグループに関連付く少なくとも１つ以上のスコープの範囲で前記クライアントにより前記Ｗｅｂサービスが利用される旨を表示する前記認可確認画面を前記端末へ提供することを特徴とする請求項８に記載の制御方法。
10. 前記認可確認画面を前記端末へ提供する前記発行ステップにおいて、前記クライアントは前記ユーザーから移譲された権限で前記Ｗｅｂサービスを利用する旨を表示する前記認可確認画面を前記端末へ提供することを特徴とする請求項８または９に記載の制御方法。
11. 前記発行ステップにおいて、ユーザーに付与された権限に変更があった場合に前記認可操作を再び行うか否かを指定させる項目を含む設定画面を前記端末へ提供し、前記クライアントを有する端末により表示された前記設定画面を介し、前記認可操作を再び行うことが指定されたことに応じて、前記スコープグループに関連付く少なくとも１つ以上のスコープの内、前記ユーザーが有する権限で利用できる範囲を定義しているスコープのみに関連付けられた認可情報を発行することを特徴とする請求項８乃至１０の何れか１項に記載の制御方法。
12. 前記認可確認画面を前記端末へ提供する前記発行ステップにおいて、ユーザーに付与された権限に変更があった場合に前記認可操作を再び行うか否かを指定させる項目を含む前記認可確認画面を前記端末へ提供し、前記クライアントを有する端末により表示された前記認可確認画面を介し、前記認可操作を再び行うことが指定されたことに応じて、前記スコープグループに関連付く少なくとも１つ以上のスコープの内、前記ユーザーが有する権限で利用できる範囲を定義しているスコープのみに関連付けられた認可情報を発行することを特徴とする請求項８乃至１１の何れか１項に記載の制御方法。
13. 前記Ｗｅｂサービスは複合機もしくはプリンターに設定する設定値を配信する機能を備え、前記クライアントは前記設定値を作成し前記Ｗｅｂサービスにアップロードする機能を備えていることを特徴とする請求項８乃至１２の何れか１項に記載の制御方法。
14. 前記スコープグループには、前記設定値に対する全ての操作が可能な管理者権限、前記設定値を編集可能な設定値編集者権限、設定値を参照することができる設定値参照者権限、および前記設定値を反映する複合機もしくはプリンターを特定するための情報を設定値に設定するデバイス設定者権限の何れか１つの権限で利用できる範囲を定義しているスコープの内、少なくとも１つ以上のスコープが関連付くことを特徴とする請求項１３に記載の制御方法。
15. Ｗｅｂサービスを提供するリソースサーバーにおける認証処理および認可処理を実行する認可サーバーを制御するプログラムであって、
    前記Ｗｅｂサービスを利用する範囲が定義されたスコープであって、少なくとも１つ以上のスコープを関連付けたスコープグループを指定する認可要求をクライアントから受信する受信ステップと、
    前記クライアントを有する端末により表示された認可確認画面を介し、認証済みユーザーの前記Ｗｅｂサービスにおける権限をクライアントへ移譲するための認可操作を前記ユーザーが行ったことに応じて、前記スコープグループに関連付けられた認可情報を発行する発行ステップと、
    前記クライアントが前記Ｗｅｂサービスを利用するために送信した前記認可情報の検証要求を前記リソースサーバーから受信した際、前記スコープグループと関連付く少なくとも１つ以上のスコープを取得し、前記検証要求が指定する検証対象のスコープが取得された少なくとも１つ以上のスコープに含まれており、かつ前記ユーザーが有する権限で利用できる範囲を定義しているスコープが取得された少なくとも１つ以上のスコープに含まれている場合、前記クライアントは前記検証対象のスコープで定義された範囲で前記Ｗｅｂサービスを利用する権限が移譲されている旨を前記リソースサーバーに送信する検証ステップと、
    を含むプログラム。

Images