(57)【要約】      （修正有）【課題】ユーザーの利便性を損なうことなく、ユーザーの権限やスコープの定義を変更可能な権限委譲システムを提供する。【解決手段】権限委譲システムが備える認可サーバーモジュールは、Ｗｅｂサービスを利用する範囲を定義する１または複数のスコープが関連付けられたスコープグループが指定された認可要求をクライアントから受信Ｓ１．９する。前記スコープグループに関連付けられた１または複数のスコープのうち少なくとも１つのスコープが、ユーザーが有する権限の範囲に含まれる場合、前記認可要求に対する認可操作を受け付けるための画面を提示Ｓ２．１する。前記画面を介して前記認可要求に対する前記ユーザーの認可操作を受け付けたことに応じて、前記クライアントに対し、前記スコープグループに関する認可情報を発行Ｓ３．１する。発行した認可情報に基づいて認可トークンの要求を受け付けたことに応じて、前記認可トークンを発行Ｓ３．７する。【選択図】図４
2018081643.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂサービスを利用する範囲を定義する１または複数のスコープが関連付けられたスコープグループが指定された認可要求をクライアントから受信する受信手段と、
前記スコープグループに関連付けられた１または複数のスコープのうち少なくとも１つのスコープが、ユーザーが有する権限の範囲に含まれる場合、前記ユーザーに対し、前記認可要求に対する認可操作を受け付けるための画面を提示する提示手段と、
前記画面を介して前記認可要求に対する前記ユーザーの認可操作を受け付けたことに応じて、前記クライアントに対し、前記スコープグループに関する認可情報を発行する第１の発行手段と、
前記第１の発行手段にて発行した認可情報に基づいて認可トークンの要求を受け付けたことに応じて、前記スコープグループに対する認可トークンを発行する第２の発行手段と、
を有することを特徴とする認可サーバー。
【請求項２】
前記第１の発行手段は、ユーザーの認可操作を受け付ける際に、前記クライアントが前記スコープグループに関連付けられた１または複数のスコープの範囲にて前記Ｗｅｂサービスの利用が可能となる旨を前記ユーザーに提示することを特徴とする請求項１に記載の認可サーバー。
【請求項３】
前記第２の発行手段は、前記認可トークンの要求を受け付けた際に、前記認可情報に関連付けられた１または複数のスコープのうち少なくとも１つのスコープが、前記ユーザーが有する権限の範囲に含まれる場合、前記認可トークンを発行することを特徴とする請求項１または２に記載の認可サーバー。
【請求項４】
前記第２の発行手段は、前記スコープグループに対する認可トークンを発行する際に、併せて当該認可トークを再発行するためのリフレッシュトークンを発行し、
前記第２の発行手段は、前記リフレッシュトークンを用いて、前記認可トークンの再発行要求を受け付けた場合、当該再発行要求を受け付けた時点における前記スコープグループに関連付けられた１または複数のスコープに基づいて、前記認可トークンを再発行することを特徴とする請求項１乃至３のいずれか一項に記載の認可サーバー。
【請求項５】
前記第２の発行手段は、前記認可トークンを再発行した際に、併せて新たなリフレッシュトークンを発行することを特徴とする請求項４に記載の認可サーバー。
【請求項６】
前記第２の発行手段は、前記認可トークンを発行する際に、署名情報を付与することを特徴とする請求項１乃至５のいずれか一項に記載の認可サーバー。
【請求項７】
前記認可トークンは、ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎが用いられ、
前記署名情報は、ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅが用いられることを特徴とする請求項６に記載の認可サーバー。
【請求項８】
請求項１乃至７のいずれか一項に記載の認可サーバーと、Ｗｅｂサービスを提供するリソースサーバーとを含む権限委譲システムであって、
前記リソースサーバーは、
前記認可トークンを用いて前記Ｗｅｂサービスの利用要求を受け付ける受け付け手段と、
前記認可トークンの検証を行う認可トークン検証手段と、
前記認可トークン検証手段による検証結果に基づき、前記Ｗｅｂサービスを提供する提供手段と
を有することを特徴とする権限委譲システム。
【請求項９】
前記認可トークン検証手段は、前記認可トークンが示す許可されたスコープが、前記利用要求において要求されたＷｅｂサービスの提供を許可する範囲を示すか否かを検証することを特徴とする請求項８に記載の権限委譲システム。
【請求項１０】
前記リソースサーバーは更に、前記認可トークンの検証を、前記認可サーバーに対して要求するか、自身の前記認可トークン検証手段にて検証を行うかを判定する判定手段を備えることを特徴とする請求項８または９に記載の権限委譲システム。
【請求項１１】
Ｗｅｂサービスを利用する範囲を定義する１または複数のスコープが関連付けられたスコープグループが指定された認可要求をクライアントから受信する受信工程と、
前記スコープグループに関連付けられた１または複数のスコープのうち少なくとも１つのスコープが、ユーザーが有する権限の範囲に含まれる場合、前記ユーザーに対し、前記認可要求に対する認可操作を受け付けるための画面を提示する提示工程と、
前記画面を介して前記認可要求に対する前記ユーザーの認可操作を受け付けたことに応じて、前記クライアントに対し、前記スコープグループに関する認可情報を発行する第１の発行工程と、
前記第１の発行工程にて発行した認可情報に基づいて認可トークンの要求を受け付けたことに応じて、前記スコープグループに対する認可トークンを発行する第２の発行工程と、
を有することを特徴とする認可サーバーの制御方法。
【請求項１２】
コンピューターを、
Ｗｅｂサービスを利用する範囲を定義する１または複数のスコープが関連付けられたスコープグループが指定された認可要求をクライアントから受信する受信手段、
前記スコープグループに関連付けられた１または複数のスコープのうち少なくとも１つのスコープが、ユーザーが有する権限の範囲に含まれる場合、前記ユーザーに対し、前記認可要求に対する認可操作を受け付けるための画面を提示する提示手段、
前記画面を介して前記認可要求に対する前記ユーザーの認可操作を受け付けたことに応じて、前記クライアントに対し、前記スコープグループに関する認可情報を発行する第１の発行手段、
前記第１の発行手段にて発行した認可情報に基づいて認可トークンの要求を受け付けたことに応じて、前記スコープグループに対する認可トークンを発行する第２の発行手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認可サーバーおよびその制御方法、プログラム、並びに権限委譲システムに関する。
【背景技術】
【０００２】
近年、インターネット上に展開された所謂クラウドサービスの利用が拡大している。クラウドサービスは個々にＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を公開しており、他のアプリケーションやクラウドサービスからＡＰＩを介してサービスが提供する機能を利用する事が可能である。ＷｅｂサービスＡＰＩではＯＡｕｔｈ２．０と呼ばれる、認可の連携を実現させるための標準プロトコルの採用が進んでいる。特許文献１ではＯＡｕｔｈ２．０を利用したＷｅｂサービスＡＰＩの利用方法の技術が開示されている。
【０００３】
ＯＡｕｔｈ２．０によれば、例えばあるサービスＡが管理するユーザーのデータを取得するＡＰＩに対して、そのユーザーから認められた範囲にてサービスＢがアクセスすることができる。このとき、サービスＡは、サービスＢからアクセスされる範囲を明らかにした上で、サービスＢによるＡＰＩへのアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを「認可操作」と称する。また、このアクセスされる範囲をＯＡｕｔｈ２．０では「スコープ」と称し、スコープによりデータへのアクセス可否が決定される。
【０００４】
ユーザーが認可操作を行うと、サービスＢは、サービスＡにおけるユーザーが許可した範囲のデータへのアクセスが認められたことを証明するトークン（以下、「認可トークン」と称する）を受け取る。サービスＢは、以降のサービスＡのＡＰＩへのアクセスはその認可トークンを用いて実現できる。このユーザーの認可操作によりサービスＢがユーザーのリソースに対しアクセスすることを認可したことを「権限委譲」と称する。なお、ＯＡｕｔｈ２．０では、ユーザーの認可操作を元に認可トークンを発行するサーバーを「認可サーバー」と呼称する。また、ＡＰＩを公開するサーバーを「リソースサーバー」、ＡＰＩをコールする主体を「クライアント」と呼称する。
【０００５】
ＯＡｕｔｈ２．０では、認可サーバーとリソースサーバーは同一サーバーで構成する事も可能としているが、リソースサーバーが複数種存在する様な大規模なシステムでは通常認可サーバーを独立したサーバーとして構成する。その場合、サービスＡはサービスＢからのＡＰＩ利用のたびに取得した認可トークンの検証を認可サーバーに依頼する。そして、その検証結果を元にＡＰＩの利用の可否を決定する。ここで、大規模システムでは認可サーバーに負荷が集中してしまうという課題が発生する。この問題に対し、サービスＡが認可サーバーに検証依頼することなく自身で認可トークンを検証する手段として署名付き認可トークンの利用が検討されている。サービスＡは受信した署名付き認可トークンの署名を検証する事で認可サーバーに確認することなく認可トークンが有効であるかを判断できる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１５−０９５０５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
権限委譲を可能とするプロトコルには、サービスにおけるリソースの変更、およびユーザーの権限の変更に対応する柔軟性が欠如している可能性がある。例えば、ＯＡｕｔｈ２．０の認可トークンは、ユーザーが認可操作する際に確認したスコープのみが権限委譲されているとする。ここで、ユーザーが権限委譲可能なスコープの変化や、ＡＰＩを利用するためのスコープの増減、変更があった場合に、当該ＡＰＩを利用するためには、ユーザーに再度、認可操作を強いる可能性があり、利便性が損なわれる可能性がある。
【０００８】
本発明は上記課題を鑑みてなされたものであり、ユーザーの利便性を損なうことなく、ユーザーの権限やスコープの定義を変更可能な権限委譲システムを提供する。
【課題を解決するための手段】
【０００９】
上記課題を解決するために本願発明は以下の構成を有する。すなわち、認可サーバーであって、Ｗｅｂサービスを利用する範囲を定義する１または複数のスコープが関連付けられたスコープグループが指定された認可要求をクライアントから受信する受信手段と、前記スコープグループに関連付けられた１または複数のスコープのうち少なくとも１つのスコープが、ユーザーが有する権限の範囲に含まれる場合、前記ユーザーに対し、前記認可要求に対する認可操作を受け付けるための画面を提示する提示手段と、前記画面を介して前記認可要求に対する前記ユーザーの認可操作を受け付けたことに応じて、前記クライアントに対し、前記スコープグループに関する認可情報を発行する第１の発行手段と、前記第１の発行手段にて発行した認可情報に基づいて認可トークンの要求を受け付けたことに応じて、前記スコープグループに対する認可トークンを発行する第２の発行手段と、を有する。
【発明の効果】
【００１０】
本発明によれば、スコープグループの範囲内のユーザーの権限の変更があった場合に、ユーザーに再度、認可操作を強いることなくＡＰＩ利用を継続することができる。
【図面の簡単な説明】
【００１１】
【図１】本願発明に係る権限委譲システムの構成例を示す図。
【図２】本願発明に係るハードウェア構成の例を示す図。
【図３】本願発明に係るソフトウェア構成の例を示す図。
【図４】ＯＡｕｔｈ２．０のシーケンスの例を示す図。
【図５】本願発明に係るログイン画面の構成例を示す図。
【図６】本願発明に係る各種テーブルの構成例を示す図。
【図７】本願発明に係る各種テーブルの構成例を示す図。
【図８】ＯＡｕｔｈ２．０のリフレッシュシーケンスの例を示す図。
【図９】本願発明に係るスコープ検証処理のフローチャート。
【図１０】本願発明に係る認可確認画面の構成例を示す図。
【図１１】署名付き認可トークンの例を示す図。
【図１２】本願発明に係る認可トークン検証処理のフローチャート。
【図１３】本願発明に係る権限検証処理のフローチャート。
【図１４】本願発明に係る権限、スコープ変更の時系列を示した図。
【発明を実施するための形態】
【００１２】
上述したように、端末からアクセスされるリソースの範囲、即ちサービスを利用する範囲が定義されたスコープ、およびユーザーの権限は変化するため、ＯＡｕｔｈ２．０を始めとする権限委譲プロトコルには柔軟性が求められる。始めに、スコープおよびユーザーの権限の変化について説明する。エンタープライズの分野では、ユーザーが所有する権限はユーザーの立場によって異なることがある。例えば、会社の特定の機密を含む情報にアクセスできる立場と、そうでない立場によってユーザーが所有する権限に差異があり、ＯＡｕｔｈ２．０におけるスコープとユーザーが所有する権限には密接な関係がある。つまり、サービスにおけるリソースの範囲を意味するスコープに対しアクセスを可能とする権限、という定義を行い、その権限を特定のユーザーに付与する運用が想定される。なお、ユーザーの立場は当人の社内での役割の変化や業務の変更により変更されるものであるため、ユーザーの権限は何かしらの要因によって適時変更される。つまり、ある時点でのユーザーの権限と、その後の時点でのユーザーの権限は変化しており、ユーザーがサービスに権限委譲することができるスコープの範囲も変化する。
【００１３】
一方、クラウドサービスにおいては、継続的インテグレーション（ｃｏｎｔｉｎｕｏｕｓ  ｉｎｔｅｇｒａｔｉｏｎ）、継続的デリバリー、継続的デプロイメントと言われる短期間での新機能リリースを実施する手法やアーキテクチャが注目されている。そして、この短期間で新機能をリリースしていくことは、各種ツールや開発プロセス、設計手法が提供されることによって、さらに拡大していくことが予想される。この短期間でリリースしていくことは、ＷｅｂサービスのＡＰＩの増加や、当該ＡＰＩが取り扱うデータの範囲の拡大、もしくは範囲の変更が短期間で行われることを意味する。
【００１４】
つまり、ユーザーの権限の変更を要因としたユーザーによる権限委譲が可能なスコープの変化、短サイクルリリースによるスコープの増減、およびスコープ定義の変更が行われることが想定される。こう言ったケースが発生し、かつ権限委譲が行われ認可トークンが発行されている場合、再度ユーザーに認可操作を行わせることでユーザーの権限の変化および／またはスコープの変化に対応した認可トークンを発行する必要がある。
【００１５】
そこで、本願発明は、この認可操作の手間を省き、利便性を高めつつ、ユーザーの権限の変化および／またはスコープの変化に対応した認可トークンの運用を可能にすることを目的としている。本願発明において、認可トークンとして署名付き認可トークンを用いる。また、その手法としてＪＷＴ（ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ）、ＪＷＳ（ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ）を利用する。
【００１６】
以下に説明する実施形態において、サービスとは、サーバー上で起動するソフトウェアがクライアントからの要求に従い実行されることでそのクライアントに対して提供される機能のことを指す。なお、そのソフトウェアであるＷｅｂアプリケーションのこともサービスと呼ぶ場合もある。本実施形態においては、クラウドサービスとしてリソースサーバーが提供するサービスがあり、ユーザーは、端末を介してリソースサーバーが提供するサービスを利用している想定で説明する。また、クライアントは、端末上で起動するソフトウェアである。クライアントは、端末が備えるＷｅｂブラウザーを介してアクセスすることが可能なように構成、もしくは、Ｗｅｂブラウザーの機能を備えたソフトウェアを起動／制御することが可能なように構成されている。また、リソースサーバーは、ＷｅｂサービスとしてＡＰＩを公開しており、クライアントはこのＡＰＩを利用する事でユーザーに対してサービスを提供している想定で説明する。
【００１７】
なお、上記の前提に限定するものでは無く、クライアントはリソースサーバーと連携する別のサービスとして構成されてもよい。また、リソースサーバーおよび端末は、各々単数で構成される事を限定しているわけではない。例えば、複数台から構成されたサーバー群がサービスを提供していてもよい。よって、本願発明でサーバーと称した場合、１台または複数台から構成されるサーバー群であることも含まれる。
【００１８】
クライアントがリソースサーバーのＡＰＩを利用するためには、後述するＯＡｕｔｈ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅ  Ｇｒａｎｔによるユーザーの認可操作を伴った権限委譲が必要となる。換言すると、ユーザーから権限委譲を受けたクライアントは、リソースサーバーのＡＰＩの利用が可能になる。
【００１９】
次に、本願発明の実施形態にて用いられるリソースサーバーが提供するサービスの例を説明する。リソースサーバーは、不図示の複合機もしくはプリンター（以下、デバイス）からのリクエストに応じて、各デバイスに配信する各種データを配信する機能を備える。つまり、リソースサーバーは、デバイスの設定値を配信するサービスを提供する。ここで、各種データとは、デバイスがどのような動作をするかを決定するための設定値、デバイスにインストールするファームウェアやアプリケーションの情報、および、デバイスに設定することができるオプション機能が挙げられる。また、各種データをどのような順序で設定すべきかといった制御情報や、アプリケーションをインストールするためのライセンス情報、等も含むことができる。本実施形態においては、これらの設定値、設定値の制御情報、およびライセンスをリソースとして定義している。
【００２０】
また、本実施形態では、クライアントアプリケーションの機能の例として以下を備えるものとして説明する。クライアントアプリケーションは、デバイスに配信する各種データを作成し、個々のデバイス用のデータとしてリソースサーバーにアップロードする機能を備える。
【００２１】
以下、本発明の一実施形態について図面を用いて説明する。
【００２２】
［システム構成］
本実施形態に係る権限委譲システムは、図１に示すような構成のネットワーク上に実現される。ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）１００は、外部ネットワークであり、本発明ではＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）システムが構築されている。ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）１０１は、内部ネットワークであり、複数のＬＡＮ１０１がＷＡＮ１００を介して接続されている。図１の構成例では、認可サーバー２００とリソースサーバー３００とが同じＬＡＮ１０１内に位置し、ＷＡＮ１００を介して、端末４００が位置するＬＡＮ１０１と接続されている。
【００２３】
認可サーバー２００は、ＯＡｕｔｈ２．０を実現するためのサーバーであり、認可サーバーモジュールが設置される。リソースサーバー３００は、Ｗｅｂサービスとして公開されるＡＰＩを備えるリソースサーバーモジュールが設置される。端末４００は、Ｗｅｂブラウザー４１０、およびクライアントアプリケーション４２０を備える。端末４００は、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）やスマートフォンと呼ばれる携帯端末等が該当する。クライアントアプリケーション４２０は、リソースサーバー３００が備えるリソースサーバーモジュールが公開するＡＰＩを利用する事で、自身が提供する機能と合わせたサービスをユーザーに提供する。端末４００は、Ｗｅｂブラウザー４１０を用いて認可サーバー２００と通信する。
【００２４】
認可サーバー２００、およびリソースサーバー３００は、ＬＡＮ１０１を介して接続されている。なお、認可サーバー２００とリソースサーバー３００はＬＡＮ１０１でなく、ＷＡＮ１００を介して接続する構成であってもよい。また、認可サーバー２００、リソースサーバー３００、および端末４００はそれぞれ、ＷＡＮ１００を介して通信可能に接続されている。また、認可サーバー２００はデータベースサーバー（不図示）とＬＡＮ１０１を介して接続しており、認可サーバーモジュールが利用するデータを格納するよう構成されてもよい。さらには、リソースサーバー３００、認可サーバー２００は物理的に、同一のサーバー上に構成されていてもよい。
【００２５】
本実施形態に係る権限委譲システムの構成要素は、例えば、図２に示すような構成の情報処理装置にて実現される。図２は、認可サーバー２００、リソースサーバー３００、および端末４００のハードウェア構成の例を示す。なお、本実施形態の各サーバーおよび端末には、図２の構成に限定するものではない。例えば、一般的な情報処理装置のハードウェア構成やＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）として提供される情報処理装置の仮想的なハードウェア構成を適用できる。
【００２６】
ＣＰＵ２００１は、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）やアプリケーション等のプログラムを実行し、システムバス２００４に接続される各ブロックを制御する。各種プログラムは、ＲＯＭ２００３のプログラム用ＲＯＭや、ハードディスク（ＨＤ）等の外部メモリ２０１１に記憶されており、ＲＡＭ２００２にロードされて実行される。後述する各シーケンスの処理は、各種プログラムの実行により実現される。
【００２７】
ＲＡＭ２００２は、ＣＰＵ２００１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２００５は、キーボード２００９やポインティングデバイス（不図示）からのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２００６は、ＣＲＴディスプレイ２０１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２００７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２０１１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２００８は、ＷＡＮ１００、ＬＡＮ１０１を介して接続された他の機器との通信制御処理を実行する。なお、ＩａａＳとして提供される仮想的な情報処理装置の場合においては、ＫＢＣ２００５、ＣＲＴＣ２００６等を備えず、ＮＣ２００８を介して接続される端末に備えるキーボード２００９や、ＣＲＴディスプレイ２０１０から操作されるよう構成される。
【００２８】
尚、後述の全ての説明においては、特に断りのない限りサーバーや端末における実行のハードウェア上の主体はＣＰＵ２００１であり、ソフトウェア上の主体は外部メモリ２０１１にインストールされたアプリケーションプログラムである。
【００２９】
図３は、本実施形態に係る、認可サーバー２００、リソースサーバー３００それぞれのモジュール構成の例を示す図である。各モジュールを実行されることでサービスを提供する。なお、ここでは、本実施形態に係るモジュールのみを示し、他のモジュールについては省略する。権限委譲システム内の各装置が有するソフトウェアモジュールは、各装置のＣＰＵ２００１がＲＡＭ２００２にロードされたプログラムを実行することで実現される。
【００３０】
図３（ａ）に示すように、認可サーバー２００は、認可サーバーモジュール２１０、およびＨＴＴＰサーバーモジュール２２０を備える。ＨＴＴＰサーバーモジュール２２０は、ＷＡＮ１００を介して接続する端末４００に設置されたＷｅｂブラウザー４１０、およびクライアントアプリケーション４２０とのＨＴＴＰ通信を行うためのモジュールである。また、ＨＴＴＰサーバーモジュール２２０は、ＳＳＬ／ＴＬＳによる通信が可能に構成されており、証明書ストア（不図示）を備える。また、本実施形態では、後述する認可要求を受け付けた場合に、要求元に対して認証情報（ユーザーＩＤ、パスワード）によるユーザー認証を要求するよう構成している。
【００３１】
認可サーバーモジュール２１０は、ＨＴＴＰサーバーモジュール２２０上で、もしくは、これと連携して動作するＷｅｂアプリケーションである。認可サーバーモジュール２１０は、ＨＴＴＰサーバーモジュール２２０を介してＷｅｂブラウザー４１０からの要求を受け付け、その要求に対応して処理を実行し、応答する。本実施形態では、ＨＴＴＰサーバーモジュール２２０にてユーザー認証を受け付ける。そして、要求元の認証に成功した場合、認可サーバーモジュール２１０は、認証したユーザー情報を関連づけた認証トークンを生成し、認可サーバーモジュール２１０に認証トークンを通知するよう構成されている。認証トークンとは、ユーザーが認証されそのユーザーがログインしている事を示す、もしくは、ユーザーが認証されているかを検証するためのトークンである。認証トークンを利用する事でユーザーを識別する事が可能となる。後述の認可コードは、認証されたユーザーの認可操作により権限委譲されたクライアントが、そのユーザーの権限を用いてユーザーに成り代わりアクセスすることを許可した事を示すための情報である。従って、認証トークンと認可コードの両者は、用途が異なるものである。特に、認証トークンの場合はユーザーの確認を目的としているが、認可コードは権限の確認を目的としている。
【００３２】
また、認可トークンは、クライアントが認可コードを用いて取得し、クライアントがＡＰＩを利用するための権限を持つことを示すトークンである。認可サーバーモジュール２１０は、認可トークンを署名するための秘密鍵を保持している。この秘密鍵を用いて認可トークンを署名し、署名付き認可トークンとして発行する事ができる。さらには、リフレッシュトークンは、同じく認可コードを用いて取得し認可トークンを再発行することが可能であることを示すトークンである。ＨＴＴＰサーバーモジュール２２０、および認可サーバーモジュール２１０における処理の詳細は後述する。
【００３３】
認可サーバーモジュール２１０は、ＬＡＮ１０１を介してリソースサーバーモジュール３１０からの認可トークンの権限検証処理要求を受け付ける。そして、認可サーバーモジュール２１０は、その要求に応じて、処理し、クライアントによるリソースサーバー３００へのアクセス可否に関する応答を行うよう構成されている。この認可トークンの権限検証処理は、ＲＰＣ（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）として構成してもよいし、ＨＴＴＰサーバーモジュール２２０を介してＬＡＮ１０１やＷＡＮ１００を介して通信可能なＷｅｂサービスのＡＰＩとして構成してもよい。
【００３４】
図３（ｂ）に示すように、リソースサーバー３００は、リソースサーバーモジュール３１０を備える。リソースサーバーモジュール３１０は、ＨＴＴＰサーバーモジュール（不図示）上で動作するよう構成してもよい。リソースサーバーモジュール３１０はＷｅｂサービスとして公開するＡＰＩを備えており、より具体的な例としては前述のとおりである。リソースサーバーモジュール３１０は、クライアントアプリケーション４２０からのリソース要求（利用要求）を受け付け、その要求に応じて処理し、応答する。
【００３５】
また、リソースサーバーモジュール３１０は、認可サーバーモジュール２１０にて発行した署名付き認可トークンの署名を検証する際に用いられる公開鍵を保持している。もしくは、リソースサーバーモジュール３１０は、認可サーバーモジュール２１０が署名を検証する際に用いられる公開鍵を取得するためのＡＰＩを公開し、リソースサーバーモジュール３１０がそのＡＰＩを介して公開鍵を取得するよう構成してもよい。リソースサーバーモジュール３１０は、受信した認可トークンが署名付き認可トークンであった場合、この公開鍵を利用して署名を検証する事で認可トークンの正当性を確認する。また、リソースサーバーモジュール３１０は、場合によっては、認可サーバーモジュール２１０に対して後述の認可トークンの権限検証処理を要求する事もできる。
【００３６】
［処理シーケンス］
次に、図４〜図７を用いて、クライアントアプリケーション４２０が、リソースサーバーモジュール３１０が公開するＡＰＩを利用するまでの本実施形態のシーケンスを説明する。なお、シーケンス図において、“Ｒｅｆ”は参照を示しており、別の図でその詳細を説明する。また、“Ａｌｔ”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。また、“Ｏｐｔ”は前の処理の結果が条件を満たした場合のみ実行される処理を示す。
【００３７】
まず、本実施形態に係る、認可サーバーモジュール２１０のユーザーテーブルおよびクライアントテーブルのデータ例をそれぞれ図６（ａ）、（ｂ）に示す。
【００３８】
本実施形態では、図６（ａ）に示すように、ユーザーテーブルには、ユーザーとして「ａｄｍｉｎ＠ｘｘ．ｃｏｍ」、「ｕｓｅｒ＠ｘｘ．ｃｏｍ」が登録されており、それぞれ、記載の権限が設定されている。
【００３９】
本実施形態では、図６（ｂ）に示すように、クライアントテーブルには、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」というクライアントが登録されている。各パラメーターの利用方法については後述する。
【００４０】
また、本実施形態に係る、認可サーバーモジュール２１０のスコープ定義テーブルのデータ例を図６（ｃ）に示す。
【００４１】
本実施形態では、ユーザーの権限として、管理者権限、設定値編集者権限、設定値参照者権限、およびデバイス設定者権限の４つの権限を定義する。管理者権限は、上述の設定値に対する全ての操作が可能な権限とする。設定値編集者権限は、設定値を編集可能な権限とする。設定値参照者権限は、設定値を参照することができる権限とする。デバイス設定者権限は、設定値を反映する複合機やプリンターなどのデバイスを特定するための情報を設定値に設定する権限とする。通常、権限とスコープは対応付けて定義し、スコープによりデータへのアクセス範囲が決定される。スコープは、リソースサーバーモジュール３１０が提供するサービスを利用する範囲を定義しており、これによりデータへのアクセス可否が決定される。
【００４２】
例えば、設定値参照者の権限に対応する「ｒｅａｄ」というスコープが定義されていた場合、クライアントアプリケーション４２０は、「ｒｅａｄ」スコープを用いて権限委譲プロトコルを実施し、「ｒｅａｄ」スコープに対応する認可トークンを取得できる。そして、この認可トークンを用いることで、リソースサーバーモジュール３１０の各種設定値を参照するためのＡＰＩを利用することが可能となる。しかしながら、この認可トークンでは設定値を編集するＡＰＩを利用することはできない。クライアントアプリケーション４２０が設定値を編集するためには、設定値編集者の権限に対応する「ｅｄｉｔ」というスコープを指定して認可トークンを取得する必要がある。このとき、権限委譲プロトコルを実施する際に、クライアントアプリケーション４２０に「ｒｅａｄ」、「ｅｄｉｔ」の両方のスコープを指定することが考えられる。しかしながら、ユーザー自身に設定値編集者の権限が付与されていない場合、認可確認の処理でエラーとなり、認可トークンを取得することができない。
【００４３】
そこで本実施形態では、複数のスコープをグルーピングし、そのグループ内のスコープに対応する権限のうち少なくとも一つの権限を所持している場合は、認可確認処理にて認可トークンの発行を許可するスコープグループという定義を追加する。より具体的には、例えば、図６（ｃ）の１行目に示すように、「ａｄｍｉｎ」、「ｅｄｉｔ」、「ｒｅａｄ」、「ｄｅｖｉｃｅ」というスコープをまとめた「ｇｒｏｕｐ」というスコープグループを定義する。「ｇｒｏｕｐ」は、図６（ｃ）で示された全てのスコープと関連付いているため、グループ権限が与えられたユーザーは現時点におけるリソースサーバーモジュール３１０が提供する全ての機能を使用できる。そして、「ｇｒｏｕｐ」スコープを指定して権限委譲プロトコルを実施することで、設定値参照者権限しか所持していないユーザーであっても認可トークンを取得することができるようになる。
【００４４】
ただし、ユーザーは設定値編集権限を所持しないため、「ｇｒｏｕｐ」を指定して取得した認可トークンであっても、リソースサーバーモジュール３１０の設定値を編集するＡＰＩが利用できてはならない。そこで、認可サーバーモジュール２１０は、認可トークンに対して、ユーザーが現在所持している権限の範囲のスコープのみを記載し署名する。さらに、認可サーバーモジュール２１０は、認可トークンのリフレッシュを受けるたびに、その時点でユーザーが所持している権限の範囲のスコープを記載し署名する。このスコープグループの処理により、ユーザーは自身の権限に変更が行われたとしても、「ｇｒｏｕｐ」を指定して取得した認可トークンであれば、リフレッシュを伴う事でユーザーの権限に即したＡＰＩ利用が可能となる。
【００４５】
また、リソースサーバーモジュール３１０にて、例えば、設定値の制御順序を変更するためのスコープ「ｏｒｄｅｒ」が必要なＡＰＩを新規追加し、認可サーバーモジュール２１０にてスコープ定義「ｏｒｄｅｒ」を追加した場合を考える。このとき、通常は、「ｏｒｄｅｒ」スコープを指定して、権限委譲プロトコルを再度実施する必要がある。これに対し、「ｏｒｄｅｒ」スコープをスコープグループ「ｇｒｏｕｐ」に関連付けて定義する。この構成により、ユーザーに権限が付与されている限り、「ｇｒｏｕｐ」を指定して取得した認可トークンをリフレッシュする事で設定値の制御順序を変更するためのＡＰＩを利用するためのトークンとして利用できる。
【００４６】
なお、認可サーバーモジュール２１０は、要求を受信したことに応じて、スコープ定義テーブルに新たなスコープを定義する。ここでの要求は、リソースサーバー３００に追加された新しい機能を呼び出すＡＰＩの実装に伴い、そのＡＰＩに対応する新たなスコープを定義するために送信される。その際に、「ｇｒｏｕｐ」に対して新たなスコープを関連付けることもできるが、場合によっては、「ｇｒｏｕｐ」に新たなスコープを関連付けないことも可能である。新たなスコープを定義する要求は、端末４００と同じ構成を有するコンピューター（不図示）から送信できる。以下、これら処理の詳細について説明する。
【００４７】
本実施形態のシーケンスで説明するユーザーは、図６（ａ）に示すように、ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」および、そのパスワードを利用するとして説明する。
【００４８】
また、本シーケンスで説明するクライアントアプリケーション４２０は、図６（ｂ）に示すように、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」の各種データである、シークレット、およびリダイレクトＵＲＩを保持している。リダイレクトＵＲＩは、クライアントアプリケーション４２０が、認可応答を受け付けるためのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）である。これらデータは、認可サーバーモジュール２１０に予め登録されている必要があるが、登録手段については不図示の画面を用いた方法や、認可サーバーモジュール２１０が公開するＡＰＩによって実施する手段が考えられる。それら手段の結果、図６（ｂ）に示した通り、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」というクライアントが登録される。
【００４９】
Ｓ１．１にて、ユーザーは、Ｗｅｂブラウザー４１０に表示されている連携開始操作（不図示）を実行する。ここでの連携開始操作は、例えば、クライアントアプリケーション４２０にて提供される各種操作画面（不図示）を介して行われる。
【００５０】
Ｓ１．２にて、Ｗｅｂブラウザー４１０は、クライアントアプリケーション４２０に連携開始が通知される。なお、Ｓ１．１、Ｓ１．２の処理については、ユーザーがクライアントアプリケーション４２０から操作し、クライアントアプリケーション４２０がＷｅｂブラウザー４１０を呼び出すよう構成してもよい。
【００５１】
Ｓ１．３にて、連携開始を受けたクライアントアプリケーション４２０は、Ｗｅｂブラウザー４１０、ＨＴＴＰサーバーモジュール２２０を介して認可サーバーモジュール２１０に対して認可要求を行う。本実施形態では、権限委譲プロトコルとしてＯＡｕｔｈ２．０に定義されているＡｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅ  Ｇｒａｎｔフローをベースに本願発明の構成を説明する。なお、認可要求には、少なくとも、前述のクライアントアプリケーション４２０が保持しているクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」およびリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」を含む。つまり、認可要求には、クライアントアプリケーション４２０が、ユーザーから権限委譲されるリソースの範囲を示すスコープを含む。ここでは、スコープ「ｒｅａｄ」を指定した場合と、スコープグループ「ｇｒｏｕｐ」を指定した場合とについてそれぞれ説明する。なお、リダイレクトＵＲＩは、認可サーバー２００にて発行された認可コードを受け付けるクライアントアプリケーション４２０のＵＲＬである。
【００５２】
Ｓ１．４にて、Ｗｅｂブラウザー４１０から認可要求を受け付けたＨＴＴＰサーバーモジュール２２０は、Ｗｅｂブラウザー４１０からの通知に、ＨＴＴＰ  Ｃｏｏｋｉｅとして有効な認証トークンが含まれているか否かを検証する。含まれている場合、ＨＴＴＰサーバーモジュール２２０は、認証トークンを認可サーバーモジュール２１０に通知し、Ｓ１．９に移行する。含まれていない場合は、Ｓ１．５〜Ｓ１．８の処理を実行する。
【００５３】
Ｓ１．５にて、ＨＴＴＰサーバーモジュール２２０は、ユーザー認証をするためにログイン画面５００をＷｅｂブラウザー４１０に応答する。図５は、ＨＴＴＰサーバーモジュール２２０が応答するログイン画面５００の構成例を示す。本実施形態では、ユーザーは、ユーザーＩＤおよびパスワードを入力し、それらの組が認可サーバーモジュール２１０のユーザーテーブルに登録されている情報の組と一致する場合に、認証するよう構成されている。なお、ユーザーを認証する手段として他の手段、例えば、Ｘ．５０９の証明書や、パスワードを複数回入力する多段階認証等、別の手段を構成してもよく、特に限定するものではない。
【００５４】
図５に示すログイン画面５００は、ユーザーＩＤを入力するユーザーＩＤ入力欄５０１、パスワードを入力するパスワード入力欄５０２、およびログイン操作を実行するためのログインボタン５０３を含んで構成される。
【００５５】
Ｓ１．６にて、ユーザーは、Ｗｅｂブラウザー４１０に表示されたログイン画面５００に必要な情報を入力し、ログインボタン５０３を押下する。ここでは、ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」、および、パスワード「ｕｓｅｒ」が入力されるものとして説明する。
【００５６】
Ｓ１．７にて、Ｗｅｂブラウザー４１０は、ログイン要求として、入力された情報（ユーザＩＤおよびパスワード）をＨＴＴＰサーバーモジュール２２０に送信する。
【００５７】
Ｓ１．８にて、ＨＴＴＰサーバーモジュール２２０は、ユーザーＩＤおよびパスワードを取得し、ユーザーテーブル（図６（ａ））のユーザーＩＤおよびパスワードの情報の組と比較し、一致するか否かを検証する事でユーザーを認証する。なお、ＨＴＴＰサーバーモジュール２２０は、ユーザー認証に失敗、つまり、ユーザーテーブルに入力された情報が登録されていない場合は、認証エラー画面（不図示）をＷｅｂブラウザー４１０に応答する。ここで、認証エラー画面と共に、ログイン画面５００を再度表示させてもよい。ユーザー認証に成功した場合、ＨＴＴＰサーバーモジュール２２０は認証トークンを生成する。この認証トークンは、認可サーバー２００の不揮発メモリ上に、ユーザーＩＤに対応するＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）と対応付けて保存される。ＵＵＩＤは、重複しないユニークなＩＤ（識別情報）である。ここでは、ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」に対応するＵＵＩＤ「１００００００１」に対応付けて保存される。
【００５８】
Ｓ１．９にて、ＨＴＴＰサーバーモジュール２２０は、認可サーバーモジュール２１０に対し、生成した認証トークンを通知し、更に認可要求を行う。なお、この認証トークンはＨＴＴＰ  Ｃｏｏｋｉｅとして設定され、ＨＴＴＰサーバーモジュール２２０からＷｅｂブラウザー４１０への応答に設定され通知される。以後、Ｗｅｂブラウザー４１０から認可サーバーモジュール２１０へのアクセスの際、上記のＨＴＴＰサーバーモジュール２２０による認証トークンの検証、認証処理、および認証トークンの通知が実行されるとして説明を省略する。
【００５９】
Ｓ１．１０にて、認証トークンを含む認可要求を受け付けた認可サーバーモジュール２１０は、受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＩの組が正しいか検証する。具体的には、認可サーバーモジュール２１０は、受信した認可要求の情報が、クライアントテーブル（図６（ｂ））に登録されているクライアントＩＤとリダイレクトＵＲＩの組に一致するか検証する。不一致の場合、認可サーバーモジュール２１０はエラー画面（不図示）を、ＨＴＴＰサーバーモジュール２２０を介してＷｅｂブラウザー４１０に応答する。一致した場合、認可サーバーモジュール２１０は、Ｓ２．１にてスコープ検証処理を実施する。スコープ検証処理の詳細については図９を用いて後述する。
【００６０】
認可サーバーモジュール２１０は、スコープ検証処理（Ｓ２．１）の結果、権限あり応答であった場合、Ｓ１．１１にて、認可確認処理を実施する。認可サーバーモジュール２１０は、認可確認処理として、認可確認画面をＷｅｂブラウザー４１０に応答する。
【００６１】
図１０（ａ）は、スコープグループではないスコープが指定された場合に、認可サーバーモジュール２１０により応答される認可確認画面１０００の構成例である。また、図１０（ｂ）は、スコープグループが指定された場合に、認可サーバーモジュール２１０により応答される認可確認画面１１００の構成例である。これら画面の共通の部分に関しては、同一の番号を付与している。認可確認画面１０００、１１００は、認可要求に含まれるクライアントＩＤをキーとしてクライアントテーブルから取得したクライアント名を表示する領域であるアクセス元表示領域１００１を備える。さらに、認可確認画面１０００、１００１は、認可要求で取得したスコープに対応する説明を表示する領域である委譲権限表示領域１００２を備える。
【００６２】
本実施形態の場合、図６（ｃ）に示すように、リソースサーバーモジュール３１０の提供するサービスの内の全ての機能に対応するスコープがスコープグループを示す「ｇｒｏｕｐ」に関連付けられている。そのため、認可確認画面１１００において、全てのスコープに対応する権限の内のユーザーが所持している権限が権限委譲の範囲である旨を説明している。なお、全てのスコープに対応する権限の内のユーザーが所持している権限が権限委譲の範囲である旨を必ずしも認可確認画面に表示する必要はない。しかし、表示しない場合でも、スコープグループに関連付く少なくとも１つのスコープの範囲（ここでは、ａｄｍｉｎ、ｅｄｉｔ、ｒｅａｄ、ｄｅｖｉｃｅの範囲）で、クライアントアプリケーション４２０が、リソースサーバーモジュール３１０が提供するＷｅｂサービスを利用する可能性があることを表示させる必要はある。また、認可確認画面１０００、１１００は、ユーザーが上記情報の内容について認可操作を実行する許可ボタン１００３、および拒否を実行する拒否ボタン１００４を備える。さらに、図１０（ｂ）が示すように、認可確認画面１１００は、スコープグループ説明領域１１０１を備える。スコープグループ説明領域１１０１は、スコープグループが指定された場合に、委譲権限表示領域１００２で示した委譲する権限の範囲がユーザーの権限の変化によって動的に変更される旨を説明する領域である。
【００６３】
認可サーバーモジュール２１０からの応答に応じて、Ｗｅｂブラウザー４１０は、取得した認可確認画面１０００もしくは認可確認画面１１００をユーザーに提示する。そして、ユーザーが許可ボタン１００３、もしくは拒否ボタン１００４を押下した場合、Ｗｅｂブラウザー４１０は、その認可確認結果を取得し、認可サーバーモジュール２１０に通知する。
【００６４】
認可サーバーモジュール２１０は、Ｗｅｂブラウザー４１０から認可確認結果を取得する。そして、取得した認可確認結果が許可である場合は、認可サーバーモジュール２１０は、認可確認処理の結果を「許可応答」として認可確認処理（Ｓ１．１１）を終了する。一方、認可確認結果が拒否である場合は、認可サーバーモジュール２１０は、認可確認処理の結果を「拒否応答」として認可確認処理（Ｓ１．１１）を終了する。
【００６５】
次に、認可サーバーモジュール２１０において、認可確認処理（Ｓ１．１１）の結果が「許可応答」であった場合のシーケンスについて説明する。つまり、図４におけるＳ３．１〜Ｓ３．１５の処理が行われる。
【００６６】
Ｓ３．１にて、認可サーバーモジュール２１０は、認可コードを発行する。具体的には、認可サーバーモジュール２１０は、トークンＩＤ「ｃｄ＿０００００１」もしくは「ｃｄ＿０００００２」を発行する。更に、認可サーバーモジュール２１０は、認可要求に含まれるクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」とリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」、スコープ、認証済みのユーザーのユーザーＩＤに対応するＵＵＩＤ「１００００００１」をトークンテーブル（図７（ａ））に登録する。その際、認可サーバーモジュール２１０は、トークン種別を認可コードとし、有効期限として当該認可コードが有効である期限の日時を登録する。
【００６７】
図７（ａ）に、認可サーバーモジュール２１０のトークンテーブルの例を示す。図７（ａ）では、トークンが有効か否かを示す状態を「有効」として登録しているが、有効期限を検証することで有効性を毎度確認する構成としてもよい。スコープとしては、「ｒｅａｄ」、もしくはスコープグループである「ｇｒｏｕｐ」が設定される。
【００６８】
Ｓ３．２、Ｓ３．３にて、認可サーバーモジュール２１０は、発行した認可コードのトークンＩＤ「ｃｄ＿０００００１」もしくは「ｃｄ＿０００００２」を付与してＷｅｂブラウザー４１０を介し、クライアントアプリケーション４２０に認可を応答する。具体的には、認可サーバーモジュール２１０は、認可要求時に取得したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」に対してＷｅｂブラウザー４１０がリダイレクトするよう、Ｗｅｂブラウザー４１０に応答する。
【００６９】
Ｓ３．４にて、Ｗｅｂブラウザー４１０から認可応答を受け付けたクライアントアプリケーション４２０は、認可サーバーモジュール２１０に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード「ｃｄ＿０００００１」もしくは「ｃｄ＿０００００２」、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」、および認可要求時に送信したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」が含まれる。
【００７０】
Ｓ３．５にて、認可サーバーモジュール２１０は、取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」の組をもってクライアントを認証する。具体的には、認可サーバーモジュール２１０は、取得した情報が、クライアントテーブル（図６（ｂ））の組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合は、認可サーバーモジュール２１０は、クライアントアプリケーション４２０に認証エラーを応答する。
【００７１】
クライアント認証に成功した場合、Ｓ３．６にて、認可サーバーモジュール２１０は、取得した認可コード「ｃｄ＿０００００１」もしくは「ｃｄ＿０００００２」を検証する。認可コードの検証としては、認可サーバーモジュール２１０は、取得した認可コードがトークンテーブル（図７（ａ））に登録されているかを確認し、登録されている場合は更に、その認可コードが有効かを検証する。更に、認可サーバーモジュール２１０は、認可トークン要求にて取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」とリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」がトークンテーブル（図７（ａ））のクライアントＩＤおよびリダイレクトＵＲＩと一致するか否かを検証する。認可コード検証の結果が「無効」であった場合、認可サーバーモジュール２１０は、クライアントアプリケーション４２０にトークン不正エラーを応答する。一方、認可コード検証の結果が「有効」であった場合、認可サーバーモジュール２１０は、認可コードに関連付けられたスコープに対して、Ｓ２．１のスコープ検証処理を実施する。スコープ検証処理の詳細については図９を用いて後述する。
【００７２】
スコープ検証処理（Ｓ２．１）の結果、「権限あり」となった場合、Ｓ３．７にて、認可サーバーモジュール２１０は、認可トークンを発行する。具体的には、認可サーバーモジュール２１０は、トークンＩＤ「ａｔ＿０００００１」もしくは「ａｔ＿０００００２」を発行し、認可コードに関連付けられたユーザーのＵＵＩＤ「１００００００１」、スコープ「ｒｅａｄ」もしくは「ｇｒｏｕｐ」、および認証したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークンテーブルに登録する。その際、認可サーバーモジュール２１０は、トークン種別を「認可トークン」とし、有効期限として当該認可トークンが有効である期限の日時を登録する。
【００７３】
次に、認可サーバーモジュール２１０は、これらの情報からＪＷＴを生成し、署名値を計算する。図１１は、トークンＩＤ「ａｔ＿０００００２」の認可トークンとして生成されるＪＷＴの例である。例示では見やすいように改行やインデントを含めて示している。Ｐａｙｌｏａｄには、トークンテーブルに登録されたトークンＩＤを「ｊｔｉ」に、ユーザーのＵＵＩＤを「ｓｕｂ」に、クライアントＩＤを「ａｚｐ」に、有効期限を「ｅｘｐ」に設定する。そして、前の処理で取得した権限を有している１または複数のスコープを、「ｓｃｏｐｅｓ」の「ｏｗｎｅｒ」に設定する。トークンテーブルに登録したスコープがスコープグループだった場合は、別途「ｓｃｏｐｅｓ」の「ｇｒｏｕｐ」配下に設定してもよい。そして、認可サーバーモジュール２１０は、生成したＪＷＴに対して、保持している秘密鍵を用いてＪＷＳに従った署名値（署名情報）を作成し、付与する。
【００７４】
図１１におけるＥｎｃｏｄｅｄは、実際に生成された署名付き認可トークンの例を示している。ただし、署名値については省略している。なお、ＪＷＴに設定する各項目については記載の項目に限定するものではなく、例えば、「ｎｂｆ」としてトークンが有効になる日時、「ｉａｔ」としてトークンを発行した時刻を設定してもよい。
【００７５】
Ｓ３．８にて、認可サーバーモジュール２１０は、リフレッシュトークンを発行する。具体的には、認可サーバーモジュール２１０は、トークンＩＤ「ｒｔ＿０００００１」もしくは「ｒｔ＿０００００２」を発行する。更に、認可サーバーモジュール２１０は、それぞれの認可トークンに関連付けられたユーザーのＵＵＩＤ「１００００００１」、スコープ、および認証したクライアントＩＤをトークンテーブルに登録する。その際、トークン種別は「リフレッシュトークン」とし、有効期限として当該リフレッシュトークンが有効である期限の日時を登録する。なお、ＯＡｕｔｈ２．０の場合、認可コードは一度しか利用できないように制御することが推奨されているため、トークンＩＤ「ｃｄ＿０００００１」、「ｃｄ＿０００００２」の認可コードの状態を「無効」にする。無効にする処理として、状態の値を変更する代わりに、有効期限を過去の日時に更新することで無効扱いにしてもよいし、テーブルのレコードそのものを削除することで無効にしてもよい。
【００７６】
図７（ｂ）に、認可サーバーモジュール２１０のトークンテーブルの例を示す。例では、図７（ａ）で示した認可サーバーモジュール２１０のトークンテーブルに対してデータが追加、変更された状態を示している。
【００７７】
Ｓ３．９にて、認可サーバーモジュール２１０は、発行した認可トークンのトークンＩＤ「ａｔ＿０００００１」もしくは「ａｔ＿０００００２」に署名を付与した署名付き認可トークンと、リフレッシュトークンのトークンＩＤ「ｒｔ＿０００００１」もしくは「ｒｔ＿０００００２」をクライアントアプリケーション４２０に応答する。
【００７８】
Ｓ３．１０にて、認可トークンを取得したクライアントアプリケーション４２０は、リソースサーバーモジュール３１０が公開するＡＰＩに対してリソース要求を行う。ここでは、それぞれの署名付き認可トークンを用いて設定値を参照するためのＡＰＩを呼び出したとして説明する。
【００７９】
Ｓ３．１１にて、リソース要求を受けたリソースサーバーモジュール３１０は、認可トークン検証処理を行う。図１２は、リソースサーバーモジュール３１０における認可トークン検証処理である。
【００８０】
Ｓ１２０１にて、リソースサーバーモジュール３１０は、リソース要求されたリソースについて、自身で権限検証するリソースか、認可サーバーモジュール２１０へ検証要求すべきリソースかを判定する。認可サーバーモジュール２１０へ検証要求すべきと判定された場合（Ｓ１２０１にてＮＯ）、Ｓ３．１２の権限検証要求処理行う。自身で権限検証すると判定された場合（Ｓ１２０１にてＹＥＳ）Ｓ１２０２へ進む。
【００８１】
ここでの判定に関し、例えば、管理者権限が必要なリソースは、その時点において権限を有しているか否かを確認すべきリソースであるとする。一方、署名付き認可トークンは、設定された有効期限の範囲内においては、発行の時点で権限を有していればリソース要求時点で権限を失っていたとしてもリソースへのアクセスを許可してしまうというリスクがある。したがって、Ｓ１２０１での判定は、署名付き認可トークンに設定する有効期限と、リソースアクセスに必要な権限をどこまで厳密に管理すべきか、に応じて行う。
【００８２】
例えば、権限そのものが有償で、権限を付与できる数に制限があるようなケースを考える。このような場合に、署名付き認可トークンの有効期限が十分長いと、署名付き認可トークン発行後に権限を外し、別のユーザーに権限を付与してから署名付き認可トークンを発行する、という処理を繰り返す事で、権限を付与できる数の制限が形骸化してしまう。このような問題に対し、自身で検証を行うか、認可サーバーモジュール２１０に検証を依頼するかを切り替える。ここでの判定基準としては、所定のＷｅｂサービスの利用について、セキュリティや厳密性が要求される場合には、認可サーバーモジュール２１０に要求することが考えられる。
【００８３】
Ｓ１２０２にて、リソースサーバーモジュール３１０は、リソース要求の際に付与されている認可トークンが署名付き認可トークンであるか否かを確認する。署名付き認可トークンでは無い場合は（Ｓ１２０２にてＮＯ）、Ｓ３．１２の権限検証要求処理を実行する。署名付き認可トークンである場合は（Ｓ１２０２にてＹＥＳ）、Ｓ１２０３へ進む。なお、認可サーバーモジュール２１０が署名付き認可トークンしか発行しない場合は、本処理は省略できる。
【００８４】
Ｓ１２０３にて、リソースサーバーモジュール３１０は、保持もしくは認可サーバーモジュール２１０から取得した公開鍵を用いて、受信した署名付き認可トークンの署名を検証する。
【００８５】
Ｓ１２０４にて、リソースサーバーモジュール３１０は、署名が正しく、かつ、その認可トークンが有効期限内か否かを判定する。条件を満たさない場合（Ｓ１２０４にてＮＯ）、Ｓ３．１５のエラー応答を行う。一方、条件を満たす場合（Ｓ１２０４にてＹＥＳ）Ｓ１２０５へ進む。
【００８６】
Ｓ１２０５にて、リソースサーバーモジュール３１０は、要求されたリソースが、トークンに記載のスコープの範囲内かを判定する。このとき、リソースサーバーモジュール３１０は、スコープグループではなく、権限を有しているものに絞り込んだスコープに基づいて判定を行う。具体的には、図１１のＪＷＴの例で説明すると、「ｓｃｏｐｅｓ」の、「ｏｗｎｅｒ」に記載されたスコープで判定する。リソースがスコープの範囲内であると判定された場合（Ｓ１２０５にてＹＥＳ）Ｓ３．１４のリソース取得へと遷移する。範囲内でないと判定された場合（Ｓ１２０５にてＮＯ）、Ｓ３．１５のエラー応答を行う。
【００８７】
次に、リソースサーバーモジュール３１０の認可トークン検証処理（Ｓ３．１１）にて、認可サーバーモジュール２１０で権限検証すべきと判定された場合の処理を説明する。
【００８８】
Ｓ３．１２にて、リソースサーバーモジュール３１０は、認可サーバーモジュール２１０に対して権限検証を要求する。その際、リソースサーバーモジュール３１０は、取得した認可トークン「ａｔ＿０００００１」もしくは「ａｔ＿０００００２」および検証対象である要求されたリソースのスコープである「ｒｅａｄ」を認可サーバーモジュール２１０に渡す。
【００８９】
Ｓ４．１にて、認可サーバーモジュール２１０は、権限検証処理を行う。認可サーバーモジュール２１０による権限検証処理の詳細については図１３を用いて後述する。
【００９０】
Ｓ３．１３にて、リソースサーバーモジュール３１０は、認可サーバーモジュール２１０から権限検証処理（Ｓ４．１）の結果を取得する。
【００９１】
結果が許可であった場合、Ｓ３．１４にて、リソースサーバーモジュール３１０は、リソース、具体的には要求された設定値を取得する。
【００９２】
Ｓ３．１５にて、リソースサーバーモジュール３１０は、クライアントアプリケーション４２０にリソースを応答する。なお、権限検証の結果、拒否であった場合は、リソースサーバーモジュール３１０は、Ｓ３．１４をスキップし、クライアントアプリケーション４２０にエラーを応答する。
【００９３】
次に、認可サーバーモジュール２１０において、認可確認処理（Ｓ１．１１）の結果が「拒否応答」であった場合のシーケンスについて説明する。ここでは、図４におけるＳ５．１〜Ｓ５．２の処理が行われる。
【００９４】
Ｓ５．１、Ｓ５．２にて、認可サーバーモジュール２１０は、Ｗｅｂブラウザー４１０を介し、クライアントアプリケーション４２０に拒否応答を応答する。より具体的には、認可サーバーモジュール２１０は、認可要求時に取得したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｌｏｃａｌｈｏｓｔ：ｘｘ」に対してＷｅｂブラウザー４１０がリダイレクトするよう、Ｗｅｂブラウザー４１０に応答する。
【００９５】
以上、クライアントアプリケーション４２０が、リソースサーバーモジュール３１０が公開するＡＰＩを利用するまでの、権限委譲プロトコルを利用した本実施形態のシーケンスである。なお、ＯＡｕｔｈ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅ  Ｇｒａｎｔを例に認可トークンの発行処理について説明したが、権限委譲プロトコルであればこれに限るものではない。例えば、必ずしも認可コードの発行の必要はなく、最終的に認可情報である認可トークンが発行されさえすればよい。
【００９６】
［リフレッシュシーケンス］
次に、図８を用いて本実施形態に係る、クライアントアプリケーション４２０が認可トークンをリフレッシュし、リソースサーバーモジュール３１０が公開するＡＰＩを利用するためのリフレッシュシーケンスを説明する。なお、図８中の“Ａｌｔ”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。また、“Ｏｐｔ”はオプションであり、処理を省くことも可能である。なお、図４に示した処理と同じ処理については、同じ参照番号を付し、説明を省略する。
【００９７】
本シーケンスは、Ｓ６．１のユーザー操作から開始されるケースと、クライアントアプリケーション４２０が自身の処理中にて開始するケースとがある。そのため、Ｓ６．１、Ｓ６．２はオプションとして記載している。
【００９８】
Ｓ６．１にて、ユーザーは、Ｗｅｂブラウザー４１０に表示されている再実行操作（不図示）を行う。ここでの再実行操作は、例えば、クライアントアプリケーション４２０にて提供される各種操作画面（不図示）を介して行われる。
【００９９】
Ｓ６．２にて、Ｗｅｂブラウザー４１０は、クライアントアプリケーション４２０に再実行を要求する。再実行を受け付けたクライアントアプリケーション４２０は、リソースサーバーモジュール３１０が公開するＡＰＩに対して、すでに取得済みの認可トークンを用いてリソース要求を行う。ここでは、認可トークンが無効であったとして説明する。なお、リソース要求（Ｓ３．１０）から、リソースサーバーモジュール３１０がクライアントアプリケーション４２０に対してエラー応答を返すまでの処理（Ｓ３．１５）については、図４を用いて説明した処理フローと同様のため、ここでは説明を省略する。
【０１００】
Ｓ７．５にて、エラー応答を受けたクライアントアプリケーション４２０は、認可サーバーモジュール２１０に対して認可トークンリフレッシュ要求（認可トークンの再発行要求）を行う。その際、認可トークン、リフレッシュトークン応答にて取得したトークンＩＤ「ｒｔ＿０００００１」もしくは「ｒｔ＿０００００２」、および、クライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」が送信される。
【０１０１】
Ｓ７．６にて、認可サーバーモジュール２１０は、取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」の組を用いてクライアントを認証する。具体的には、取得した情報が、クライアントテーブル（図６（ｂ））の組と一致するかを検証する事で認証する。不図示であるが、ここでクライアント認証に失敗した場合は、認可サーバーモジュール２１０は、クライアントアプリケーション４２０に認証エラーを応答する。
【０１０２】
クライアント認証に成功した場合、Ｓ７．７にて、認可サーバーモジュール２１０は、取得したリフレッシュトークンを検証する。認可コードの検証としては、取得したリフレッシュトークンがトークンテーブルに登録されているかを確認し、登録されている場合は更に、リフレッシュトークンが有効か否かを検証する。更に、認可サーバーモジュール２１０は、認可トークンリフレッシュ要求にて取得したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」がトークンテーブルのクライアントＩＤと一致するか否かを検証する。リフレッシュトークン検証の結果が「無効」であった場合の処理は後述する。ここで、リフレッシュトークン検証の結果が「有効」であった場合、認可サーバーモジュール２１０は、リフレッシュトークンに関連付けられたユーザーのＵＵＩＤおよびスコープに対して、スコープ検証処理（Ｓ２．１）を実施する。このスコープ検証処理（Ｓ２．１）の詳細については後述する。
【０１０３】
次に、リフレッシュトークン検証の結果が「有効」であり、かつ、スコープ検証処理（Ｓ２．１）の結果が「権限あり」であった場合、Ｓ８．１にて、認可サーバーモジュール２１０は、認可トークンを発行する。より具体的には、認可サーバーモジュール２１０は、トークンＩＤ「ａｔ＿０００００３」もしくは「ａｔ＿００００４」を発行する。更に、認可サーバーモジュール２１０は、リフレッシュトークンに関連付けられたユーザーのＵＵＩＤ「１００００００１」、スコープ「ｒｅａｄ」もしくは「ｇｒｏｕｐ」、および認証したクライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークンテーブル（図７）に登録する。その際、トークン種別は「認可トークン」とし、有効期限として当該認可トークンが有効である期限の日時を登録する。次に、認可サーバーモジュール２１０は、これら情報と、スコープ検証処理（Ｓ２．１）の結果得られたスコープからＪＷＴを生成し、署名値を計算する。詳細については図１１を用いて説明済みのため省略する。そして、認可サーバーモジュール２１０は、生成したＪＷＴに対して、保持している秘密鍵を用いてＪＷＳに従った署名値を作成し、付与する。
【０１０４】
さらに認可サーバーモジュール２１０は、ＯＡｕｔｈ２．０のオプションの仕様として、Ｓ８．２にてリフレッシュトークンを再発行するように構成してもよい。その場合は、Ｓ８．３にて、認可サーバーモジュール２１０は、利用したリフレッシュトークンを無効化する。具体的には、認可サーバーモジュール２１０は、トークンＩＤ「ｒｔ＿０００００３」、「ｒｔ＿００００４」をそれぞれ発行し、さらに、「ｒｔ＿０００００１」、「ｒｔ＿００００２」のリフレッシュトークンの状態を「無効」にする。本実施形態では、リフレッシュトークンの再発行処理は実施しない方式で説明する。
【０１０５】
Ｓ８．４にて、認可サーバーモジュール２１０は、発行した署名付き認可トークンをクライアントアプリケーション４２０に応答する。
【０１０６】
Ｓ３．１０にて、認可トークンを取得したクライアントアプリケーション４２０は、リソースサーバーモジュール３１０が公開するＡＰＩに対してリソース要求を行う。これ以降の処理については、図４を用いて説明した通りである。
【０１０７】
次に、認可サーバーモジュール２１０において、スコープ検証処理（Ｓ２．１）の結果が権限エラー応答だった場合のシーケンスを説明する。
【０１０８】
Ｓ９．１にて、認可サーバーモジュール２１０は、クライアントアプリケーション４２０に対してリフレッシュトークンが「無効」であると応答する。リフレッシュトークンの無効応答を受信したクライアントアプリケーション４２０は、前述の認可要求（Ｓ１．３）を実施する。その後の処理は、図４を用いて説明したシーケンスと同様であるため説明を省略する。
【０１０９】
以上、クライアントアプリケーション４２０が認可トークンをリフレッシュし、リソースサーバーモジュール３１０が公開するＡＰＩを利用するための権限委譲プロトコルにおけるリフレッシュシーケンスである。
【０１１０】
（スコープ検証処理）
続いて、図４および図８にて示したスコープ検証処理（Ｓ２．１）について、図９を用いて説明する。スコープ検証処理（Ｓ２．１）を用いることで、前述のスコープグループによる認可トークンの発行や検証が可能となる。
【０１１１】
Ｓ９０１にて、認可サーバーモジュール２１０は、ユーザーのＵＵＩＤ、スコープを取得する。ここでＵＵＩＤ「１００００００１」で、スコープ「ｒｅａｄ」、もしくはスコープ「ｇｒｏｕｐ」であるとして説明する。
【０１１２】
Ｓ９０２にて、認可サーバーモジュール２１０は、Ｓ９０１にて取得したＵＵＩＤを用いて、ユーザーの権限を取得する。より具体的には、認可サーバーモジュール２１０は、ＵＵＩＤ「１００００００１」を用いて認可サーバーモジュール２１０のユーザーテーブルから権限情報「デバイス設定者」、「設定値参照者」を取得する。
【０１１３】
Ｓ９０３にて、認可サーバーモジュール２１０は、Ｓ９０１で取得したスコープに含まれる数の分、Ｓ９０４〜Ｓ９１０を繰り返す。本実施形態では、「ｒｅａｄ」もしくは「ｇｒｏｕｐ」のいずれかが単独でスコープが指定された場合（すなわち、スコープの数は１）として説明する。
【０１１４】
Ｓ９０４にて、認可サーバーモジュール２１０は、スコープがスコープグループか否かを判定する。その際、認可サーバーモジュール２１０のスコープ定義テーブルの権限情報を確認し、ここが「グループ」である場合はスコープグループであるとして判定する。なお、この方式に限るものではない。例えば、別途、スコープかスコープグループかを区別するための項目を増やしてもよいし、スコープＩＤの形式としてプレフィックスやポストフィックスを付与したスコープＩＤとして、その付与された情報で判別可能としてもよい。スコープグループでない場合（Ｓ９０４にてＮＯ；本例では「ｒｅａｄ」の場合）Ｓ９０５へ進み、スコープグループである場合（Ｓ９０４にてＹＥＳ；本例では「ｇｒｏｕｐ」の場合）Ｓ９０８へ進む。
【０１１５】
Ｓ９０５にて、認可サーバーモジュール２１０は、スコープとユーザーの権限の確認を行う。具体的には、認可サーバーモジュール２１０は、スコープ定義テーブル（図６（ｃ））の権限情報が、Ｓ９０２で取得したユーザーの権限に含まれているか否かを確認する。つまり、「ｒｅａｄ」スコープは権限情報として「設定値参照者」が定義されているため、Ｓ９０２で取得したユーザーの権限に「設定値参照者」が含まれているかが確認される。
【０１１６】
Ｓ９０６にて、認可サーバーモジュール２１０は、Ｓ９０５の確認の結果、権限を有しているか否かを判定する。「権限あり」と判定された場合（Ｓ９０６にてＹＥＳ）、処理対象を次のスコープとして、Ｓ９０３のループ処理を継続する。すべてのスコープに対して処理が完了していた場合は、Ｓ９１１へ進むこととなる。「権限なし」と判定された場合（Ｓ９０６にてＮＯ）Ｓ９０７へ進む。
【０１１７】
Ｓ９０７にて、認可サーバーモジュール２１０は、権限エラーを応答する。そして、本処理フローを終了する。
【０１１８】
Ｓ９１１にて、認可サーバーモジュール２１０は、「権限あり」として権限を有するスコープを応答する。そして、本処理フローを終了する。なお、本実施形態では、ユーザーの権限に「設定値参照者」が含まれているため、「権限あり」と判定される。
【０１１９】
Ｓ９０８にて、認可サーバーモジュール２１０は、スコープグループに関連付けられた全スコープを取得する。具体的には、認可サーバーモジュール２１０は、スコープ定義テーブル（図６（ｃ））からグループ情報を取得する。本実施形態では「ｇｒｏｕｐ」スコープのグループ情報は「ａｄｍｉｎ」、「ｅｄｉｔ」、「ｒｅａｄ」、「ｄｅｖｉｃｅ」が定義されている。
【０１２０】
Ｓ９０９にて、認可サーバーモジュール２１０は、取得した全スコープの各々に対してＳ９０５と同様のスコープとユーザーの権限の確認処理を実施する。
【０１２１】
Ｓ９１０にて、認可サーバーモジュール２１０は、全スコープのうち１つでもユーザーが権限を有しているか否かを判定する。いずれかが権限を有している場合は、処理対象を次のスコープとして、Ｓ９０３のループ処理を継続する。その際、認可サーバーモジュール２１０は、スコープグループに関連付けられたスコープの内、Ｓ９０９にて「権限あり」と判定されたスコープを抽出する。すべてのスコープに対して処理が完了していた場合は、Ｓ９１１へ進む。いずれのスコープも「権限なし」と判定された場合（Ｓ９１０にてＮＯ）Ｓ９０７へ進む。
【０１２２】
Ｓ９１１にて、認可サーバーモジュール２１０は、「権限あり」として権限を有するスコープを応答する。そこには、Ｓ９１０の判定の際に抽出されたスコープを含む。本実施形態では、ユーザーの権限に「設定値参照者」、「デバイス設定者」が含まれており、さらに、「ｒｅａｄ」スコープ、「ｄｅｖｉｃｅ」スコープの権限情報がそれぞれ一致するため、２つの権限を有していることになる。結果、Ｓ９１０にて「権限あり」としてスコープ「ｒｅａｄ」、「ｄｅｖｉｃｅ」、および、「ｇｒｏｕｐ」が応答される。
【０１２３】
以上、本実施形態に係るスコープ検証処理について説明した。このスコープ検証処理を用いることで、スコープグループに対して権限を有するスコープを抽出しつつ、権限の有無を検証する事ができる。
【０１２４】
本願発明の特徴的な構成の１つは、クライアントアプリケーション４２０が認可トークンリフレッシュ要求を認可サーバーモジュール２１０に送信した際に、認可サーバーモジュール２１０が、スコープ検証処理（図９）を行い、認可トークンを発行する点である。と言うのも、本願発明はＪＷＴおよびＪＷＳを用いた認可処理を想定している。そこで、認可サーバーモジュール２１０ではなくリソースサーバーモジュール３１０が認可トークン検証処理（図１２）を実行する形態であり、認可トークン検証処理時に可能な限り最新の権限付与状況を考慮したいと言う要望がある。詳細については、図１４を用いて説明を行う。
【０１２５】
（権限検証処理）
続いて、図４に示した権限検証処理（Ｓ４．１）の詳細について、図１３を用いて説明する。本実施形態に係る権限検証処理（Ｓ４．１）により、スコープグループを指定して取得した認可トークンであれば、そのスコープグループ内に含まれるスコープの範囲内にて、権限検証が実施される。そして、そのスコープに対応する権限をユーザーが所持していた場合は権限検証の結果、権限ありと判定される。
【０１２６】
Ｓ１３０１にて、認可サーバーモジュール２１０は、取得した認可トークンから、全スコープ、ユーザーのＵＵＩＤを取得する。ここでは「ａｔ＿０００００１」もしくは、「ａｔ＿０００００２」が認可トークンとして取得された場合をそれぞれ説明する。認可トークン「ａｔ＿０００００１」の場合、認可サーバーモジュール２１０のトークンテーブル（図７（ｂ））にて、ユーザーのＵＵＩＤ「１００００００１」、スコープ「ｒｅａｄ」が取得される。認可トークン「ａｔ＿０００００２」の場合、認可サーバーモジュール２１０のトークンテーブル（図７（ｂ））にて、ユーザーのＵＵＩＤ「１００００００１」、スコープ「ｇｒｏｕｐ」が取得される。
【０１２７】
Ｓ１３０２にて、認可サーバーモジュール２１０は、取得されたスコープの数だけ、Ｓ１３０３〜Ｓ１３０４の処理をループして実施する。本実施形態では、それぞれ１個のスコープが取得された場合を例に挙げて説明する。
【０１２８】
Ｓ１３０３にて、認可サーバーモジュール２１０は、取得したスコープがスコープグループか否かを判定する。その際、認可サーバーモジュール２１０は、認可サーバーモジュール２１０のスコープ定義テーブル（図６（ｃ））の権限情報を確認し、「グループ」であった場合はスコープグループであるとして判定する。なお、この方式に限るわけではなく、例えば、別途スコープかスコープグループかを区別するための項目を増やしてもよいし、スコープＩＤの形式としてプレフィックスやポストフィックスを付与したスコープＩＤとして、その付与された情報で判別可能としてもよい。スコープがスコープグループでない場合（Ｓ１３０３にてＮＯ；本例の場合はスコープが「ｒｅａｄ」の場合）、未処理のスコープを処理対象として、Ｓ１３０２のループ処理を継続する。一方、スコープがスコープグループである場合（Ｓ１３０３にてＹＥＳ；本例の場合はスコープが「ｇｒｏｕｐ」の場合）、Ｓ１３０４へ処理を進める。
【０１２９】
Ｓ１３０４にて、認可サーバーモジュール２１０は、スコープグループに関連付けられた全スコープを取得する。具体的には、認可サーバーモジュール２１０は、スコープ定義テーブル（図６（ｃ））からグループ情報を取得する。図６（ｃ）の例では、「ｇｒｏｕｐ」スコープのグループ情報は「ａｄｍｉｎ」、「ｅｄｉｔ」、「ｒｅａｄ」、「ｄｅｖｉｃｅ」が定義されている。認可サーバーモジュール２１０は、取得したグループ情報を分解し、それぞれスコープを後続の処理対象として記憶する。そして、未処理のスコープを処理対象として、Ｓ１３０２のループ処理を継続する。すべてのスコープに対する処理が完了すると、Ｓ１３０５へ遷移する。
【０１３０】
Ｓ１３０５にて、認可サーバーモジュール２１０は、Ｓ１３０２にて取得したＵＵＩＤを用いて、ユーザーの権限を取得する。具体的には、認可サーバーモジュール２１０は、ＵＵＩＤ「１００００００１」を用いて認可サーバーモジュール２１０のユーザーテーブル（図６（ａ））から権限情報「デバイス設定者」、「設定値参照者」を取得する。
【０１３１】
Ｓ１３０６にて、認可サーバーモジュール２１０は、権限検証リクエストに含まれる検証対象のスコープの数分、Ｓ１３０７〜Ｓ１３１０の処理をループして実施する。本実施形態では、検証対象のスコープとして、設定値を参照するためのスコープである「ｒｅａｄ」が指定されたとして説明する。
【０１３２】
Ｓ１３０７にて、認可サーバーモジュール２１０は、検証対象のスコープが、スコープグループを分解した結果を含む、トークンから取得した１または複数のスコープに含まれているか否かを検証する。含まれていないと判定された場合は（Ｓ１３０７にてＮＯ）、Ｓ１３０８へ進み、含まれていると判定された場合は（Ｓ１３０７にてＹＥＳ）Ｓ１３０９へ進む。本実施形態では、検証対象のスコープ「ｒｅａｄ」は、認可トークン「ａｔ＿０００００１」から取得されたスコープが「ｒｅａｄ」であるため、含まれると判定され、Ｓ１３０９へ進む。また、認可トークン「ａｔ＿０００００２」から取得されたスコープは、「ａｄｍｉｎ」、「ｅｄｉｔ」、「ｒｅａｄ」、「ｄｅｖｉｃｅ」であるため、含まれると判定され、Ｓ１３０９へ進む。
【０１３３】
Ｓ１３０８にて、認可サーバーモジュール２１０は、本検証対象のスコープに対しては権限がないと判定し、その旨を応答として記憶する。そして、次の未処理のスコープを検証対象としてＳ１３０７のループ処理を継続する。
【０１３４】
Ｓ１３０９にて、認可サーバーモジュール２１０は、検証対象のスコープとユーザーの権限の確認を行う。具体的には、認可サーバーモジュール２１０は、スコープ定義テーブル（図６（ｃ））の権限情報が、Ｓ１３０５で取得したユーザーの権限に含まれているか否かを確認する。具体的には、検証対象のスコープ「ｒｅａｄ」スコープは権限情報として「設定値参照者」が定義されているため、Ｓ１３０５で取得したユーザーの権限に「設定値参照者」が含まれているかが確認される。
【０１３５】
Ｓ１３１０にて、認可サーバーモジュール２１０は、Ｓ１３０９にて「権限あり」となった場合は、本検証対象のスコープに対しては権限があるとして記憶する。そして、Ｓ１３０７のループ処理を継続し、すべての検証対象のスコープに対して権限検証が終了すると、Ｓ１３１１へ進む。
【０１３６】
Ｓ１３１１にて、認可サーバーモジュール２１０は、権限検証の結果を応答し、処理を終了する。その際、認可サーバーモジュール２１０は、記憶された権限検証の結果を全て応答する。例えば、検証リクエストに複数のスコープが含まれていた場合は、それぞれのスコープに対する検証結果が応答される。本実施形態では、「ａｔ＿００００１」、「ａｔ＿００００２」双方とも「権限あり」という結果が応答される。そして、本処理フローを終了する。
【０１３７】
本実施形態に係る権限検証処理により、スコープグループを指定して取得した認可トークンであれば、そのスコープグループが分解され検証される。そのため、スコープグループ内のスコープの範囲内であれば、ユーザーの認可処理を実施することなく、ユーザーの権限の検証判定、つまり、Ｓ１３０９の処理を実施することが可能となる。つまり、ユーザーの権限の変更に対し、ユーザーに再度認可確認処理を強いることなく、ユーザーの権限に即した権限検証処理を実施することが可能となる。
【０１３８】
［時系列によるユースケースの説明］
次に、図１４を用いてＯＡｕｔｈ２．０を例にスコープ定義に変更があった場合においても、ユーザーの再認可を必要することなくＡＰＩ利用が継続できるケースを説明する。更に、ユーザーの権限に変更があった場合においても、ユーザーの再認可を必要とすることなくＡＰＩ利用が継続できるケースを説明する。
【０１３９】
図１４（ａ）は、スコープ定義の変更とＡＰＩ実行の可否の振る舞いを時系列で示した図である。図１４（ａ）の右方向の矢印は時間軸である。また時間軸に対する矢印は特定の時間におけるスコープ定義や、ユーザーの権限、およびクライアントアプリケーション４２０からリソースサーバーモジュール３１０へのＡＰＩ利用および、その結果を示している。
【０１４０】
まず、図１４（ａ）に示す通り、ユーザー（ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」）は、その権限情報として「デバイス設定者」、「設定値参照者」を所持している。次に、スコープ定義としては図１４（ａ）で示している通りである。特に、スコープＩＤ「ｇｒｏｕｐ」は、そのメンバーとして「ｒｅａｄ」、「ｄｅｖｉｃｅ」スコープが含まれている。
【０１４１】
その状態で、クライアントアプリケーション４２０にてスコープ「ｇｒｏｕｐ」で署名付き認可トークン１（図１４（ａ）ではＪＷＴ１）を取得したとする。署名付き認可トークンを取得するためのシーケンスおよびフローについては前述した通りである。結果、スコープとしては、「ｒｅａｄ」、「ｄｅｖｉｃｅ」のスコープが記述された署名付き認可トークンが取得される。
【０１４２】
次に、クライアントアプリケーション４２０は、取得した署名付き認可トークン１（ＪＷＴ１）を利用して、リソースサーバーモジュール３１０のスコープ「ｒｅａｄ」を要求するリソースへのＡＰＩを実行する。このとき、署名付き認可トークンにスコープ「ｒｅａｄ」が含まれており、署名値は正しいためＡＰＩの実行は成功する。ここで署名値の検証は、認可サーバーモジュール２１０ではなく、リソースサーバーモジュール３１０にて実施される（図４のＳ３．１１、図１２）。その結果、認可サーバーモジュール２１０に負荷をかけることなく権限検証が可能となる。
【０１４３】
次に、クライアントアプリケーション４２０は、取得した署名付き認可トークン１（ＪＷＴ１）を利用して、リソースサーバーモジュール３１０のスコープ「ｏｒｄｅｒ」を要求するリソースへのＡＰＩを実行する。このとき、署名付き認可トークンにスコープ「ｏｒｄｅｒ」が含まれていないためＡＰＩの実行は拒否される。課題として説明したように、スコープ「ｏｒｄｅｒ」を指定してＯＡｕｔｈ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅ  Ｇｒａｎｔを再度処理し、別の認可トークンを取得しなければこのＡＰＩを利用することができない。従って、従来の方法では、ユーザーは、認可操作をもう一度実施しなければならない。
【０１４４】
次に、スコープ定義のスコープ「ｇｒｏｕｐ」のメンバーにスコープ「ｏｒｄｅｒ」を追加したとする。その後、クライアントアプリケーション４２０は、認可トークンのリフレッシュを実施する（図８）。このとき、スコープとして「ｒｅａｄ」、「ｄｅｖｉｃｅ」、「ｏｒｄｅｒ」のスコープが記載された署名付き認可トークン２（図１４（ａ）ではＪＷＴ２）が取得される。
【０１４５】
再度、クライアントアプリケーション４２０は、スコープ「ｏｒｄｅｒ」を要求するリソースへのＡＰＩを実行する。このとき、署名付き認可トークンにスコープ「ｏｒｄｅｒ」が含まれており、署名値は正しいためＡＰＩの実行は成功する。
【０１４６】
つまり、ユーザーに権限が付与されている限り、「ｇｒｏｕｐ」を指定して認可トークン取得した場合、リフレッシュをする事でそのままスコープ「ｏｒｄｅｒ」を必要とするＡＰＩを利用することができる。その結果、リソースサーバーモジュール３１０に新しい機能が実装された場合、クライアントアプリケーション４２０は、その機能を呼び出すＡＰＩを、認可トークンをユーザーに認可操作を再度実施させることなく利用できる。さらに、署名値の検証は、認可サーバーモジュール２１０ではなく、リソースサーバーモジュール３１０にて実施される（図８のＳ３．１１、図１２）。その結果、認可サーバーモジュール２１０に負荷をかけることなく権限検証が可能となる。
【０１４７】
図１４（ｂ）は、ユーザー権限の変更とＡＰＩ実行の可否の振る舞いを時系列で示した図である。図１４（ｂ）の右方向の矢印は時間軸である。また時間軸に対する矢印は矢印がさす特定の時間におけるスコープ定義や、ユーザーの権限、およびクライアントアプリケーション４２０からリソースサーバーモジュール３１０へのＡＰＩ利用および、その結果を示している。
【０１４８】
まず、図１４（ｂ）に示す通り、ユーザー（ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」）は、その権限情報として「デバイス設定者」、「設定値参照者」を所持している。次に、スコープ定義としては、図１４（ｂ）で示している通りである。特にスコープＩＤ「ｇｒｏｕｐ」は、そのメンバーとして「ｒｅａｄ」、「ｄｅｖｉｃｅ」、および「ｏｒｄｅｒ」スコープが含まれている。また、「ｏｒｄｅｒ」スコープに対して、権限情報として「設置作業者」が関連付けられている。
【０１４９】
その状態で、クライアントアプリケーション４２０にてスコープ「ｇｒｏｕｐ」で署名付き認可トークン１（図１４（ｂ）ではＪＷＴ１）を取得したとする。署名付き認可トークンを取得するためのシーケンスおよびフローについては前述したとおりである。このとき、スコープとしては、「ｒｅａｄ」、「ｄｅｖｉｃｅ」のスコープが記述された署名付き認可トークンが取得される。なお、図示していないが、ここでスコープ「ｏｒｄｅｒ」を指定して署名付き認可トークン１（ＪＷＴ１）の取得を実施しようとした場合、フロー（図９）で説明したとおりユーザーに権限がないため、取得に失敗する。
【０１５０】
次に、クライアントアプリケーション４２０は、取得した署名付き認可トークン１（ＪＷＴ１）を利用してリソースサーバーモジュール３１０のスコープ「ｒｅａｄ」を要求するリソースへのＡＰＩを実行する。署名付き認可トークンにスコープ「ｒｅａｄ」が含まれており、署名値は正しいため、ＡＰＩの実行は成功する。このとき、署名値の検証は、認可サーバーモジュール２１０ではなく、リソースサーバーモジュール３１０にて実施される。その結果、認可サーバーモジュール２１０に負荷をかけることなく権限検証が可能となる。
【０１５１】
次に、クライアントアプリケーション４２０は、取得した署名付き認可トークン１（ＪＷＴ１）を利用してリソースサーバーモジュール３１０のスコープ「ｏｒｄｅｒ」を要求するリソースへのＡＰＩを実行する。このとき、署名付き認可トークンにスコープ「ｏｒｄｅｒ」が含まれていないためＡＰＩの実行は拒否される。ここまでが課題として説明した状態である。
【０１５２】
次に、ユーザー（ユーザーＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」）に「設置作業者」の権限を付与する。その後に、クライアントアプリケーション４２０は、認可トークンのリフレッシュを実施する（図８）。その結果、スコープとして「ｒｅａｄ」、「ｄｅｖｉｃｅ」、「ｏｒｄｅｒ」のスコープが記載された署名付き認可トークン２（図１４（ｂ）ではＪＷＴ２）が取得される。
【０１５３】
クライアントアプリケーション４２０は、再度、スコープ「ｏｒｄｅｒ」を要求するリソースへのＡＰＩを実行する。その結果、署名付き認可トークン２（ＪＷＴ２）にスコープ「ｏｒｄｅｒ」が含まれており、署名値は正しいためＡＰＩの実行は成功する。
【０１５４】
つまり、ユーザーの権限の変更があった場合に、再度ユーザーに認可操作を強いることなく、そのままスコープ「ｏｒｄｅｒ」を必要とするＡＰＩを利用することができる。さらに、署名値の検証は、認可サーバーモジュール２１０ではなく、リソースサーバーモジュール３１０にて実施される。その結果、認可サーバーモジュール２１０に負荷をかけることなく権限検証が可能となる。
【０１５５】
以上、本実施形態では、スコープグループを定義しスコープグループを利用して権限委譲する。これにより、ユーザーの権限の変更があったとしても、ユーザーに再度認可操作を求めることなく変更されたユーザーの権限の範囲内でＡＰＩ利用を継続することができる。また、サービスの新たな機能の実装に伴いスコープに変更があったとしても、同じくユーザーに再度認可操作を求めることなく、ユーザーの権限に応じて新たな機能に対応するＡＰＩを含むＡＰＩの利用を継続することができる。
【０１５６】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【０１５７】
２００  認可サーバー、３００  リソースサーバー、４００  端末、２１０  認可サーバーモジュール、３１０  リソースサーバーモジュール、４１０  Ｗｅｂブラウザー、４２０  クライアントアプリケーション
【図１】
2018081643.tif 000003
【図２】
2018081643.tif 000004
【図３】
2018081643.tif 000005
【図４】
2018081643.tif 000006
【図５】
2018081643.tif 000007
【図６】
2018081643.tif 000008
【図７】
2018081643.tif 000009
【図８】
2018081643.tif 000010
【図９】
2018081643.tif 000011
【図１０】
2018081643.tif 000012
【図１１】
2018081643.tif 000013
【図１２】
2018081643.tif 000014
【図１３】
2018081643.tif 000015
【図１４】
2018081643.tif 000016