JP2015125510A - 権限管理サーバー及び権限管理方法 - Google Patents

Abstract

【課題】ひとつのテナントにおいて、個々のサービスのＡＰＩの利用上限が、他のサービスのＡＰＩの利用状況による影響を受けることがなく、サービスの利便性が向上した権限委譲システムを実現する。【解決手段】クライアントが利用するＡＰＩの上限数を設定し、権限委譲先からの要求に応じて認可トークンを発行するときと、発行した認可トークンの検証要求を受け付けたときに、権限委譲先に設定されたＡＰＩごとの使用上限数に従ってクライアント毎のＡＰＩ使用上限数を管理するＡＰＩカウント処理を行う。そこでは、ＡＰＩの使用数を増分し（Ｓ５．２）、使用上限数と比較し（Ｓ５．３）上限を超えていれば認可トークンの検証は失敗とする。【選択図】図１１

Description

本発明は、権限委譲システムにおけるクライアントのAPI呼び出し上限管理方法に関し、特に、同一テナントにおける複数クライアントからのAPI呼び出しに関する権限管理サーバー及び権限管理方法に関する。

近年、インターネット上に展開された所謂クラウドサービスの利用が拡大している。例えば、CRM（Customer Relationship Management）サービスを利用して顧客関係を管理する事や、SNS（Social Networking Service）を利用して、リアルタイムに情報発信、情報収集を行う事が、個人だけでなく、ビジネスの現場でも拡大している。また、これら多数のクラウドサービスは個々にWebサービスのAPIを公開しており、他のアプリケーションやクラウドサービスからAPIを介してサービスが提供する機能を利用する事が可能となっている。これにより、複数のクラウドサービスが公開する複数のAPIを組み合わせ、あたかも一つのWebサービスのように構成するマッシュアップという機能が広がりつつある。

その一方で、複数のクラウドサービスを連携するマッシュアップ機能の利用機会の増加によって、いくつかの課題が生まれる。すなわち、ユーザーが望んだ以上の情報が複数のクラウドサービス間で交換され、ユーザーデータや個人情報が漏えいするリスクがある。本来、各クラウドサービスにて必要以上にユーザーデータや個人情報等を取得することは望ましくなく、さらには、ユーザーが連携を望まないクラウドサービスに対してユーザーデータや個人情報が提供されてはならない。一方で、サービスの提供者からすると、クラウドサービス間の連携の仕組みは容易に実装できるものが好ましい。このような状況において、OAuth 2.0と呼ばれる認可の連携を実現させるための標準プロトコルが策定されている。

OAuth 2.0によれば、例えばあるサービスAが管理するユーザーのデータを取得するAPIに対して、そのユーザーから認められたサービスBがアクセスすることができる。このときサービスAは、サービスBからアクセスされる範囲を明らかにした上で、サービスBによるAPIへのアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。

ユーザーが認可操作を行うと、サービスBはサービスAからアクセスを認められたことを証明するトークン (以下、認可トークンと称する) を受け取り、サービスBによる以降のサービスAのAPIへのアクセスはその認可トークンを用いて実現できる。このユーザーの認可操作によって或るサービスが管理する当該ユーザーのリソースに対するアクセスを他のサービスに認める行為を権限委譲と称する。ここで認可トークンを用いるとサービスBは、ユーザーの認証情報なしに、認可を行ったユーザーの権限でサービスAのAPIにアクセスできる。またそのため、ユーザーから認可を受け認可トークンを取得したサービスBは、その認可トークンを厳重かつ適正に管理する責務を負う。

また、OAuth 2.0では、サービスBの成り済ましを防ぐために、サービスBを認証する必要がある。このサービスBを認証するために、サービスAは予めサービスBの認証情報、より具体的にはクライアントIDおよびシークレットを発行し、管理し、さらにはサービスBにそれら認証情報を設定しておく必要がある。以降、リソースを提供するサービスAをリソースサーバー、サービスAからみたサービスB、すなわちリソースサーバーを、そのサービスのユーザーから委譲された権限で利用する他のサービスのことを（そのリソースサーバーの）クライアントと呼称する。また、OAuth 2.0では、上述のユーザーの認可操作、認可トークン発行およびクライアントの認証を行う認可サーバーと、ユーザーのデータをリソースとして管理し、WebサービスとしてAPIを公開するリソースサーバーとを分けて構成する事が可能である。その場合、サービスBはユーザーからの権限委譲を受け、認可サーバーから認可トークンを取得し、その認可トークンを用いてリソースサーバーのAPIを利用する。そして、リソースサーバーは、取得した認可トークンを認可サーバーに検証依頼し、結果、アクセスの許可を得られた場合にのみリソースへのアクセスを許可し、サービスBにデータを応答するよう構成される。

クラウドサービスにおいて、Webサービスに公開するAPIは、クライアントごとに、単位時間あたりの利用数を監視するのが一般的である。これは、ある特定のクライアントから過剰にAPIを利用され、サービス全体の品質が低下してしまう事を防ぐためである。特に、サービスの利用量が課金される有償サービスでは、単位時間あたりの利用数に上限を設け、上限を超えたアクセスは拒否するよう構成される事が多い。これは、有償サービスは基本的に利用者との契約が行われる事で利用可能となり、有償サービスとしては契約した内容に従ったサービスを安定的に提供する責務を負うためである。例えば、SLA（Service Level Agreement）と呼ばれるサービスの品質を保証する制度がよく知られている。このSLAには、例えば、提供するサービスの最低速度や、利用不可能な時間の上限などが定義されている。ユーザーは、このSLAに定義されているサービスの品質の対価として利用料金を支払う。また、SLAには、定義されている品質が守れなかった場合の処置としてサービス提供者側の罰則や、ユーザーへの保証、例えば利用料金の減額、が定義されている。よって、有償サービスでは、SLAに定義された品質を守る事が非常に重要となっており、APIの利用量の上限設定および、上限を超えた場合にアクセスを拒否し、サービスの品質低下を防ぐことが重要となる。

"The OAuth 2.0 Authorization Framework"、[online] D. Hardt、2013年5月 ＜URL http://tools.ietf.org/html/rfc6749＞

特開2007-328417 号公報

あるテナント内に存在する複数クライアントである社内システムと、クラウドサービスとが連携する場合以下の構成が考えられる。なおテナントとは、リソースの提供先を区分する単位であり、ユーザーがクラウドを利用し、管理する単位である。たとえば複数のユーザーが同一のリソースサーバーを利用するケースを考えると、リソースサーバーで管理される各ユーザーの情報は互いに独立して分離されており、このような分離の単位をテナントと呼ぶ。すなわち、各々のクライアントはクラウドサービス（すなわちリソースサーバー）の特定のテナントのテナントクライアントとして動作し、特定のテナントで複数のクライアントが複数のサービスを利用するような構成が考えられる。例えば、あるテナントに、そのテナントの属するクラウドサービスに対するデータアップロードクライアントと帳票クライアントとプリントクライアントが存在するような構成である。API利用上限管理は、テナント単位でOAuthによる上限管理をすることが前提である。

しかしながら、上述のOAuthの構成、つまり、認可トークンを発行する認可サーバーと、APIを公開するリソースサーバーとで構成されている場合において、以下の課題がある。すなわち、特定のテナントにおいてAPI利用上限数が存在すると、クライアントがサービスAのAPIを大量に利用して上限に達すると、サービスBのAPIが呼べなくなる。つまり、あるサービスのAPIの利用状況により、他のサービスのAPIの利用可能数が影響を受ける、という課題がある。

本発明は上述の課題を鑑みてなされたものである。

上記課題を解決するために本発明は以下の構成を有する。

リソースに対するユーザーのアクセス権限を管理する管理手段と、
クライアントからの、リソースに対するユーザーの前記アクセス権限の委譲を要求する認可要求に応じて、該認可要求を検証し、検証が成功した場合には前記クライアントに対して認可トークンを発行する発行手段と、
リソース要求が前記認可トークンとともにあった場合、前記認可トークンを検証し、検証が成功した場合には検証応答を返す検証手段とを有し、
前記発行手段による前記認可要求の検証と、前記検証手段による前記認可トークンの検証とはいずれも、前記リソースに対するアクセス数が、設定されたアクセス上限数を超えたか否か判定し、超えない場合に当該認可トークンが正当であると判定することを含むことを特徴とする権限管理サーバー。

また他の観点によれば本発明は以下の構成を有する。

リソースに対するユーザーのアクセス権限を管理する管理手段と、
クライアントからの、リソースに対するユーザーの前記アクセス権限の委譲を要求する認可要求に応じて前記クライアントに対して認可トークンを発行する発行手段と、
リソース要求が前記認可トークンとともにあった場合、前記認可トークンを検証し、検証が成功した場合には検証応答を返す検証手段とを有し、
前記検証手段による前記認可トークンの検証では、要求されたリソースに対するアクセス数が、設定されたアクセス上限数を超えるか否か判定し、超えない場合に当該認可トークンが正当であると判定することを含むことを特徴とする権限管理サーバー。

本発明によれば、ひとつのテナントにおいて、個々のサービスのAPIの利用上限が、他のサービスのAPIの利用状況に影響を受けることがない。そのためサービスの利便性が増す、という効果がある。

また、複数サービスが連携して動作する場合、複数サービスからなる一連の機能に対してAPI利用上限を割り当てることで、エラーすることなく実施できるようになりサービスの利便性が増す、という効果がある。

システム構成図。 各装置のハードウェア構成図。 各装置のソフトウェアモジュール構成図。 認可サーバーで管理するクライアント関連テーブル構造を示す図。 認可サーバーで管理するクライアント関連テーブル構造を示す図。 認可サーバーで管理する認可トークン関連テーブル構造を示す図。 認可サーバーで管理する認可トークン関連テーブル構造を示す図。 ＡＰＩ上限数設定フローチャート。 ログイン、ＡＰＩ上限設定画面例を示す図。 クライアント登録からリソースアクセスまでのシーケンスを示す図。 Client Credentials Grantの場合の認可トークン発行シーケンスを示す図。 認可トークン検証処理フローチャート。 ＡＰＩカウント処理フローチャート。 第２の実施形態におけるＡＰＩ複数呼び出しシーケンスを示す図。 第２の実施形態におけるＡＰＩカウント処理フローチャート。 Authorization Code Grant の場合の認可トークン発行シーケンスを示す図。 Authorization Code Grantの場合の認可トークン発行シーケンスにおけるユーザーインターフェースを示す図。

以下、本発明を実施するための形態について図面を用いて説明する。
本実施の形態に係るAPI使用数上限管理機能を持つ権限委譲システムは、図１に示すような構成のネットワーク上に実現される。なお権限委譲システムはサーバーとクライアントとから構成されるシステムであり、認可済クライアントへのサービス提供システムである。また委譲される権限は、後述するリソースサーバーにより提供されるリソースへのアクセス権限である。なお、リソースを提供するシステムという観点から見れば、本実施形態のシステムをリソース提供システムということもできる。

