(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-28
(45)【発行日】2023-05-11
(54)【発明の名称】サービス認可処理装置、システム、方法及びプログラム
(51)【国際特許分類】
G06F 21/44 20130101AFI20230501BHJP
【FI】
G06F21/44
(21)【出願番号】P 2018224487
(22)【出願日】2018-11-30
【審査請求日】2021-10-28
【前置審査】
(73)【特許権者】
【識別番号】000003078
【氏名又は名称】株式会社東芝
(73)【特許権者】
【識別番号】301063496
【氏名又は名称】東芝デジタルソリューションズ株式会社
(74)【代理人】
【識別番号】110003708
【氏名又は名称】弁理士法人鈴榮特許綜合事務所
(72)【発明者】
【氏名】保坂 真由美
(72)【発明者】
【氏名】江崎 裕一郎
(72)【発明者】
【氏名】斉藤 稔
【審査官】局 成矢
(56)【参考文献】
【文献】特開2013-105442(JP,A)
【文献】特開2017-204073(JP,A)
【文献】特開2017-059219(JP,A)
【文献】米国特許出願公開第2017/0083697(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 21/44
(57)【特許請求の範囲】
【請求項1】
複数のサービスを連携して、所定の機能を実現するシステムに適用するサービス認可処理装置であって、
連携する各サービスを実行する際に、認可が必要であるか否かを判定する認可判定手段と、
認可が必要であるサービスに対して認可に利用する認可情報を提供するために、前記認可情報を取得して管理する認可情報管理手段と、
前記連携する各サービスの起動時に、前記システムに含まれるサーバから取得する情報に基づいて、前記連携する各サービス毎に、呼び出し関係を示す第1の情報と、認可の必要性が有るか又は無いかを特定する第2の情報とを含む認可処理情報を作成する認可処理情報作成手段と、
前記認可処理情報作成手段によって作成された前記認可処理情報を格納する第2の記憶装置とを具備し
、
前記認可判定手段は、前記認可処理情報において、前記第2の情報に、許可の必要性が無いと特定されているサービスが認可を必要としないと判定する、
サービス認可処理装置。
【請求項2】
前記認可情報管理手段は、
前記システムに含まれるサーバから、前記認可判定手段により認可が必要であると判定されるサービスに対応する認可情報を取得し、
前記認可情報を第1の記憶装置に格納し、
前記認可情報を利用するサービスからの要求に基づいて、前記第1の記憶装置から前記認可情報を取り出して前記サービスに提供する、請求項1に記載のサービス認可処理装置。
【請求項3】
請求項1
又は2に記載のサービス認可処理装置と、
前記サービス認可処理装置と通信して、複数のサービスを連携して実行する第1のサーバと、
前記サービス認可処理装置と通信して、前記認可情報を生成して前記サービス認可処理装置に提供する第2のサーバと
を具備する、システム。
【請求項4】
前記サービス認可処理装置は、
前記第1のサーバ及び前記第2のサーバと通信し、各種の情報を交換する中継手段を含む、請求項
3に記載のシステム。
【請求項5】
複数のサービスを連携して、所定の機能を実現するシステムに適用するサービス認可処理の方法であって、
連携する各サービスを実行する際に、認可が必要であるか否かを判定する処理と、
認可が必要であるサービスに対して認可に利用する認可情報を提供するために、前記認可情報を取得して管理する処理と、
前記連携する各サービスの起動時に、前記システムに含まれるサーバから取得する情報に基づいて、前記連携する各サービス毎に、呼び出し関係を示す第1の情報と、認可の必要性が有るか又は無いかを特定する第2の情報とを含む認可処理情報を作成して、第2の記憶装置に格納する処理と、
前記認可処理情報において、前記第2の情報に、許可の必要性が無いと特定されているサービスが認可を必要としないと判定する処理とを実行する、方法。
【請求項6】
前記システムに含まれるサーバから、認可が必要であると判定されるサービスに対応する前記認可情報を取得する処理と、
前記認可情報を第1の記憶装置に格納する処理と、
前記認可情報を利用するサービスからの要求に基づいて、前記第1の記憶装置から前記認可情報を取り出して前記サービスに提供する処理と
を実行する、請求項
5に記載の方法。
【請求項7】
請求項
5又は
6に記載の方法による各処理を、コンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、サービス認可処理装置、システム、方法及びプログラムに関する。
【背景技術】
【0002】
近年、例えばWebサービスを提供するためのシステムやソフトウェアの開発において、サービスの全機能を、いわゆるモノリス(monolith)構成ではなく、マイクロサービスを利用して構成する方式が注目されている。マイクロサービスアーキテクチャは、複数のサービスを組み合わせて連携させることにより、所定の全機能を実現する仕組みである。マイクロサービスを利用する方式であれば、外部のサービスを利用できるために、開発コストの削減を実現できる。また、組み合わせる各サービスは独立性があるため、サービス(機能)ごとの変更や追加が容易となる。
【0003】
ところで、マイクロサービスを利用して、連携元のサービスが連携先のサービスを呼び出して利用する場合に、例えばOAuth2というプロトコルを利用した認可が必要となることがある。この場合、例えばアクセストークン(access token)のような、認可に必要な認可情報を取得するための認可処理が必要となる。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2015-228067号公報
【文献】WO2013145517号公報
【文献】特開2009-99131号公報
【文献】特開2013-145506号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
マイクロサービスを利用する方式では、認可を必要としない連携元のサービスが、認可が必要である連携先のサービスを呼び出して利用する場合、当該連携元サービスは認可処理を実行する機能を実装することが要求されることになる。このため、マイクロサービスの利点に含まれる各サービスの独立性を確保できなくなる。
【0006】
そこで、目的は、認可を必要とするサービスを含む複数のサービスを連携して、所定の機能を実現する方式に適用できると共に、各サービスの独立性を確保できるサービス認可処理装置を提供することにある。
【課題を解決するための手段】
【0007】
本実施形態のサービス認可処理装置は、複数のサービスを連携して、所定の機能を実現するシステムに適用するサービス認可処理装置であって、認可判定手段と、認可情報管理手段と、認可処理情報作成手段と、第2の記憶装置とを有する。前記認可判定手段は、連携する各サービスを実行する際に、認可が必要であるか否かを判定する。前記認可情報管理手段は、認可が必要であるサービスに対して認可に利用する認可情報を提供するために、前記認可情報を取得して管理する。認可処理情報作成手段は、前記連携する各サービスの起動時に、前記システムに含まれるサーバから取得する情報に基づいて、前記連携する各サービス毎に、呼び出し関係を示す第1の情報と、認可の必要性が有るか又は無いかを特定する第2の情報とを含む認可処理情報を作成する。前記第2の記憶装置は、前記認可処理情報作成手段によって作成された前記認可処理情報を格納する。前記認可判定手段はさらに、前記認可処理情報において、前記第2の情報に、許可の必要性が無いと特定されているサービスが認可を必要としないと判定する。
【図面の簡単な説明】
【0008】
【
図1】実施形態に関するシステムの構成を説明するためのブロック図。
【
図2】実施形態に関するサービス関連テーブルの一例を示す図。
【
図3】実施形態に関する認可情報テーブルの一例を示す図。
【
図4】実施形態に関するユーザ情報テーブルの一例を示す図。
【
図5】実施形態に関する各サービスの呼び出し関係の一例を示す図。
【
図6】実施形態に関する認可処理の概要を説明するための図。
【
図7】実施形態に関する認可処理を説明するためのフローチャート。
【
図8】実施形態に関する認可判定部の処理を説明するためのフローチャート。
【
図9】実施形態に関するアクセストークン管理部の処理を説明するためのフローチャート。
【
図10】実施形態に関するサービス関連作成部の処理を説明するためのフローチャート。
【発明を実施するための形態】
【0009】
以下図面を参照して、実施形態を説明する。
[システムの構成]
図1は、本実施形態に関するシステム1の構成を示す図である。
図1に示すように、本実施形態のシステム1は、認可処理装置10、認可サーバ13、リソースサーバ14、及び各種のサービス(機能)A~Eを実現するサービス提供サーバ15を有する。サービス提供サーバ15は、各サービスA~Eをそれぞれ独立して実現する複数のサーバ群であり、後述するように、各サービスA~Eを連携させるマイクロサービスを実現する。マイクロサービスは、複数のサービスを連携して所定のサービス(機能)を実現する方式である。
【0010】
認可処理装置10は、主としてコンピュータ及び記憶装置により実現する、APIゲートウエイ(Application Programming Interface Gateway)11及びサービスレジストリ12を含む。本実施形態のAPIゲートウエイ11は、クライアント2とサービス(A~E)との間で各種の情報を交換する中継機能を実現すると共に、後述する認可判定機能を有する。APIゲートウエイ11は、通信の制御を実行する通信部101及び認可判定部102を含む。認可判定部102は、後述する認可情報取得部103により取得されたデータに基づいて、サービスを利用する上での認可が必要であるか否かを判定する認可判定処理を実行する。
【0011】
サービスレジストリ12は情報管理用のサーバに相当し、認可情報取得部103、アクセストークン(Access Token)管理部104、認可情報記憶部105、及びサービス関連作成部106を含む。認可情報取得部103は、認可情報記憶部105から、後述するサービス関連テーブル20、認可情報テーブル21、及びユーザ情報テーブル22を取得する。これらの各テーブル20、21、22は、認可処理装置10において使用される認可処理情報である。
【0012】
アクセストークン管理部104は、認可サーバ13により発行されるアクセストークンを認可情報記憶部105に登録する処理や、認可情報記憶部105からアクセストークンを取得する処理を実行する。認可情報記憶部105は、サービス関連テーブル20、認可情報テーブル21、及びユーザ情報テーブル22を格納すると共に、登録対象のアクセストークンを格納する。サービス関連作成部106は、後述するように、サービス関連テーブル20及び認可情報テーブル21を作成して、認可情報記憶部105に格納する。
【0013】
認可サーバ13は、APIゲートウエイ11の通信部101と接続し、ユーザが操作するクライアント2からのリクエストに基づいて、リソースサーバ14にアクセスするか否かの判定処理や、アクセストークンを発行する処理を実行する。本実施形態では、リソースサーバ14は、例えばサービスEと連携する外部のサービス(F)を提供する。ここで、サービスEが当該サービス(F)にアクセスするためには、例えばOAuth2のプロトコルを利用した認可が必要であるとする。なお、本実施形態では、当該OAuth2のプロトコルを利用した認可を、単に認可と表記する。
【0014】
図2は、サービス関連テーブル20の一例を示す図である。サービス関連テーブル20は、マイクロサービスを実現するために、連携する各サービスの呼び出し関係を表す情報である。
図5は、当該各サービスの呼び出し関係の一例を示す図である。
図5に示すように、クライアント2からのリクエストにより、サービスA(パス:/service a-1)が呼び出されると、サービスAはサービスB(パス:/service b-1)とサービスD(パス:/service d-1)を呼び出す。さらに、サービスBは、サービスC(パス:/service c-1)とサービスE(パス:/service e-1)を呼び出す関係になっている。
【0015】
図2に示すように、サービス関連テーブル20は、
図5で示すような各サービスの呼び出し関係を、サービス名とパスにより一意に特定できる情報である。即ち、サービス関連テーブル20は、行単位のデータにより、どのサービスがどのサービスを呼び出しているかを定義している。例えば、1行目のデータは、サービスA(パス:/service a-1)が、サービスB(パス:/service b-1)を呼び出すことを定義している。ここで、パスとは、サービス名のサービスにアクセスするためのルートを示し、例えばURL(Uniform Resource Locator)のパス名に相当する情報である。
【0016】
図3は、認可情報テーブル21の一例を示す図である。
図3に示すように、認可情報テーブル21は、各サービスA~Eにアクセスする(呼び出す)ために、認可を必要とするか否かを示す情報である。認可情報テーブル21は、例えば、サービスAからサービスDについては認可を必要とせず、サービスEについては認可を必要とすることを示している。
【0017】
図4は、ユーザ情報テーブル22の一例を示す図である。
図4に示すように、ユーザ情報テーブル22は、ユーザ毎に、サービスにアクセスする際の認可に必要なアクセストークン(Access Token)を設定している情報である。即ち、アクセストークンは、認可に使用する認可情報である。ユーザ情報テーブル22は、例えば、ユーザIDとして「User C」が設定されたユーザが、クライアント2からサービスEにアクセスするためのアクセストークン「accVkjcJyb4BWCx」、及び、その有効期限が「2020/11/30 00:00:00」であることを示している。
[システムの動作]
図6は、本実施形態の認可処理装置10及び認可サーバ13による認可処理の概要を説明するための図である。ここでは、ユーザIDとして「User A」が設定されたユーザがクライアント2から、サービスA(パス:/service a-1)にアクセスする例として説明する。
【0018】
APIゲートウエイ11は、クライアント2からサービスAに対してアクセスがあると(60)、認可判定部102がアクセス先のサービスが認可を必要とするか否かを判定する。認可判定部102は、サービスレジストリ12にアクセスし(61)、認可情報記憶部105に格納されたサービス関連テーブル20及び認可情報テーブル21を参照して、認可の有無を判定する。なお、クライアント2は、例えば、パーソナルコンピュータのディスプレイ200及びPC本体201からなる。
【0019】
ここで、APIゲートウエイ11は、例えばサービスAと連携してアクセス先となるサービス(E)が認可を必要とする場合には、クライアント2のPC本体201に対して認可を行うためにリダイレクトする(62)。クライアント2は、認可サーバ13にリダイレクトすることで(63)、認可サーバ13からログイン画面情報を受信する(64)。クライアント2は、ディスプレイ200上の表示されたログイン画面上にユーザIDやパスワードを入力して、認可サーバ13に送信する(65)。認可サーバ13は、ユーザIDやパスワードが正しい場合には、認可コードをクライアント2及びAPIゲートウエイ11に返信する(66)。
【0020】
APIゲートウエイ11は、認可サーバ13から取得する認可コードを利用して、認可サーバ13により発行される認可情報であるアクセストークンを取得する(67)。本実施形態では、APIゲートウエイ11は、認可サーバ13から取得したアクセストークンを、サービスレジストリ12の認可情報記憶部105に格納する(61)。
【0021】
このような認可処理の実行後に、APIゲートウエイ11は、サービスAに対してアクセスする(68)。
図5に示すような呼び出し関係により、各サービスAからEは連携して、所定のサービスの全機能を実現する。即ち、サービスAは、連携先であるサービスB及びサービスDを呼び出す。さらに、サービスBは、連携先であるサービスC及びサービスEを呼び出す。
【0022】
ここで、サービスEは、リソースサーバ14にアクセスするために、サービスレジストリ12の認可情報記憶部105に格納されたアクセストークンを取得する(69)。サービスEは、リソースサーバ14に当該アクセストークンを送信する(70)。即ち、サービスEは、アクセストークンを使用してサービスFを呼び出し、必要なリソースを取得できる(71)。
【0023】
図7から
図10は、本実施形態の認可処理装置10及び認可サーバ13による認可処理を、さらに詳細に説明するためのフローチャートである。
【0024】
図7に示すように、APIゲートウエイ11は、通信部101がクライアント2から、サービスAに対してアクセスするためのリクエストを受け付けると(S1)、認可判定部102により認可が必要であるか否かを判定する(S2)。
【0025】
図8は、認可判定部102の判定処理を説明するためのフローチャートである。認可判定部102は、サービスレジストリ12の認可情報取得部103にアクセスする。
図8に示すように、認可情報取得部103は、認可情報記憶部105からサービス関連テーブル20及び認可情報テーブル21を取得する(S20)。認可判定部102は、サービス関連テーブル20を参照して、パスとサービス名が一致する項目のデータを取得する(S21)。ここでは、サービスA(パス:/service a-1)にアクセスしているので、サービス関連テーブル20の1行目と2行目の各データを取得する。
【0026】
次に、認可判定部102は、認可情報テーブル21を参照して、パスとサービス名が一致する項目のデータを取得する(S22)。認可判定部102は、認可情報テーブル21のデータから、認可の有無を判定する(S23)。具体的には、認可情報テーブル21の1行目のデータは、認可の値が無しなっているため、認可判定部102は、サービスAが認可を行わない(認可を必要としない)と判定する。
【0027】
次に、認可判定部102は、サービス関連テーブル20を参照して、パスを含むサービス名(A)に対応する、利用サービスパスを含む利用サービス名(B,D)を取得する(S24)。利用サービスパスと利用サービス名が無しの場合は、対応するサービスから呼び出されるサービスが無いことを示す。
【0028】
具体的には、サービス関連テーブル20の1行目のデータから、サービスAがする利用サービスが利用サービス名B(利用サービスパス:/service b-1)であるため、認可判定部102は、サービス関連テーブル20の3及び4行目のデータ(いずれもサービス名B)を取得する。同様に、サービス関連テーブル20の2行目のデータ(利用サービス名D)から、サービス関連テーブル20の6行目のデータ(サービス名D)を取得する。
【0029】
認可判定部102は、サービス関連テーブル20からデータを取得できなくなるまで、S21からの処理を繰り返す(S25のYES)。認可判定部102は、データを取得できなかった場合に処理を終了する(S25のNO)。このような認可判定部102の処理により、サービスA(パス:/service a-1)にアクセスするためには、提携先のサービスE(パス:/service e-1)において認可が必要であることが判定できる。
【0030】
図7に戻って、APIゲートウエイ11は、サービスAにアクセスするために、認可判定部102により認可が必要でないと判定された場合(S3のNO)、通信部101を経由してサービスAを実行して処理を終了する(S17)。即ち、クライアント2は、APIゲートウエイ11を介して、サービスAからEが連携して実現される、所定のサービスの全機能が提供される。
【0031】
一方、認可判定部102は認可が必要と判定した場合、アクセストークン管理部104にアクセスする(S3のYES)。アクセストークン管理部104は、認可情報記憶部105にアクセストークンが登録(格納)されている否かを確認する(S4)。
【0032】
図9は、アクセストークン管理部104の処理を説明するためのフローチャートである。
図9に示すように、アクセストークン管理部104は、認可情報記憶部105からユーザ情報テーブルを取得する(S30)。アクセストークン管理部104は、ユーザ情報テーブル(
図4を参照)から、ユーザID、パス、サービス名(E)が一致するデータを取得する(S31)。具体的には、ユーザ情報テーブル22から、例えば、ユーザIDとして「User C」、パスが「/service e-1」、及びサービス名Eのデータを取得する。即ち、サービスA(パス:/service a-1)にアクセスするためには、提携先のサービスE(パス:/service e-1)において認可が必要であるという、認可判定部102の判定結果に基づいている。
【0033】
アクセストークン管理部104は、ユーザ情報テーブル22から、アクセストークンが登録済みであるか否かを確認する(S32)。ここで、アクセストークン管理部104は、ユーザ情報テーブル22の1行目のデータにはアクセストークンの値がないため、この場合には、アクセストークンが登録済みでないと判定し(S32のNO)、その旨を認可判定部102に返信する(S34)。
【0034】
アクセストークン管理部104は、ユーザ情報テーブル22の3行目のデータにはアクセストークンの値があるため、アクセストークンが登録済みであると判定し(S32のYES)、その旨を認可判定部102に返信する(S33)。但し、アクセストークン管理部104は、有効期限の値が現在より前であれば、アクセストークンが登録済みでないと判定し、有効期限の値が現在より後であれば、アクセストークンが登録済みであると判定する。
【0035】
図7に戻って、APIゲートウエイ11は、認可判定部102がアクセストークン管理部104からアクセストークンが登録済みであるとの返信を受けると(S5のYES)、通信部101を経由してサービスAを実行する(S14)。即ち、
図5に示すような呼び出し関係により、各サービスAからEは連携して、所定のサービスの全機能を実現する。
【0036】
この場合、サービスEは、サービスBからの呼び出しに応じて、アクセストークン管理部104から、認可情報記憶部105に登録(格納)されているアクセストークンを取得する(S15)。サービスEは、APIゲートウエイ11から送信される、ユーザ情報テーブル22のユーザID、パス、サービス名を含む情報を利用して、アクセストークン管理部104から所定のアクセストークンを取得する。サービスEは、当該アクセストークンを利用してリソースサーバ14にアクセスし、サービスFを呼び出して必要なリソースを取得する(S16)。これにより、クライアント2は、APIゲートウエイ11を介して、サービスAからEが連携して実現される、所定のサービスの全機能が提供される。
【0037】
一方、APIゲートウエイ11は、認可判定部102がアクセストークン管理部104からアクセストークンが登録済みでないとの返信を受けると(S5のNO)、通信部101を経由して認可サーバ13にリダイレクトする(S6)。以下、
図6を参照して前述したように、アクセストークン管理部104は、認可サーバ13が発行するアクセストークンを、認可情報記憶部105に登録(格納)する処理を実行する。
【0038】
即ち、認可サーバ13は、クライアント2にログイン画面を表示する(S7)。クライアント2は、ユーザがログイン画面に入力した、ユーザIDとパスワードを、認可サーバ13に送信する(S8)。認可サーバ13は、送信されたユーザIDとパスワードが正しくない場合には、クライアント2にログイン画面を再度表示する(S9のNO)。
【0039】
一方、認可サーバ13は、送信されたユーザIDとパスワードが正しい場合には(S9のYES)、通信部101に認可コードを返信する(S10)。APIゲートウエイ11は、通信部101を経由し、認可コードを利用して認可サーバ13からアクセストークンを取得する(S11)。通信部101は、取得したアクセストークンを、アクセストークン管理部104に渡す(S12)。アクセストークン管理部104は、アクセストークンを認可情報記憶部105に登録する(S13)。具体的には、アクセストークン管理部104は、認可情報記憶部105に格納されているユーザ情報テーブル22に対して、ユーザID、パス、サービス名(E)、アクセストークン、アクセストークンの有効期限を登録する(
図4を参照)。
【0040】
ここで、サービス関連作成部106は、APIゲートウエイ11からの通知に応じたサービス起動時に、サービス関連テーブル20及び認可情報テーブル21を作成して認可情報記憶部105に格納する。
図10は、サービス関連作成部106の処理を示すフローチャートである。
【0041】
図10に示すように、サービス起動時に、サービス関連作成部106は、APIゲートウエイ11を経由して、サービス提供サーバ15により呼び出される。サービス関連作成部106は、サービス提供サーバ15からAPIゲートウエイ11を経由して提供される情報に基づいて、サービス関連テーブル20を作成して認可情報記憶部105に格納(登録)する(S40)。この場合、サービス関連作成部106は、サービスのソースコードや設定ファイルなどに基づいて各サービスの呼び出し関係を取得し、サービス関連テーブル20を作成する。
【0042】
次に、サービス関連作成部106は、サービス提供サーバ15からAPIゲートウエイ11を経由して提供される情報に基づいて、認可情報テーブル21を作成して認可情報記憶部105に格納(登録)する(S41)。この場合、サービス関連作成部106は、サービスのソースコードや設定ファイルなどに基づいて、該当するサービスが認可を必要とするか否かの情報を取得し、認可情報テーブル21を作成する。
【0043】
以上のように本実施形態によれば、クライアントからのリクエストに応じて、複数のサービスが連携して所定のサービスの全機能を実現する、マイクロサービスを提供することが可能となる。このようなマイクロサービスにおける各サービスの呼び出し関係において、呼び出し先のサービスで認可が必要となる場合に、当該サービスが認可に必要なアクセストークンを利用することができる。これにより、連携する複数のサービスの中で、認可を必要としない呼び出し元のサービスは、呼び出し先の認可に必要な認可処理機能の実装が不要となる。従って、各サービスが連携してマイクロサービスを実現する場合に、各サービスの独立性を確保することができる。
【0044】
なお、本実施形態では、OAuth2というプロトコルを利用する認可について説明したが、これに限ることなく、別の方式による認可にも適用できる。また、本実施形態の各サービスの呼び出し関係は一例であり、別の呼び出し関係にも適用できる。
【0045】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0046】
1…システム、2…クライアント、10…認可処理装置、11…APIゲートウエイ、
12…サービスレジストリ、13…認可サーバ、14…リソースサーバ、
15…サービス提供サーバ、101…通信部、102…認可判定部、
103…認可情報取得部、104…アクセストークン管理部、
105…認可情報記憶部、106…サービス関連作成部。