＜権限委譲システムの構成＞
図１において、Wide Area Network（WAN）100はローカルアリアネットワーク等を相互接続するためにネットワークであり、例えばインターネットである。WAN100にはたとえばWorld Wide Web（WWW）システムが構築されている。Local Area Network（LAN）101は、例えばコンピュータ等のネットワーク構成要素を接続する。公衆回線102は、WAN100とコンピュータ等の構成要素を接続する公衆回線であり、WAN100がインターネットの場合、アクセス回線と呼ばれる。

認可サーバー200はOAuth 2.0を実現するためのサーバーであり、認可サーバーモジュールが設置されている。認可サーバーは、ユーザーやクライアントによるリソースへのアクセス権限を管理するサーバーであり、権限管理サーバーとも呼ぶ。リソースサーバー300には、ユーザープロビジョニングサービスや、有償データ変換サービス、無償データ変換サービスといったリソースサーバーモジュールが設置されている。なお１台のリソースサーバーに設置されるリソースサーバーモジュールは１つでもよく、複数でもよい。リソースサーバー300は、ユーザーごとのリソースを保存し、また管理しており、認可されたクライアントに対してサービスのAPIを介してリソースを提供する。リソースとは例えば記憶容量や処理能力、あるいは特定のアプリケーションなどを含む。端末400は、リソースサーバー300が提供するリソースにアクセスするアプリケーションプログラムを実行する装置であり、たとえばスマートフォンと呼ばれる携帯端末や、画像形成装置を含む。端末400には1つまたは複数のアプリケーションモジュールがインストールされている。ユーザーはそれらのアプリケーションモジュールを用いてリソースサーバーと通信する。データベースサーバー500は、認可サーバー200とLAN101を介して接続しており、認可サーバーモジュールが利用するデータが格納されている。また認可サーバー200、リソースサーバー300、端末400はそれぞれWAN100およびLAN101を介して接続されている。なお認可サーバー200、リソースサーバー300、端末400はそれぞれ個別のLAN上に構成されていてもよいし同一のLAN上に構成されていてもよい。また認可サーバー200、リソースサーバー300、ないしはデータベースサーバー500は同一のサーバー上に構成されていてもよい。

＜サーバー及び端末の構成＞
本実施の形態に係る権限委譲システムは、図2に示すような構成のサーバーおよび端末から成るシステム上に実現される。図2は、認可サーバー200、リソースサーバー300、端末400、およびデータベースサーバー500のハードウェア構成を示す。なお、図2に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の各サーバーおよび端末には一般的な情報処理装置のハードウェア構成を適用できる。

図２において、CPU201は、ROM203のプログラム用ROMに記憶された、或いはハードディスク（HD）等の外部メモリ211からRAM202にロードされたOSやアプリケーション等のプログラムを実行しシステムバス204に接続される各ブロックを制御する。ここでOSとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをOSと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。RAM202は、CPU201の主メモリ、ワークエリア等として機能する。キーボードコントローラ（KBC）205は、キーボード209や不図示のポインティングデバイスからのキー入力を制御する。CRTコントローラ（CRTC）206は、CRTディスプレイ210の表示を制御する。ディスクコントローラ（DKC）207は各種データを記憶するハードディスク（HD）等の外部メモリ211におけるデータアクセスを制御する。ネットワークコントローラ（NC）208はWAN100、LAN101、もしくは公衆回線102を介して接続された他の機器との通信制御処理を実行する。

尚、後述の全ての説明においては、特に断りのない限りサーバーにおける実行のハード上の主体はCPU201であり、ソフトウェア上の主体は外部メモリ211にインストールされたアプリケーションプログラムである。

＜ソフトウェアモジュール構成＞
図３は本実施の形態に係る、認可サーバー200、リソースサーバー300、端末400それぞれのモジュール構成を示す図である。なお認可サーバー200、リソースサーバー300、端末400は図２のものと同一である。

図３中、認可サーバー200は認可サーバーモジュール600、HTTPサーバーモジュール610を持つ。HTTPサーバーモジュール610はWAN100を介して接続する端末400のHTTPクライアント（例えばWebブラウザー）とのHTTP通信をサーバーとして行うためのモジュールである。また、SSL/TLSによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施形態では、後述するクライアント登録要求を受け付けるエンドポイントにて、要求元に対してX.509形式の証明書による認証を要求するよう構成されている。認可サーバーモジュール600はHTTPサーバーモジュール610上もしくは、連携して動作するWebアプリケーションであり、HTTPサーバーモジュール610を介して端末400からの要求を受け付け、処理し、応答する。その際、本実施形態では、HTTPサーバーモジュール610にて、クライアント登録要求を受け付け、要求元の認証に成功した場合、受信した証明書を認可サーバーモジュール600に通知するよう構成されている。

リソースサーバー300はリソースサーバーモジュール700、HTTPサーバーモジュール710を持つ。HTTPサーバーモジュール710はHTTPサーバーモジュール610と同様の機能を持つ。リソースサーバーモジュール700はHTTPサーバーモジュール710上もしくは、連携して動作するWebアプリケーションであり、HTTPサーバーモジュール710を介して端末400からの要求を受け付け、処理し、応答する。

端末400はアプリケーション管理モジュール810、Webブラウザー820を備え、一つないしは複数のアプリケーションモジュール800を持つ。アプリケーション管理モジュール810は、端末400上で動作する管理対象のアプリケーションモジュール800のライフサイクルを管理する機能を備えている。ライフサイクルとはアプリケーションのインストール、起動、停止、アンインストールを含むアプリケーションの状態を示すものとする。例えば、アプリケーション管理モジュール810としてはOSGi（Open Services Gateway initiative）アライアンスで規定されたOSGI（登録商標）が考えられる。アプリケーションモジュール800は端末400が提供するアプリケーション実行環境にて動作するアプリケーションである。このアプリケーションはアプリケーション管理モジュール810にてライフサイクル管理されている。ここでアプリケーションモジュール800は、端末400が予め持っていてもよく、またアプリケーション管理モジュール810を介して後からインストールされてもよい。さらに、端末400はWWWを利用するためのユーザーエージェントであるWebブラウザー820を備える。また、アプリケーションモジュール800は、自身を証明するためのX.509形式の証明書および、その秘密鍵を保持している。そして、後述のHTTPサーバーモジュール610との通信確立時に利用する事で、HTTPサーバーモジュール610によってアプリケーションモジュールからの要求である事を認証する事ができる。

＜データベースサーバーのデータテーブル＞
図４Ａ（ａ）、図４Ａ（ｂ）、図４Ｂ（ｃ）、図４Ｂ（ｄ）は認可サーバー200がLAN101を介して通信可能に構成されたデータベースサーバー500の外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー200の外部メモリに構成する事もできる。なお、以下の説明では図４Ａと図４Ｂとを区別せず、図４と称する。

図４（ａ）は証明書管理テーブル1200である。なお、本実施形態では、証明書としてX.509形式の証明書を利用する。証明書管理テーブル1200は、証明書のシリアル番号1201、証明書の発行者1202、主体者1203、開始日時1204、終了日時1205、および、後述する関連付けられるテナントのマスターユーザーの識別名であるDN（Distinguished Name）1206を有する。なおテナントとは、発明の概要で説明したように、リソースの提供先を区分する単位であり、ユーザーがクラウドを利用し、管理する単位である。

図４（ｂ）はクライアント管理テーブル1300である。クライアント管理テーブル1300はクライアントID1301、クライアントシークレット1302、テナントID1303、種別1304、DN1305、クライアント名1306、リダイレクトURL1307を有する。認可サーバー200は、認証を要求するクライアントなどから受信したIDと秘密情報との組を、クライアントID1301、シークレット1302の情報の組と照合してクライアントの正当性を検証し、正しければ認証情報を生成することで、各クライアントを認証する機能を備える。クライアント名1306、リダイレクトURL1307は後述のシーケンスで利用される値である。また、種別1304は、当該レコードのクライアントがテナントのマスターユーザーであるかどうか、を識別するためのデータが格納される。

図４（ｃ）はデフォルト権限管理テーブル1400である。デフォルト権限管理テーブル1400はテナントID1401、デフォルト権限ID1402とを有する。テナントID1401はクライアント管理テーブル1300のテナントID1303と互いに参照可能に構成されている。

図４（ｄ）はクライアント権限テーブル1500である。クライアント権限テーブル1500はクライアントID1501、権限ID1502とを有する。クライアントID1501はクライアント管理テーブル1300のクライアントID1301と互いに参照可能に構成されている。また、権限ID1502はデフォルト権限管理テーブル1400のデフォルト権限ID1402に設定されている権限IDが格納される。この権限ID1502への権限IDの登録については後述する。

＜認可サーバーのデータテーブル＞
図５Ａ（ａ）、図５Ａ（ｂ）、図５Ａ（ｃ）、図５Ａ（ｄ）、図５Ｂ（ｅ）は認可サーバー200がLAN101を介して通信可能に構成されたデータベースサーバー500の外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー200の外部メモリに構成する事もできる。なお、以下の説明では図５Ａと図５Ｂとを区別せず、図５と称する。また図５（ｆ）及び図５（ｇ）は本実施形態では必ずしも必要ではないため、第２実施形態で説明する。

図５（ａ）はスコープテーブル1600である。ここでスコープとは、OAuth 2.0による権限委譲プロトコル上にて、認可トークンを発行する際に、その認可トークンによって参照可能なリソースの範囲を表す。なお本実施形態においてスコープは、該スコープにより参照可能となるリソースに関するアクセスAPI、あるいは一連のアクセスAPI群に相当する。また、該スコープ、アクセスAPIは、本実施形態における各種サービスに相当する。該スコープにより規定されるアクセスAPIの例は後述する。

スコープテーブル1600はスコープID1601、スコープの種別1602、後述する画面例で利用するスコープの説明1603、権限ID1604を有する。ここで、スコープとは、後述するOAuthによる権限委譲フローにおいて、権限委譲先（クライアント）のアクセス範囲を示す。なお、ここで言うリソースオーナーはOAuth 2.0のフローにより対象が変わる。より具体的には、本実施形態においてはClient Credentials Grantによる認可トークン取得フローを実施する。Client Credentials Grantによる認可トークン取得フローの場合は、リソースオーナーはクライアント自身となる。スコープテーブル1600における権限ID1604は、当該スコープIDが示すスコープに対してアクセスするために必要な権限を示し、0個以上の権限IDを紐づける事ができる。ここで、複数の権限IDが紐づいている場合すなわち関連付けられている場合は、その複数の権限IDのうちの少なくとも１個の権限を有していれば、スコープが示すリソースへアクセスできる。また0個の権限IDが紐づいている場合、つまり、一つも権限IDと紐づいていない場合は、当該スコープに対して認証された主体であれば、だれでもアクセス可能であることを示す。スコープの種別1602は、そのスコープが単独のAPIに相当するか、一連のAPI群に相当するかを示している。一群のAPIとは、たとえばデータ作成、帳票処理、その印刷というように、一連のAPIを利用するアプリケーションがクライアントである場合に、それらをまとめたものである。本実施形態では単独であるか一群であるかによる処理の相違はないが、後述する第２の実施形態では、APIの利用上限数の扱いが相違する。

図５（ｂ）はユーザー管理テーブル1700である。ユーザー管理テーブル1700は、ユーザーID1701、パスワード1702、テナントID1703を有する。認可サーバー200は、ユーザーにより入力されたユーザーIDとパスワードとをユーザーID1701、パスワード1702の情報の組と照合してユーザーの正当性を検証し、正しければ認証情報を生成することで、各ユーザーを認証する機能を備える。

図５（ｃ）はユーザー権限テーブル1800である。ユーザー権限テーブル1800はユーザーID1801、権限ID1802とを有する。ユーザーID1801はユーザー管理テーブル1700のユーザーID1701と互いに参照可能に構成されている。なお、本実施形態では、ユーザー権限テーブル1800とクライアント権限テーブル1500とは互いに独立したテーブルとして記載しているが、一つのテーブルとして管理する事も可能である。

図５（ｄ）は認可トークン管理テーブル1900である。認可トークン管理テーブル1900は、認可トークンID1901、トークン種別1902、有効期限1903、スコープID1904、クライアントID1905とを有する。これら認可トークン管理テーブル1900の処理詳細については後述する。

図５（ｅ）はAPI使用数管理テーブル1950である。API使用数管理テーブル1950はテナントID1951、スコープID1952、サービス名1953、API使用上限数1954、API使用数1955、API ID List1956とを有する。テナントID1951は、ユーザー管理テーブル1700のテナントID1703と互いに参照可能に構成されている。スコープID1952は、スコープテーブル1600のスコープID1601と互いに参照可能に構成されている。サービス名1953は、スコープID1952に対応したサービスの名称を表す。本サービス名称は、リソースサーバー300のリソースサーバーモジュール700の提供するリソースへのアクセスによるサービスを表す。本実施形態においては、リソースサーバー300は、リソースサーバー300のリソースサービスモジュール700へのアクセスにより様々なサービスを提供する。例えば、後述するリソースサーバーモジュール700がAPIとして提供する帳票サービスなどである。API使用上限数1954は、前記リソースサーバーモジュール700がAPIとして提供する各種サービスについて、そのAPIの使用上限数を表す。この値は図６で説明する手順で設定される。本実施形態では、QoS（Quality of Service）の概念に基づき、テナント毎に一定期間内のAPIごとの使用数（API使用数と呼ぶ）に制限をかける。その目的は、テナントのサービス、すなわちAPI過剰利用によるリソースサーバーモジュール700の提供する各種サービスのクオリティ低下の防止である。本実施形態においては、一つのテナントに対するサービス提供に対し、APIの使用制限をかける。具体的には、テナントごとに、単位期間内の各種サービスを表すAPIの使用数に上限を設け制限する。単位期間は予め定めた時間的な長さであれば、例えば１日や１月などといった期間であればよい。単位期間は一律に定めてもよいし、テナントごとやサービスごとに定めてもよい。この単位期間はサービス提供の契約が継続する限り更新され、単位期間が経過時点から次の新たな単位期間が開始される。API使用数1955は、現在テナントID1951のテナントがスコープID1952で示されるAPIを何度使用したかを記録する。また新たな単位期間が開始される都度、例えば０で初期化される。例えば、単位期間の満了をタイマなどのより管理し、単位期間が満了したならAPI使用数1955を０で初期化して再び単位期間の経過を測定する。API ID List1956は、スコープID1952で示されるサービスを構成する具体的なAPIの名称のリストである。本実施形態においては、一つのサービスが一つのAPIで構成される場合と、一つのサービスが複数のAPIで構成される場合がある。しかしいずれも、一つのサービスは一つのスコープIDで表される。これらAPI使用数管理テーブル1950の処理詳細については後述する。

＜API上限数設定処理＞
図６、図７を用いて、認可サーバーモジュール600における、API上限数設定処理に関する本実施形態のフローチャートを説明する。本フローチャートは、マスターユーザーが端末400において認可サーバーモジュール600にAPI使用の上限数を設定する際のフローを示している。図６においては、ステップS6.1、S6.2、S6.5、S6.7は端末における入力とサーバーへの送信とを伴う処理であり、他のステップは認可サーバーモジュール600およびHTTPサーバーモジュール610を含む認可サーバー200による処理である。なお、ステップS6.3については、独立した認証サーバーがある場合には、認証手順はその認証サーバーで行われる。

S6.1にて、マスターユーザーは、端末400のWebブラウザー820を用いて、認可サーバー200のHTTPサーバーモジュール610に対してAPI上限数設定要求を行う。なお端末400のWebブラウザー820がAPI上限数設定要求を行うきっかけは次のようである。すなわち本実施形態では、端末400にてマスターユーザーによりWebブラウザー820が、API上限数設定画面を提供するURL（既知とする）に対してアクセスすることとして説明する。API上限数設定画面は、認可サーバー200の認可サーバーモジュール600に含まれる。

Webブラウザー820からのAPI上限数設定要求を受け付けたHTTPサーバーモジュール610は認可要求を受ける。そして、HTTPサーバーモジュール610はS6.2 にて、ユーザー認証をするためにログイン画面をWebブラウザー820に応答する。ここで図７（ａ）はHTTPサーバーモジュール820が応答するログイン画面例である。図７（ａ）は、ユーザーIDを入力するユーザーID入力欄2001、パスワードを入力するパスワード入力欄2002、およびログイン操作を実行するためのログインボタン2003から成る。

S6.2にてユーザーがWebブラウザー820に表示された図７（ａ）に必要な情報すなわちユーザーIDとパスワードとを入力し、ログインボタン2003を押下すると、Webブラウザー820は入力された情報をHTTPサーバーモジュール610に送信する。S6.3にてHTTPサーバーモジュール610はWebブラウザー820からユーザーIDとパスワードとを取得し、ユーザー管理テーブル1700のユーザーID1701、パスワード1702の情報の組と比較し一致するものがあるかを検証する事でユーザーを認証する。HTTPサーバーモジュール610は、ユーザー認証に失敗、つまり、ユーザー管理テーブル1700に取得した情報が登録されていない場合は、S6.9にて不図示の認証エラー画面をWebブラウザー820に応答する。なおユーザーを認証する方法として他の手段、例えば、X.509の証明書や、パスワードを複数回入力する多段階認証等、別の方法を用いることも可能であり、本方法に限定するものではない。

S6.3にてログインに成功した場合、S6.4にて、認可サーバー200の認可サーバーモジュール600は、HTTPサーバーモジュール610を通して、図７（ｂ）に示すサービス一覧画面2400を表示する。サービス一覧画面2400は、テナント・ユーザー表示領域2401に先のログインS6.2に成功したユーザーのテナントIDとユーザーIDを表示する入力画面である。また先のログインS6.2に成功したユーザーが利用可能なサービス一覧をAPI上限数一覧表示領域2402に表示する。API上限数一覧表示領域2402は、サービス名2403とAPI上限数2404とにより構成される。このうちサービス名2403は、現在前記テナント・ユーザー情報表示領域2401に表示されているログインユーザーの所属する、テナントIDで示されるテナントの利用可能なサービス名の一覧を表示する。具体的には、ログインしているユーザーのテナントIDで、API使用数管理テーブル1950を検索し、一致するテナントIDに対応したサービス名1953を全て表示する。

S6.5にてログインユーザーは前記Webブラウザー802によりAPI上限数を設定するサービス名2403を選択し、サービス名に対して、ユーザーインターフェース上では同じ行のAPI上限数2404欄にAPI上限数を入力する。本API上限数の設定値の範囲については、認可サーバー200のCPU、メモリーなどの計算リソースの制限、サービスを提供するテナント数などにより規定の最大値が存在し、前記ユーザーは設定値の最大値を超えない範囲で上限数を設定可能である。サービス名2403で示される各サービスに対してAPI上限数2404を設定したら、OKボタン2405を押下して各サービスのAPI上限数の設定を行う。

S6.6にて、認可サーバー200の認可サーバーモジュール600は、ユーザーにより設定されたAPI上限数が設定値の最大値を超えていないか判定する。もし設定されたAPI上限値が設定値の最大数を超えないならば、S6.7にて、認可サーバー200の認可サーバーモジュール600は設定値を表示して処理を終了する。もし前記設定値が前記設定値の最大数を超えていれば、設定値最大数超過のエラー（図示せず）を表示して処理を終える。

なお本実施形態では、あるテナントについて、個々のサービス（すなわちAPI）に対して設定された上限数の総和が、そのテナントの最大数を超えることを許容しないものとする。そこでたとえば、API上限数2404の初期値としては、最大数を各APIに等分した値をデフォルトとして設定し、表示する。そしてあるサービスに対してAPI上限数の設定値が入力されたなら、その設定値とデフォルト値との差分を他のサービスに対して自動的に割り当てて設定し、再表示する。この各サービスに対する割り当ては、たとえばほぼ均等とする。このようにすることで、個々のサービスの使用上限数は、他のサービスの使用状況の影響を受けることがない。なお、各テナントについて、個々のサービス（すなわちAPI）に対して設定された上限数の総和が、そのテナントの最大数を超えることを許容してもよい。ただし、各サービスの上限数のそれぞれがいずれも最大数に設定されると、結果として従来技術と同様の課題が生じることとなる。それを避けるために、サービスごとに設定可能なAPI上限数の最大値（サービスごとの最大数と呼ぶ）を設けてもよいし、あるいは、各テナントでサービスごとに設定可能なAPI上限数の総和が、テナントの最大数よりも、一定の割合あるいは一定の値だけ大きくなることを許容するよう構成してもよい。

以上の手順により、単位期間内のサービスごとのAPI使用数の上限が設定される。

＜リソース取得シーケンス＞
図８を用いて、アプリケーションモジュール800における、クライアントの登録からリソース取得に関する本実施形態のシーケンスを説明する。本シーケンスはユーザーが端末400において、認可サーバーモジュール600に未登録であるアプリケーションモジュール800を利用する際のフローを示している。例えば、端末400のアプリケーションモジュール800においてクライアント登録は最初の一度のみとし、移行は認可トークン取得のシーケンスから実施するよう構成する事もできる。

まず、図８を用いてアプリケーションモジュール800におけるクライアント登録のシーケンスを説明する。S1.1にて、端末400のアプリケーションモジュール800は、認可サーバー200のHTTPサーバーモジュール610に対してクライアント登録要求を行う。なお、アプリケーションモジュール800がクライアント登録要求を行うきっかけとして、本実施例では、端末400にて、ユーザーが当該アプリケーションモジュール800をインストールし、初めて起動したタイミングとして説明する。なお、他のきっかけとして、ユーザーがアプリケーションモジュール800の機能を選択し、リソースサーバー300へのリソース要求が発生するタイミングが考えられる。また、アプリケーションモジュール800が明示的に開始する操作を備え、ユーザーが端末400にて当該操作をしたタイミングが考えられる。なお、クライアント登録要求は、クライアント名およびAuthorization Code Grantを利用するためのリダイレクトURLを含む。また、その他の情報として、クライアントを説明するための文字列や、説明が記載されるサイトのURL、等の付属情報を含むよう構成する事もできる。Authorization Code Grantとは、連携するアプリケーション（クライアント）が、サービスが公開するAPIを利用するために、そのサービスを利用する権限を有するユーザーから権限の委譲をうけるための手続きであり、OAuth 2.0に定められている。Authorization Code Grantの手順については図１４等を参照して後述する。

アプリケーションモジュール800からのクライアント登録要求を受け付けたHTTPサーバーモジュール610はSSL/TLS通信のネゴシエーションを開始する。その際、デバイス登録要求に関してはクライアント認証を要求するよう設定されているため、アプリケーションモジュール800に対して証明書を要求する。S1.2にてHTTPサーバーモジュール610は不図示の証明書ストアにて設定されている証明書を用いて、アプリケーションモジュール800から取得した証明書を検証し、アプリケーションモジュール800をデバイス登録の要求元として認証する。なお、本実施の形態では、クライアント登録要求の要求元の認証方法として、SSL/TSLの証明書による認証方式にて説明したが、例えば、Basic認証やDigest認証といった、IDおよびパスワードを用いる方式等が考えられる。さらには、これら主体を認証する手段を経て、認証された主体に対してクライアントを登録するための認可トークンを発行する手段を設け、当該認可トークンを検証する事によってクライアント登録を受け付けるよう構成する事も可能である。ここで認証に失敗した場合、HTTPサーバーモジュール610はアプリケーションモジュール800に対してエラーを応答する。

S1.3にて、HTTPサーバーモジュール610は、アプリケーションモジュール800を認証した後に、認可サーバーモジュール600に対して、アプリケーションモジュール800から受信したクライアント登録要求を通知する。その際、認証したアプリケーションモジュール800を識別するための情報も通知する。より具体的には取得した証明書の情報を通知する。

S1.4にて認可サーバーモジュール600は、HTTPサーバーモジュール610より通知された証明書の情報を取得する。次に、S1.5 にて、認可サーバーモジュール600は、取得した証明書のシリアル番号、発行者、主体者をキーとして、証明書管理テーブル1200の情報を特定し、テナントマスターDN1206の情報を取得する。その際、開始日時1204、終了日時1205を有効期間として、検証するよう構成する事もできる。ここで、証明書管理テーブル1200にレコードが無い場合や、有効期間の検証に失敗した場合、認可サーバーモジュール600はHTTPサーバーモジュール610を介してアプリケーションモジュール800にエラーを応答する。

続いて、S1.6にて認可サーバーモジュール600は、取得したテナントマスターDN206をキーとして、クライアント管理テーブル1300からテナントID1303を取得する。そして、取得したテナントID1303をキーとしてデフォルト権限管理テーブル1400から、デフォルト権限ID1402を取得する。取得されるデフォルト権限ID402は複数である事があり得る。また、デフォルト権限管理テーブル1400に一つも登録されていない場合は、後述のクライアント権限テーブル1500への登録は行わない。

そして、S1.7にて認可サーバーモジュール600は、取得した情報を元にクライアント管理テーブル1300にクライアントを新規登録する。より具体的には、クライアントID、シークレットを発行し、DNを作成し、それぞれ1301、1302、1305に格納する。そして、取得したクライアント名、リダイレクトURL、および、テナントマスターDN206により特定されたテナントIDを、それぞれ1306、1307および1303に格納する。その際、種別1304は一般とする。そして、S1.8にて認可サーバーモジュール600は、発行し、登録したクライアントIDとデフォルト権限管理テーブル1400から取得したデフォルト権限IDとを、クライアント権限テーブル1500に格納する。この際、複数のデフォルト権限IDが取得されている場合は、複数のデータを格納する事になる。

登録が完了した後に、S1.9にて認可サーバーモジュール600は、発行したクライアントIDとシークレットを、HTTPサーバーモジュール610を介してアプリケーションモジュール800に応答する。

以上がクライアント登録の説明である。これらシーケンスによって、クライアントをオンライン登録する際に、アプリケーションモジュール800を識別し、適切な権限を付与する事が可能となる。

次に、図８を用いてアプリケーションモジュール800における、認可トークンの取得から認可トークンを利用してのリソース取得までを説明する。なお、図中“Ref”は参照を示しており、別図で説明する。また、“Alt”は分岐を示しており、事前のシーケンスの結果による分岐処理を示す。

S1.10にて、アプリケーションモジュール800は認可トークン取得を開始する。なお、認可トークン取得を開始するきっかけとしては、ユーザーが端末400を用いてアプリケーションモジュール800を開始した場合が考えられる。また、アプリケーションモジュール800が明示的に開始する操作を備え、ユーザーが端末400にて当該操作をしたタイミングが考えられる。ここで、認可トークンの発行処理はOAuth 2.0に定義されているフローに従って実施される。なお本実施形態では、フローとしてAuthorization Code Grant、およびClient Credentials Grantのケースを説明する。Authorization Code Grant による認可トークン発行処理については図１４、図１５（ａ）、図１５（ｂ）および図１５（ｃ）を用いて後述する。また、Client Credentials Grant による認可トークン発行処理については図９を用いて後述する。本実施形態の認可トークンの発行処理は、これらのいずれかを用いて行われる。S1.11にて、アプリケーションモジュール800は、各認可トークンの取得フローによって認可トークンを取得する。S1.12にて、アプリケーションモジュール800は取得した認可トークンを用いてリソースサーバーモジュール700にリソース要求を行う。リソース要求は、リソースに対応したAPIを読み出すことで行う。ここで、リソースサーバーモジュール700は図８にて不図示のHTTPサーバーモジュール710を介して要求の受信および、応答の送信を行う。

本実施形態においては、リソース要求はREST API呼び出しによるサービス要求に相当する。また、本実施形態のすべての API 操作をSSL上で実行するようにし、X.509証明書を用いて相互認証されるように構成することも可能である。

アプリケーションモジュール800は、取得した認可トークンをHTTPヘッダーの「Authorization: Bearer」に含めることで、リソースサーバーモジュール700の提供する各種APIにアクセスすることが出来る。例えば帳票作成APIを呼ぶ際には、以下のようになる。
POST /oauth2/v1/form/create HTTP/1.1
Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw
Host: example.com
ここで、「7Fjfp0ZBr1KtDRbnfVdmIw」が認可トークンである。

例えばcsvファイルをアップロードしてデータセットを作成するAPIを呼ぶ際には、REST APIのヘッダーは以下のようになる。
POST /oauth2/v1/dataset/upload HTTP/1.1
Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw
Host: example.com。

実際にアップロードされるCSVファイルについては、本APIは、ユーザーがWebブラウザーのフォーム入力で送信ボタンを押したときのふるまいを模倣する。すなわちRFC2388に従いContent-Type： multipart/form-data としてPOSTデータを送信する。また例えば作成したデータを印刷するAPIを呼ぶ際には、以下のようになる。
GET /oauth2/v1/print?printerid=xxxx&jobid=yyyy HTTP/1.1
Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw
Host: example.com。

S1.13にてリソースサーバーモジュール700は認可トークン検証要求を認可サーバーモジュール600に行う。ここで、本実施形態では、リソースサーバーモジュール700および認可サーバーモジュール600間の通信はLAN101を介して行うよう説明するが、WAN100を介して行うよう構成する事も可能である。その際は、互いのHTTPサーバーモジュール610および、710を介して通信する事になる。認可サーバーモジュール600にて、認可トークン検証要求を受け付けた際に行われる認可トークン検証処理については図１０を用いて後述する。認可トークンを検証した結果、当該認可トークンが正当であると検証された場合、認証情報の入力を要求することなくリソースに対するアクセスを許可する。

S1.14にてリソースサーバーモジュール700は、認可サーバーモジュール600より認可トークン検証応答を受信する。ここで、検証結果が有効（Valid）である場合は、S1.15にてリソース取得処理を行う。そして、S1.16にてアプリケーションモジュール800に対して取得したリソースを応答し、処理を終了する。また、認可トークン検証応答の結果が無効（Invalid）あるいはAPI上限管理エラーである場合は、S1.17にてアプリケーションモジュール800に対してエラー応答を行い、処理を終了する。

以上が、アプリケーションモジュール800における、認可トークンの取得から認可トークンを利用してのリソース取得までの説明である。

＜Authorization Code Grantによる認可トークン発行処理＞
次に、OAuth 2.0におけるAuthorization Code Grantの場合の認可トークン発行処理について図１４および、図１５（ａ）、図１５（ｂ）、図１５（ｃ）を用いて説明する。図１４のS2.1において、アプリケーションモジュール800はWebブラウザー820を介してHTTPサーバーモジュール610へ認可要求を行う。なお、HTTPサーバーモジュール610において、認可要求を受け付けるエンドポイントは、クライアント認証ではなくユーザー認証を要求するよう設定されている。なお、認可要求には、少なくとも、クライアント登録の結果取得したクライアントIDおよび登録したリダイレクトURL、そして取得する予定のリソース範囲を示す少なくとも一つのオーナースコープを含む、一つないしは複数のスコープIDを含む。必要なスコープIDはアプリケーションモジュール800に予め知らされているものとする。

S2.2においてHTTPサーバーモジュール610は認可要求を受ける。そして、HTTPサーバーモジュール610はS2.3 にて、ユーザー認証をするためにログイン画面をWebブラウザー820に応答する。ここで図１５（ａ）はHTTPサーバーモジュール820が応答するログイン画面例である。図１５（ａ）は、ユーザーIDを入力するユーザーID入力欄2001、パスワードを入力するパスワード入力欄2002、およびログイン操作を実行するためのログインボタン2003から成る。

S2.4にてユーザーはWebブラウザー820に表示された図１５（ａ）に必要な情報を入力し、ログインボタン2003を押下する。S2.5にてWebブラウザー820は入力された情報をHTTPサーバーモジュール610に送信する。S2.6にてHTTPサーバーモジュール610はWebブラウザー８２０からユーザーID、パスワードを取得し、ユーザー管理テーブル1700のユーザーID1701、パスワード1702の情報の組と比較し、一致するものがあるかを検証する事でユーザーを認証する。一致するものがあれば認証は成功である。HTTPサーバーモジュール610は、ユーザー認証に失敗、つまり、ユーザー管理テーブル1700に取得した情報が登録されていない場合は、不図示の認証エラー画面をWebブラウザー820に応答する。ユーザー認証に成功した場合、HTTPサーバーモジュール610は認証トークンを生成する。この認証トークンはHTTPサーバーモジュール610の不揮発メモリ上に、ユーザーIDと対応付けて保存される。そして、S2.7にてHTTPサーバーモジュール610は、アプリケーションモジュール800から受信した認可要求を認可サーバーモジュール600に通知する。その際、生成した認証トークンを付与して通知する。なお、本実施形態ではパスワード認証を行っているが、ユーザーを認証する手段として他の方法、例えば、X.509の証明書や、パスワードを複数回入力する多段階認証等、別の方法を構成する事も可能であり、本方法に限定するものではない。

S2.8にて認可サーバーモジュール600は受信した認可要求のうち、クライアントIDとリダイレクトURLの組が正しいか検証する。より具体的には、クライアント管理テーブル1300に登録されているクライアントID1301とリダイレクトURL1307の組に一致するものが登録されているか検証する。不一致の場合、認可サーバーモジュール600は不図示のエラー画面を、HTTPサーバーモジュール610を介してWebブラウザー820に応答する。一致した場合、認可サーバーモジュール600はS2.9にてユーザー情報を取得する。より具体的には、HTTPサーバーモジュール610から通知された認証トークンを用いて、HTTPサーバーモジュール610から、紐づくユーザーIDを取得する。たとえば、HTTPサーバーモジュール610は認可トークンとともにユーザーIDを含むログイン情報も受信しているので、認可トークンに関連付けられたユーザーIDをHTTPサーバーモジュール610から取得する。そして、そのユーザーIDを元にユーザー権限テーブル1800から権限ID1802を取得する。この時、取得される権限ID1802は１つとは限らず、0個である場合や複数個である場合もある。なお、本実施形態では、ユーザー情報の取得を、認証トークンを元にユーザーIDを取得し、認可サーバーモジュール600がユーザー情報を取得する方法で説明したが、この方法に限定するわけではない。例えば、HTTPサーバーモジュール610からこれら必要なユーザー情報が通知されるよう構成する事も可能であるし、また、HTTPサーバーモジュール610へ認証トークンを渡す事で、必要なユーザー情報が取得されるよう構成する事もできる。

S2.10にて認可サーバーモジュール600は、認可要求に含まれるスコープのスコープIDをキーとしてスコープテーブル1600より各スコープの権限ID1604を取得する。そして、S2.11にて認可サーバーモジュール600は、取得したスコープごとの権限ID1604が、ユーザー権限テーブル1800から取得した、S2.9で取得したユーザーIDに対応する権限ID1802に含まれているかを検証する。ユーザーが要求した認可要求に含まれたスコープに属する全ての権限が当該ユーザーに与えられている場合にはその認可要求は承認され、そうでなければ拒絶される。具体的には、スコープテーブル1600から、認可要求に含まれたスコープIDに紐づく権限IDを取得し、ユーザー権限テーブル1800の当該ユーザーに紐づけて取得した権限IDが設定されている場合は、当該認可要求は有効（Valid）と判定される。ここで、スコープテーブル1600に、スコープIDに紐づく権限ID1604が複数ある場合は、その複数の権限ID1604のうち少なくとも一つの権限IDが当該ユーザーに設定されている場合は当該権限に関する認可要求は有効（Valid）とみなす。あるいは要求したスコープに紐づけられた全ての権限IDが当該ユーザーに設定されている場合に初めて当該権限に関する認可要求は有効（Valid）とみなすようにしてもよい。また、スコープIDに紐づく権限IDが当該ユーザーに対して設定されていない場合は、ユーザーの権限に関係なく当該権限に関する認可要求は無効（Invalid）とみなす。認可要求に含まれるスコープの内、少なくとも一つの権限IDにて無効（Invalid）となった場合に、認可サーバーモジュール600はS2.28にて、Webブラウザー820に権限エラーを応答する。そして、S2.29にて、Webブラウザー820はアプリケーションモジュール800に権限エラーを応答する。より具体的には、認可要求時に取得したリダイレクトURLに対してWebブラウザー820をリダイレクトするようWebブラウザー820にリダイレクト応答する。S2.30にてアプリケーションモジュール800は図１５（ｃ）に例示した権限エラー画面をWebブラウザー820に応答し、処理を終了する。

認可要求に含まれる全てのスコープに対して有効（Valid）となった場合、S2.12にて認可サーバーモジュール600は、Webブラウザー820に対して認可確認画面を応答する。図１５（ｂ）は応答される認可確認画面の例である。認可確認画面2100は、認可要求に含まれるクライアントIDをキーとしてクライアント管理テーブル1300から取得したクライアント名1306を表示する領域であるアクセス元表示領域2101を備える。また、認可要求に含まれるスコープIDをキーとしてスコープテーブル1600から取得したスコープの説明1603を表示する領域であるスコープ表示領域2102を備える。さらに、認可確認画面2100は、ユーザーが上記情報の内容について認可操作を実行する許可ボタン2103、および拒否を実行する拒否ボタン2104を備える。ここで、ユーザーが拒否ボタン2104を押下した場合は、認可サーバーモジュール600は、オーナー権限検証の結果が無効（Invalid）だった場合と同様にS2.28にてアプリケーションモジュール800に権限エラーを応答する。なお、これら権限エラー応答については、応答を受け付けるアプリケーションモジュール800にて表示する画面の構成、もしくは文言を変更するために、エラー応答の内容を区別可能に構成する事も可能である。

S2.13にてユーザーが認可確認画面2100にて許可ボタン2103を押下、つまり認可操作を行った場合、Webブラウザー820を介し、S2.14にて認可サーバーモジュール600に認可した事が通知される。

S2.15にて認可サーバーモジュール600は、認可コードを発行する。より具体的には、認可トークンIDを発行し、認可要求に含まれるスコープID、クライアントID、認証し、許可を得たユーザーのユーザーIDをオーナーID1906として、認可トークン管理テーブル1900に登録する。その際、トークン種別1902は認可コードとし、有効期限1903に当該認可コードが有効である日時を登録する。そして、S2.16、S2.17にて認可サーバーモジュール600は発行した認可コードの認可トークンIDを含む認可応答を、Webブラウザー820を介し、アプリケーションモジュール800に送信する。より具体的には、認可要求時に取得したリダイレクトURLに対してWebブラウザー820をリダイレクトするようWebブラウザー820にリダイレクト応答する。

S2.18にてアプリケーションモジュール800は、認可サーバーモジュール600に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード、クライアントID、シークレット、および認可要求時に送信したリダイレクトURLを含が含まれる。

S2.19にて認可サーバーモジュール600は取得したクライアントID、シークレットの組をもってクライアントを認証する。より具体的には、クライアント管理テーブル1300のクライアントID1301、シークレット1302の組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合はアプリケーションモジュール800に認証エラーを応答する。クライアント認証に成功した場合、S2.20にて認可サーバーモジュール600は、取得した認可コードを検証する。認可コードの検証としては、取得した認可コードの認可トークンIDが認可トークン管理テーブル1900に登録されているか、登録されている場合は、有効期限1903の範囲内かを検証する。登録されていない場合には、S2.26で権限エラーが返される。さらには、認可トークン要求にて取得したリダイレクトURLが、認可トークンIDに紐づくクライアントID1905をキーとしてクライアント管理テーブル1300に登録されているリダイレクトURL1307と一致するかを検証する。認可コード検証の結果が無効であった場合、認可サーバーモジュール600はアプリケーションモジュール800にトークン不正エラーを応答する。そして、認可コード検証の結果が有効であった場合、S2.21にて認可サーバーモジュール600はクライアント情報を取得する。より具体的には、認証したクライアントIDをキーにクライアント権限テーブル1500から権限ID1502を取得する。この時、取得される権限ID1502は、0個である場合や複数個である場合がある。

S2.22にて認可サーバーモジュール600は、認可トークン管理テーブル1900より、取得した認可コードの認可トークンIDをキーにスコープID1904を取得する。続いて、取得したスコープの、スコープIDをキーとしてスコープテーブル1600より各スコープの権限ID1604を取得する。この時、認可トークン管理テーブル1900より取得したスコープIDにスコープが含まれていない場合、クライアント権限の検証の結果を有効（Valid）とする。ただし、このケースを例外扱いせず、ステップS2.23において原則通りに処理してもよい。その場合にはこのケースは無効（Invalid）と判定されることになろう。

そして、S2.23にて認可サーバーモジュール600は、S2.22で取得したスコープごとの権限ID1604が、クライアント権限テーブル1500から取得した権限ID1502に含まれているかを検証する。クライアントが要求した認可トークンのスコープに属する全ての権限が、当該クライアントに与えられている場合にはその認可要求は承認され、そうでなければ拒絶される。したがって、具体的には、スコープテーブル1600から、要求された認可トークンに紐づけられたスコープIDに対応する権限IDを取得し、そこにクライアント権限テーブル1500の当該クライアントに紐づけて取得した権限IDが設定されている場合は、当該認可要求は有効（Valid）と判定される。ここで、スコープテーブル1600にてスコープIDに紐づく権限ID1604が複数ある場合は、その複数の権限ID1604のうち少なくとも一つの権限IDがクライアントに設定されている場合は有効（Valid）とみなす。あるいは要求したスコープに紐づけられた全ての権限IDが当該クライアントに設定されている場合に初めて当該権限に関する認可要求は有効（Valid）とみなすようにしてもよい。また、スコープIDに紐づく権限IDが設定されていない場合は、クライアントの権限に関係なく無効（Invalid）とみなす。認可コードに紐づくスコープの内、少なくとも一つの権限IDの検証にて無効（Invalid）となった場合に、認可サーバーモジュール600はS2.26にてアプリケーションモジュール800に権限エラーを応答する。そして、S2.27にてアプリケーションモジュール800は図１５（ｃ）に例示した権限エラー画面をWebブラウザー820に応答し、処理を終了する。

認可コードに紐づく全てのスコープに対して有効（Valid）となった場合、認可サーバーモジュール600はS2.30にてAPIカウント処理を実行する。この際、前記スコープ、認証したクライアントIDを用いて処理を実行する。APIカウント処理は、利用するAPIの使用数が上限値を超えないか判定する処理である。APIカウント処理の詳細については後述する図１１の手順で行われる。もしAPIカウント処理に失敗した場合、認可サーバーモジュール600は、アプリケーションモジュール800にエラーを応答して処理を終了する。

APIカウント処理が成功した場合、S2.24にて認可サーバーモジュール600は認可トークンを発行する。より具体的には、認可トークンIDを発行し、認可コードに紐づくスコープID、オーナーID、認証したクライアントIDを認可トークン管理テーブル1900に登録する。その際、トークン種別1902は認可トークンとし、有効期限1903に当該認可トークンが有効である日時を登録する。そして、S2.24にて認可サーバーモジュール600は発行した認可トークンの認可トークンIDをアプリケーションモジュール800に応答し、処理を終了する。その際、認可トークンの有効期限を応答するよう構成する事もできる。本実施形態では、認可トークンを更新するためのリフレッシュトークンを発行しない例で説明したが、認可トークン管理テーブル1900にて、リフレッシュトークンのID、および有効期限を管理するよう構成する事もできる。その際、認可トークン発行時に同時にリフレッシュトークンも発行し、認可トークンの応答時に発行したリフレッシュトークンのIDも含めて応答するよう構成する事もできる。

＜Client Credentials Grantによる認可トークン発行処理＞
次に、OAuth 2.0におけるClient Credentials Grantの場合の認可トークン発行処理について図９を用いて説明する。

S3.1にてアプリケーションモジュール800は、認可サーバーモジュール600に対して認可トークンを要求する。この認可トークン要求には、少なくとも、クライアントID、シークレット、取得する予定のリソース範囲を示す少なくとも一つのスコープを含む、一つないしは複数のスコープIDを含む。

本実施形態においてスコープは、該スコープにより参照可能となるリソースに関するアクセスAPI、あるいは一連のアクセスAPI群に相当する。また、該スコープ、アクセスAPIは、本実施形態における各種サービスに相当する。一つのスコープIDを含む認可トークンは一つのリソース、一つのサービスに対するAPI呼び出しの際に必要となる。また複数のスコープIDを含む認可トークンは、複数サービスを連携した一連のサービスに対するAPI呼び出しの際に必要となる。

S3.2にて認可サーバーモジュール600は取得したクライアントIDとシークレットの組をもってクライアントを認証する。より具体的には、クライアント管理テーブル1300のクライアントID1301とシークレット1302の組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合はアプリケーションモジュール800に認証エラーを応答する。クライアント認証に成功した場合、S3.3にて認可サーバーモジュール600はクライアント情報を取得する。より具体的には、認証したクライアントIDをキーにクライアント権限テーブル1500から権限ID1502を取得する。この時、取得される権限ID1502は、0個である場合や複数個である場合がある。

S3.4にて認可サーバーモジュール600は、認可トークン要求に含まれるスコープのスコープIDをキーとして、スコープテーブル1600より各スコープの権限ID1604を取得する。この時、認可トークン要求に含まれるスコープIDにスコープが含まれていない場合、クライアント権限の検証の結果を有効（Valid）とする。ただし、このケースを例外扱いせず、ステップS3.5において原則通りに処理してもよい。その場合にはこのケースは無効（Invalid）と判定されることになろう。

そして、S3.5にて認可サーバーモジュール600は、取得したスコープごとの権限ID1604が、クライアント権限テーブル1500から取得した権限ID1502に含まれているかを検証する。この時、スコープテーブル1600にてスコープIDに紐づく権限ID1604が複数ある場合は、その複数の権限ID1604のうち少なくとも一つの権限IDがクライアントに設定されている場合は有効（Valid）とみなす。また、スコープIDに紐づく権限IDが設定されていない場合は、クライアントの権限に関係なく無効（Invalid）とみなす。

これら検証の結果、認可トークン要求に含まれるスコープの内、少なくとも一つ以上の権限IDにて無効（Invalid）となった場合S3.10に移行する。S3.10にて認可サーバーモジュール600はアプリケーションモジュール800に権限エラーを応答し処理を終了する。

そして、認可トークン要求に含まれる全てのスコープの検証にて有効（Valid）となった場合、認可サーバーモジュール600はS3.6にてAPIカウント処理を実行する。この際、前記スコープ、認証したクライアントIDを用いて処理を実行する。APIカウント処理の詳細については後述する。もしAPIカウント処理に失敗した場合、認可サーバーモジュール600は、アプリケーションモジュール800にエラーを応答して処理を終了する。

前記APIカウント処理が成功した場合、S3.8にて認可サーバーモジュール600は認可トークンを発行する。より具体的には、認可トークンIDを発行し、認可トークン要求に含まれるスコープID、認証したクライアントのクライアントIDおよび、当該クライアントIDをオーナーIDとして、認可トークン管理テーブル1900に登録する。その際、トークン種別1902は認可トークンとし、有効期限1903に当該認可コードが有効である日時を登録する。そして、S3.9にて認可サーバーモジュール600は発行した認可トークンの認可トークンIDをアプリケーションモジュール800に応答し、処理を終了する。その際、認可トークンの有効期限を応答するよう構成する事もできる。

＜認可トークン検証処理＞
次に、認可トークン検証処理について図１０を用いて説明する。図１０は認可サーバーモジュール600にて実施される認可トークン検証処理のフローである。図８のフローにおいて、アプリケーションモジュール800は、S1.11にて認可トークンを取得後にS1.12にてリソース要求（API呼び出し）を行う。その要求に応じてリソースサーバーモジュール700から認可サーバーモジュール600に検証要求を発行すると、認可サーバーモジュール600が認可トークンの検証処理を行い、さらにAPIカウント処理を行ってAPI使用数上限管理を行う。このAPIカウント処理を含む検証処理について以下で説明する。

ステップS4.1にて、認可サーバーモジュール600は、リソースサーバーモジュール700より認可トークン検証依頼を受ける。この認可トークン検証依頼には、検証対象となる認可トークンの認可トークンIDおよび、少なくとも一つ以上のスコープIDが含まれている。ステップS4.2にて、認可サーバーモジュール600は、これら認可トークンIDおよび、スコープIDを取得する。次に、ステップS4.3にて認可サーバーモジュール600は、取得した認可トークンIDを元に、認可トークンの情報を取得する。より具体的には、認可トークンID、およびトークン種別：認可トークンをキーとして認可トークン管理テーブル1900から有効期限1903を取得する。そして、ステップS4.4にて、認可トークンが存在しているか、つまり、認可トークン管理テーブル1900に存在するかの検証、および、有効期限内であるかを検証する。検証の結果、存在しない場合、もしくは存在するが有効期限内でない場合は認可トークンが無効と判断し、ステップS4.5にてトークン不正エラーを返却し、処理を終了する。検証の結果、認可トークンが存在し、かつ有効期限内である場合は処理を継続する。

ステップS4.6にて認可サーバーモジュール600は、検証依頼に含まれるスコープの情報を取得する。より具体的には、スコープIDをキーにスコープテーブル1600より各スコープの種別1602、権限ID1604を取得する。

次にステップS4.11にて認可サーバーモジュール600は、S4.6にて取得した一つないしは複数のスコープの種別1602に少なくとも一つ以上、クライアントスコープが含まれているか判定する。結果、一つもない場合はステップS4.15に移行する。一つ以上含まれている場合、ステップS4.12にて認可サーバーモジュール600はクライアント情報を取得する。より具体的には、認可トークンIDをキーに認可トークン管理テーブル1900からクライアントID1907を取得し、取得したクライアントIDをキーにクライアント権限テーブル1500から権限ID1502を取得する。この時、取得される権限ID1502は0個である場合や複数個である場合がある。

次に、ステップS4.13にて認可サーバーモジュール600は、ステップS4.6で取得したクライアントスコープに対する権限検証を行う。より具体的には、S4.6で取得したクライアントスコープIDをキーとしてスコープテーブル1600より各クライアントスコープの権限ID1604を取得する。そして、取得したクライアントスコープごとの権限ID1604が、ステップS4.12にて取得した権限ID1502に含まれているかを検証する。検証対象の認可トークンのクライアントに関連付けられたスコープに属する全ての権限が当該認可トークンに与えられている場合にはその認可トークンは承認され、そうでなければ拒絶される。したがって、例えば、スコープテーブル1600から、検証対象の認可トークンに紐づけられたスコープIDに対応する権限IDを取得し、そこに当該認可トークンのクライアントに紐づけて取得した権限IDが設定されている場合は、当該認可要求は有効と判定される。ここで、スコープテーブル1600にてクライアントスコープIDに紐づく権限ID1604が複数ある場合は、その複数の権限ID1604のうち少なくとも一つの権限IDがクライアントに設定されている場合は有効とみなす。また、クライアントスコープIDに紐づく権限IDが設定されていない場合は、クライアントの権限に関係なく無効とみなす。検証の結果、少なくとも一つ以上の権限IDにて無効となった場合、認可サーバーモジュール600はステップS4.14にてリソースサーバーモジュール700に権限エラーを応答し処理を終了する。検証の結果、S4.6 で取得した全てのクライアントスコープに対して有効となった場合、認可サーバーモジュール600はステップS4.15に移行する。

ステップS4.15にて認可サーバーモジュール600は、API利用上限数管理のための後述するAPIカウント処理を行う。ステップS4.16にて、本APIカウント処理の成功、失敗を判断し、もし成功したら、ステップS4.17にてAPIが実行可能であることをリソースサーバーモジュール700に応答し、処理を終了する。もしステップS4.16にて本APIカウント処理の失敗を判断したら、認可サーバーモジュール600はリソースサーバーモジュール700にAPI上限数管理エラーを応答して処理を終了する。

＜APIカウント処理＞
図１１は、図１０の認可トークン検証処理中の、認可サーバーモジュール600にて実施されるAPIカウント処理のフローチャートである。ステップS5.1にて、認可サーバーモジュール600は、検証する認可トークンに紐付くテナントIDを取得する。具体的には、認可トークン管理テーブル1900の認可トークンID1901の該当認可トークンのクライアントID1905を取得する。さらに、図４（ｂ）のクライアント管理テーブル1300のクライアントID1301から、前記クライアントIDに該当する行を参照し、該当するテナントID1303の値を取得する。次にステップS5.2にて、認可サーバーモジュール600は、API利用数管理テーブル1950の、先に取得したテナントIDとスコープIDにマッチするテナントID1951とスコープID1952の列を参照する。そして前記参照した列のAPI使用数1955をカウントアップする。さらにステップS5.3にて、認可サーバーモジュール600は、API使用数管理テーブル1950の前記参照する列のAPI上限数1954の値を確認し、前記API使用数1955（すなわちアクセス数）と、前記API上限数1954（すなわちアクセス上限数）とを比較する。もしステップS5.3でAPI使用数1955がAPI上限数1954を超過していなければ、API使用数上限内のAPI使用と判定して、ステップS5.4にて成功を返して処理を終了する。またもしステップS5.3でAPI使用数1955がAPI上限数1954を超過していると判断されれば、API使用上限を超えたAPI使用と判定して、ステップS5.5にて失敗を返して処理を終了する。

これらシーケンスによって、リソースサーバーモジュール700は適切な権限を有した、アプリケーションモジュール800からのアクセスのみを有効とし、意図しないアプリケーションモジュール800からのを権限エラーとして防ぐことが可能となる。さらに本実施形態のスコープにより参照可能となるリソースに関するアクセスAPI、あるいは一連のアクセスAPI群の呼び出し上限数を、テナント毎に管理し、さらにサービスごとに管理することが可能となる。これにより、QoS（Quality of Service）の概念に基づき、特定テナントのサービス、API過剰利用によるリソースサーバーモジュール700の提供する各種サービスのクオリティ低下の防止が可能となる。

さらに、一定期間内のAPIの使用回数が上限数を超えているか否かを判定するAPIカウント処理は、アプリケーションモジュール800による認可トークン取得処理において認可トークン要求を受けた認可サーバーモジュール600によって行われる（S2.30およびS3.6）。これは使用するプロトコルがClient Credentials Grantであるか、Authorization Code Grantであるかに依存しない。さらに、いったん認可トークを取得した後においても、当該認可トークンを用いてリソースをリソースサーバーに要求した際にも、認可トークン検証処理の中でAPIカウント処理が行われる（S1.20）。これにより、スコープに含まれたAPIの使用回数の上限により使用できない認可トークンを発行することがなくなり、処理資源や通信資源を節約できる。

［第２の実施形態］
特定のテナントにおいてサービス単位（スコープ単位）でAPI利用上限数が存在すると、クライアントがある一つのサービスのAPIを大量に利用して上限に達している状態で、前記ある一つのサービスと他のサービスを組み合わせた一連の機能が途中でエラーする可能性が発生する。すなわち、本実施形態の図５（ａ）のスコープテーブル1600に定義されたスコープID1601の、DataSetService、FormService、PrintService、DataSetFormPrintSerivceを考える。あるテナントがこれら4つのスコープに相当するAPI呼び出し、すなわちサービス要求を行うとする。その際、DataSetServiceスコープは、アプリケーションモジュール800がローカルのCSVファイルをリソースサーバーモジュール700にアップロードし、リソースサーバーモジュール700は該アップロードされたCSVファイルを構造化してデータセットに変換するAPIサービスを表す。またFormServiceスコープは、アプリケーションモジュール800が、リソースサーバーモジュール700上のデータセットを指定して帳票を作成するAPIサービスを表す。またPrintServiceは、アプリケーションモジュール800が、リソースサーバーモジュール700上の帳票データを印刷するAPIサービスを表す。さらにDataSetFormPrintServiceスコープは、アプリケーションモジュール800が、DataSetServiceスコープ、FormServiceスコープ、PrintServiceスコープのAPIを連続して呼び出し、ローカルのCSVファイルをアップロードして帳票作成、プリントするAPIサービスを表す。DataSetFormPrintServiceスコープは、本実施形態のスコープグループを表す。スコープグループとは複数スコープにひもづく認可トークンによる一連のリソース取得（ＡＰＩ呼び出し）の際の、該複数スコープの組み合わせに一意の名称を付すものである。スコープグループは、一連のリソース取得（ＡＰＩ呼び出し）を構成する。図９で示した認可トークン要求、発行シーケンスでは実際の認可トークン発行時には、複数のスコープIDを含む認可トークンとして発行される。スコープグループは認可サーバーモジュール800内の図５（ｇ）スコープグループテーブルにより規定され、アプリケーションモジュール800などクライアント側が感知するものではない。なおAPIはそのAPIで提供されるサービスを特定するものであるから、APIとサービスとは対応している。そこで本実施形態ではAPIおよび当該APIで提供されるサービスをまとめてAPIサービスと称した。したがってAPIサービスはサービスおよびそのAPIと言い替えることもできる。

今アプリケーションモジュール800がDataSetFormPrintServiceに相当する複数スコープを指定したAPIを呼び出すと、実際にはDataSetServiceスコープとFormServiceスコープとPrintServiceスコープについて図１０のフローチャートで認可トークンの検証が行われ、さらに図１１のAPIカウントが行われる。その際、前記３つのスコープのいずれかがAPI使用数上限に達していたとすると、一連のサービスの連携により構成されるDataSetFormPrintServiceスコープ（実際には複数スコープ指定）のAPI呼び出しが完了せず途中で停止してしまう可能性がある。一方、複数スコープ指定のAPI呼び出しが一連のサービスを示すことは、一連のサービスに含まれる複数スコープにスコープグループのIDを設けることで可能になる。また認可サーバーモジュール800がスコープグループと、個々のスコープのAPI上限数管理を別途管理することで個々のスコープについてのAPI呼び出しと、複数スコープで示される一連のサービス呼び出しを区別できる。これにより、前記一連のサービスの連携により構成される複数スコープ指定のAPI呼び出しが完了せず途中で停止してしまうことを回避することができる。

どのスコープがスコープグループを構成するかについては、あらかじめシステムで定められているものとする。なおユーザーによるスコープグループの定義を許してもよい。認可トークン要求において複数のスコープが指定された場合、指定された複数のトークンがすべて前記スコープグループで定められたスコープに過不足なくマッチする場合、前記複数スコープの認可トークン要求はスコープグループを指定したものと解釈する。該複数スコープ指定の認可トークン要求に応じて発行された認可トークンによるリソース取得（ＡＰＩ呼び出し）について、認可サーバーモジュール８００は、スコープグループ指定のリソース取得（ＡＰＩ呼び出し）と判定して処理を行う。

上記課題を解決するための第２の実施形態について、図５Ｂ、図１２、および図１３を用いて説明する。なお、第２の実施形態では、図８中のS1.11認可トークン取得からS1.17エラー応答シーケンス以外には差異がないため説明を省略する。また、図８と同様の処理を実施するシーケンスについては同じシーケンス番号を付与し、説明を省略する。

＜スコープグループAPI管理テーブル＞
図５（ｆ）はスコープグループAPI管理テーブル1980である。スコープグループAPI管理テーブル1980は、システムにより予め定義されているか、あるいはユーザーにより定義されるか、あるいはその両方である。スコープグループAPI管理テーブル1980は、テナントID1981、スコープID1982、グループ実行数1983、API使用数1984を有する。テナントID1981は、ユーザー管理テーブル1700のテナントID1703と互いに参照可能に構成されている。スコープID1982は、スコープグループのIDを示す。グループ実行数1983は、スコープID1982で示されるスコープグループIDに相当する複数のスコープIDに紐付く認可トークンをもってアプリケーションモジュール800がコールする一連のAPIがいくつあるかを示す。グループ実行数1983は、スコープグループとしてリソースが要求された回数の、単位期間あたりの上限数を示す。ただしこの回数は成功した要求に限る。API使用数1984は、前記一連のAPI呼び出しが何回行われたかを記録する。これらスコープグループAPI使用管理テーブル1980の処理詳細については後述する。

なお、スコープグループに係るAPI使用上限数1954もまた図７（ｂ）のようにユーザーにより設定される。一方グループ実行数1983はグループとしての実行数を示しているので、グループ実行数1983には、セットされたAPI使用上限数1954を当該スコープグループに含まれたスコープIDの数で除算した値（ただし小数部切り捨て）を設定すればよい。逆に、グループとしての実行数をセットさせ、その値を個別のAPIの使用数に換算してAPI使用上限数1954としてもよい。いずれにしても各APIの使用数の上限値と合算した総和がテナントにおけるAPIの総使用数の上限以下とする必要がある。

＜スコープグループテーブル＞
図５（ｇ）は、図５（ａ）、図５（ｂ）、図５（ｃ）、図５（ｄ）、図５（ｅ）、図５（ｆ）と同様、認可サーバー200がLAN101を介して通信可能に構成されたデータベースサーバー500の外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー200の外部メモリに構成する事もできる。

図５（ｇ）は、スコープグループテーブル1990である。スコープグループテーブル1990は、スコープグループID1991、スコープIDリスト1992、説明1993からなる。スコープグループID1991は、スコープグループのIDを示す。スコープグループIDリスト1992は、該スコープグループIDで示されるスコープグループが実際にどのスコープにより構成されるかのリストを示す。本実施形態においては、スコープグループIDのDataSetFormPrintSerivceスコープグループは、DataSetServiceスコープと、FormServiceスコープと、PrintServiceスコープの３つのスコープから構成される。アプリケーションサービス800が、該DataSetFormPrintServiceスコープグループに相当する前記３つのスコープが紐付く認可トークンによる、データアップロードサービスＡＰＩと、帳票サービスＡＰＩと、プリントサービスＡＰＩを連続して一度ずつ実行した際、認可サーバーモジュール600は、DataSetFormPrintServiceスコープグループで表される機能が一回提供されたと判断する。

＜認可トークンの取得処理＞ 図１２では、第２の実施形態における図８のシーケンスのうち、アプリケーションモジュール800の複数スコープを指定した認可トークンの取得から、認可サーバーモジュール600における該認可トークンを利用した、スコープグループによるAPI上限数管理、リソース取得（ＡＰＩ呼び出し）までを説明する。

アプリケーションモジュール800は、図８のシーケンスにおいて、認可トークンの要求を行いS1.11にて認可トークンを取得する。該認可トークン取得においてアプリケーションモジュール800が複数スコープを指定すると、図８のシーケンスに基づき複数スコープに対応した認可トークンが取得できる。その際、前記複数スコープが、認可サーバーモジュール600のスコープグループテーブル1990においてあらかじめ定義されたスコープIDリスト1992に過不足無く一致した場合、前記複数スコープは認可サーバーモジュール600においてスコープグループと認識される。スコープグループは、アプリケーションモジュール800が複数のスコープの各々に対応した複数のリソース取得（ＡＰＩ呼び出し）を行う際、認可サーバーモジュール600が一連のリソース取得（ＡＰＩ呼び出し）の完了を個別でなくまとめて数え上げるために用いられる。アプリケーションモジュール800のリソース取得（ＡＰＩ呼び出し）は、一つのスコープが紐付く場合と複数のスコープが紐付く場合で、認可サーバーモジュール600において区別される。

具体的には、前記一つのスコープが紐付くＡＰＩ呼び出しは以下の第一、第二、第三のＡＰＩ呼び出しのようになる。

（第１のＡＰＩ呼び出し）
前記DataSetServiceスコープに紐付く認可トークンによるリソース取得（アップロードサービスＡＰＩ呼び出し）は以下のようになる。認可トークン管理テーブル1900の認可トークンID1901で、DataSetServiceスコープに紐付く認可トークンIDは”AT_0000001”である。アプリケーションモジュール800はこれをBase64エンコードした””” QVRfMDAwMDAwMQ==”をAPI呼び出しの””Authorization: Bearer” の後に付与してAPI呼び出しを行う。
POST /oauth2/v1/dataset/upload HTTP/1.1
Authorization: Bearer QVRfMDAwMDAwMQ==
Host: example.com。

（第２のＡＰＩ呼び出し）
前記FormSerivceスコープに紐付く認可トークンによるリソース取得（帳票サービスＡＰＩ呼び出し）は以下のようになる。認可トークン管理テーブル1900の認可トークンID1901で、FormServiceスコープに紐付く認可トークンIDは”AT_0000002”である。アプリケーションモジュール800はこれをBase64エンコードした””” QVRfMDAwMDAwMg==”をAPI呼び出しの””Authorization: Bearer” の後に付与してAPI呼び出しを行う。
POST /oauth2/v1/form/create HTTP/1.1
Authorization: Bearer QVRfMDAwMDAwMg==
Host: example.com。

（第３のＡＰＩ呼び出し）
前記PrintServiceスコープに紐付く認可トークンによるリソース取得（プリントサービスＡＰＩ呼び出し）は以下のようになる。認可トークン管理テーブル1900の認可トークンID1901で、PrintServiceスコープに紐付く認可トークンIDは”AT_0000003”である。アプリケーションモジュール800はこれをBase64エンコードした””” QVRfMDAwMDAwMw==”をAPI呼び出しの””Authorization: Bearer” の後に付与してAPI呼び出しを行う。
GET /oauth2/v1/print?printerid=xxxx&jobid=yyyy HTTP/1.1
Authorization: Bearer QVRfMDAwMDAwMw==
Host: example.com。

上記第１、第２、第３のＡＰＩ呼び出しに対し、本実施形態の前記複数のスコープが紐付くＡＰＩ呼び出しは、次のようになる。すなわち前記DataSetServiceスコープと、前記FormServiceと、前記PrintServiceの３つが紐付いた認可トークンを用いたリソース取得（ＡＰＩ呼び出し）は、以下の第４、第５、第６のＡＰＩ呼び出しのようになる。

（第４のＡＰＩ呼び出し）
前記３つのスコープをまとめたグループスコープに紐づく認可トークンによるリソース取得（アップロードサービスＡＰＩ）は以下のようになる。認可トークン管理テーブル1900の認可トークンID1901で、DataSetFormPrintServiceスコープに紐付く認可トークンIDは”AT_0000004”である。アプリケーションモジュール800はこれをBase64エンコードした””” QVRfMDAwMDAwNA==”をAPI呼び出しの””Authorization: Bearer” の後に付与してAPI呼び出しを行う。
POST /oauth2/v1/dataset/upload HTTP/1.1
Authorization: Bearer QVRfMDAwMDAwNA==
Host: example.com。

（第５のＡＰＩ呼び出し）
前記３つのスコープをまとめたグループスコープに紐づく認可トークンによるリソース取得（帳票サービスＡＰＩ）は以下のようになる。認可トークン管理テーブル1900の認可トークンID1901で、DataSetFormPrintServiceスコープに紐付く認可トークンIDは”AT_0000004”である。アプリケーションモジュール800はこれをBase64エンコードした””” QVRfMDAwMDAwNA==”をAPI呼び出しの””Authorization: Bearer” の後に付与してAPI呼び出しを行う。
POST /oauth2/v1/form/create HTTP/1.1
Authorization: Bearer QVRfMDAwMDAwNA==
Host: example.com。

（第６のＡＰＩ呼び出し）
前記３つのスコープをまとめたグループスコープに紐づく認可トークンによるリソース取得（プリントサービスＡＰＩ）は以下のようになる。認可トークン管理テーブル1900の認可トークンID1901で、DataSetFormPrintServiceスコープに紐付く認可トークンIDは”AT_0000004”である。アプリケーションモジュール800はこれをBase64エンコードした””” QVRfMDAwMDAwNA==”をAPI呼び出しの””Authorization: Bearer” の後に付与してAPI呼び出しを行う。
GET /oauth2/v1/print?printerid=xxxx&jobid=yyyy HTTP/1.1
Authorization: Bearer QVRfMDAwMDAwNA==
Host: example.com。

図１２において、アプリケーションモジュール800は、上記第４、第５、第６のＡＰＩ呼び出しを行う。それぞれ図１２の上段、中段、下段に相当する。すなわち、ステップS8.11からS8.17において前記第４のＡＰＩ呼び出しをおこない、S9.11からS9.17において前記第５のＡＰＩ呼び出しを行い、S10.11からS10.17において前記第６のＡＰＩ呼び出しを行う。これらＡＰＩ呼び出しのシーケンスについては、図１０のフローチャートで示される認可トークン検証処理中のＡＰＩカウント処理を除き、図８のS1.11からS1.17と同様であるので省略する。このように、１つのグループスコープに紐づけされた認可トークンを用いて、グループスコープに含まれた個別のスコープに応じてサービスを受けることができる。

図１２の、図１０のフローチャートで示される認可トークン検証処理中のＡＰＩカウント処理について、図１３のフローチャートを用いて詳細に説明する。図１３は第１実施形態の図１１に代えて本実施形態で実行される処理である。

ステップS7.1にて、認可サーバーモジュール600は、検証する認可トークンに紐付くテナントＩＤを取得する。具体的には、認可トークン管理テーブル1900の認可トークンＩＤ1901に相当する該当認可トークンのクライアントＩＤ1905を取得する。さらに、図４（ｂ）のクライアント管理テーブル1300のクライアントＩＤ1301から、前記クライアントＩＤに該当する行を参照し、該当するテナントＩＤ1303の値を取得する。次にステップS7.2にて、認可サーバーモジュール600は、認可トークンテーブル1900を参照し、現検証対象の認可トークンＩＤ1901にマッチする行のスコープＩＤ1904を参照する。次にステップS7.3にて、前記ステップS7.2で参照したスコープＩＤ1904が一つのスコープＩＤか、複数のスコープＩＤかを判定する。ここでもし前記スコープＩＤが複数のスコープＩＤであれば、次に認可サーバーモジュール600は、ステップS7.4にてスコープグループテーブル1990のスコープグループＩＤリスト1992を参照し、前記複数のスコープＩＤが前記スコープグループＩＤリスト1992に過不足無くマッチするかどうか判定する。前記ステップS7.3にてスコープＩＤが複数でなければ、ステップS7.7に遷移する。また前記ステップS7.4にて前記複数スコープがスコープＩＤリスト1992に過不足無くマッチすることがなければ、ステップS7.7に遷移する。前記ステップS7.4にて検証処理中の複数スコープＩＤがスコープＩＤリスト1992に過不足無くマッチしたならば、認可サーバーモジュール600は、前記複数スコープＩＤがスコープグループテーブル1990のスコープＩＤリスト1992にマッチするスコープグループＩＤであると判断する。

そしてスコープグループであると判定された場合、ステップS7.5にて、スコープグループ管理テーブル1980の、前記ステップS7.1にて取得したテナントＩＤにマッチするテナントＩＤ1981と前記スコープグループＩＤにマッチするスコープＩＤ1982を検索し、同行のＡＰＩ使用数1984を１カウントアップする。ここでステップS7.6にて、認可サーバーモジュール600は、前記スコープグループAPIステータス管理テーブル1980の前記API使用数1984の値が、前記グループ実行数1983の値を超えていないかどうか判定する。もし前記API使用数1984の値が、前記グループ実行数1983の値を超えていれば、認可サーバーモジュール600は、前記API使用数1984の値を0に戻した後、ステップS7.7に遷移する。またもし前記API使用数1984の値が、前記グループ実行数1983の値を超えていなければ、認可サーバーモジュール600はS7.9にて成功を返して処理を終了する。ステップS7.7にて、認可サーバーモジュール600は、API使用数管理テーブル1950の前記参照する列のAPI上限数1954の値を確認し、前記API使用数1955と、前記API上限数1954を比較する。もしステップS7.8でAPI使用数1955がAPI上限数1954を超過していなければ、API使用数上限内のAPI使用と判定して、ステップS7.9にて成功を返して処理を終了する。またもしステップS7.8でAPI使用数1955がAPI上限数1954を超過していると判断されれば、API使用上限を超えたAPI使用と判定して、ステップS7.10にて失敗を返して処理を終了する。

以上が第２の実施形態におけるスコープおよびスコープグループ単位のAPI使用数上限管理の説明である。上記処理により、認可サーバーモジュール600は、クライアントから、クライアント登録時に利用するスコープのリクエストを受け付け、権限が不足なのであれば、その時点で登録エラーが返却されるよう処理する事が可能となる。結果、無駄なクライアント登録を回避する事ができる。

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

Claims (13)

1. リソースに対するユーザーのアクセス権限を管理する管理手段と、
   クライアントからの、リソースに対するユーザーの前記アクセス権限の委譲を要求する認可要求に応じて、該認可要求を検証し、検証が成功した場合には前記クライアントに対して認可トークンを発行する発行手段と、
   リソース要求が前記認可トークンとともにあった場合、前記認可トークンを検証し、検証が成功した場合には検証応答を返す検証手段とを有し、
   前記発行手段による前記認可要求の検証と、前記検証手段による前記認可トークンの検証とはいずれも、前記リソースに対するアクセス数が、設定されたアクセス上限数を超えたか否か判定し、超えない場合に当該認可トークンが正当であると判定することを含むことを特徴とする権限管理サーバー。
2. 前記リソースに対するアクセス数が前記アクセス上限数を超えるか否かは、当該リソースごとのアクセス数を、リソースごとに設定されたアクセス上限数と比較して判定されることを特徴とする請求項１に記載の権限管理サーバー。
3. 前記アクセス上限数は、前記リソースの提供先であるテナントあたり、かつ、単位期間あたりのアクセス上限数であることを特徴とする請求項１または２に記載の権限管理サーバー。
4. 前記アクセス上限数を入力するための入力画面を端末に表示させて、前記入力画面に対して入力された値を前記アクセス上限数として設定する設定手段を更に有することを特徴とする請求項１乃至３のいずれか一項に記載の権限管理サーバー。
5. 前記入力画面には、リソースごとに前記アクセス上限数を入力するための入力欄が含まれ、前記入力画面に対してリソースごとに入力された値をリソースごとの前記アクセス上限数として設定することを特徴とする請求項４に記載の権限管理サーバー。
6. 前記認可要求および前記認可トークンそれぞれには、複数のリソースをまとめたグループを含めることができ、
   前記リソースに対するアクセス数が前記アクセス上限数を超えるか否かは、当該グループを単位としたリソースへのアクセス数を、グループごとに設定されたアクセス上限数と比較して判定されることを特徴とする請求項１乃至３のいずれか一項に記載の権限管理サーバー。
7. 前記アクセス上限数を入力するための入力画面を端末に表示させて、前記入力画面に対して入力された値を前記アクセス上限数として設定する設定手段を更に有し、
   前記入力画面には、前記グループごとに前記アクセス上限数を入力するための入力欄が含まれ、前記入力画面に対して前記グループごとに入力された値を前記アクセス上限数として設定することを特徴とする請求項６に記載の権限管理サーバー。
8. リソースに対するユーザーのアクセス権限を管理する管理手段と、
   クライアントからの、リソースに対するユーザーの前記アクセス権限の委譲を要求する認可要求に応じて前記クライアントに対して認可トークンを発行する発行手段と、
   リソース要求が前記認可トークンとともにあった場合、前記認可トークンを検証し、検証が成功した場合には検証応答を返す検証手段とを有し、
   前記検証手段による前記認可トークンの検証では、要求されたリソースに対するアクセス数が、設定されたアクセス上限数を超えるか否か判定し、超えない場合に当該認可トークンが正当であると判定することを含むことを特徴とする権限管理サーバー。
9. 前記認可トークンを検証した結果、当該認可トークンが正当であると検証された場合、認証情報の入力を要求することなくリソースに対するアクセスを許可することを特徴とする請求項１乃至８のいずれか一項に記載の権限管理サーバー。
10. 請求項１乃至９のいずれか一項に記載の権限管理サーバーと、
    前記権限管理サーバーに接続された端末と、
    前記端末からリソース要求が前記認可トークンとともにあった場合には、前記認可トークンの検証を前記権限管理サーバーに要求し、前記権限管理サーバーから、前記認可トークンを認める応答があった場合には、前記端末から要求されたリソースを提供するリソースサーバーと
    を有することを特徴とするリソース提供システム。
11. 請求項１乃至９のいずれか一項に記載の権限管理サーバーとしてコンピュータを機能させるためのプログラム。
12. リソースに対するユーザーのアクセス権限を管理する管理工程と、
    クライアントからの、リソースに対するユーザーの前記アクセス権限の委譲を要求する認可要求に応じて、該認可要求を検証し、検証が成功した場合には前記クライアントに対して認可トークンを発行する発行工程と、
    リソース要求が前記認可トークンとともにあった場合、前記認可トークンを検証し、検証が成功した場合には検証応答を返す検証工程とを有し、
    前記発行工程による前記認可要求の検証と、前記検証工程による前記認可トークンの検証とはいずれも、前記リソースに対するアクセス数が、設定されたアクセス上限数を超えたか否か判定し、超えない場合に当該認可トークンが正当であると判定する工程を含むことを特徴とする権限管理方法。
13. リソースに対するユーザーのアクセス権限を管理する管理工程と、
    クライアントからの、リソースに対するユーザーの前記アクセス権限の委譲を要求する認可要求に応じて前記クライアントに対して認可トークンを発行する発行工程と、
    リソース要求が前記認可トークンとともにあった場合、前記認可トークンを検証し、検証が成功した場合には検証応答を返す検証工程とを有し、
    前記検証工程による前記認可トークンの検証は、要求されたリソースに対するアクセス数が、設定されたアクセス上限数を超えるか否か判定し、超えない場合に当該認可トークンが正当であると判定する工程を含むことを特徴とする権限管理方法。

Images