JP2016004307A

JP2016004307A - システム、方法、サーバーシステム、およびプログラム

Info

Publication number: JP2016004307A
Application number: JP2014122538A
Authority: JP
Inventors: 浩太郎松田; Kotaro Matsuda
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-06-13
Filing date: 2014-06-13
Publication date: 2016-01-12
Anticipated expiration: 2034-06-13
Also published as: US20150365348A1; JP6312536B2

Abstract

【課題】１ユーザーが複数台の端末から同じアプリケーションの機能を利用する場合においても、利便性を損なわずに、ＷｅｂサービスＡＰＩをアプリケーション開発者が容易に利用できる仕組みを提供する。
【解決手段】複数台の端末から呼出したＡＰＩの呼出し回数の集計値が、ユーザー識別子に関連付くＡＰＩの呼出し上限数以下の場合に、クライアントによるサービスの利用を認可する。
【選択図】図３

Description

本発明は、リソースへのアクセスを管理するシステム、方法、サーバーシステム、およびプログラムに関する。

近年、スマートフォンやタブレットコンピューターといったモバイル端末が急速に普及している。このようなモバイル端末に対して、インターネット上のアプリケーションストアなどを通じて、アプリケーション開発者が開発したアプリケーションを容易に公開・販売できる仕組みが用意されている。また、モバイル端末向けのアプリケーション開発において、モバイル端末単体では実現が困難な機能を、インターネット上のＷｅｂサービスとして提供し、Ｗｅｂサービス利用料金を徴収するといったインターネットサービス事業も出現してきている。特に、サーバーサイドのコード開発・サーバー運用が不要で、ＷｅｂサービスＡＰＩを利用した分だけ課金するというＢａａＳ（ＢａｃｋｅｎｄａｓａＳｅｒｖｉｃｅ）というＷｅｂサービス提供形態が出てきている。

ＢａａＳのようなＷｅｂサービスを利用してアプリケーションを開発・運用する場合、ＢａａＳと利用契約するのはアプリケーション開発者である。例えば、ＢａａＳが、モバイル端末で表示できない電子文書ファイルを別の電子文書ファイルフォーマットに変換するＡＰＩを提供していたとする。開発者は、アプリケーション内でフォーマット変換の必要なときに、ＢａａＳのＡＰＩを呼び出すようにアプリケーションを実装しておけばよい。一方で、エンドユーザーには、フォーマット変換はアプリケーションの一機能として見えるが、そのバックエンドで動作するＢａａＳについては存在を意識する必要がない。アプリケーション開発者は、アプリケーションストアなどを通じて、エンドユーザーからアプリケーション購入料金・使用料金などの収入を得ることができる。一方で、アプリケーション開発者は、配布したアプリケーションから利用された分のＷｅｂサービス利用料金をＢａａＳに支払う必要がある。なお、リクエスト数を計測し、リクエストを制限する技術として特許文献１がある。

特開２０１１−７０４３５

アプリケーションの提供形態の１つとして、アプリケーションを無料で配布し、無料で使用している間はアプリケーションの機能を制限しておき、エンドユーザーが有料の機能を購入したらアプリケーションの機能の制限を解除する、という提供形態が考えられる。アプリケーションの機能を、ＢａａＳのＡＰＩによって実現している場合、無料で使用中はＡＰＩ利用回数の上限数を少なく提供し、有料になったらＡＰＩ利用回数の上限数を引き上げることによって機能制限を解除することができる。ここで、１エンドユーザーが複数台の端末を持っている場合、１台目の端末でアプリケーションの機能を購入後、２台目以降の端末でも同じアプリケーションの機能が自動的に利用可能となるアプリケーションストア等の仕組みが存在する。例えば、無料使用中は端末１台からのＡＰＩ利用回数を１０回に制限し、アプリケーションの機能を購入後、ＡＰＩ利用回数の上限数を３００回に引き上げる、というケースを想定する。前述のように、１エンドユーザーが複数台の端末を持っており、１回の購入で全ての端末のアプリケーションの機能を利用可能とすることができる場合、次のような課題がある。２台目以降の端末のＡＰＩ利用回数の上限数を一律３００回に引き上げると、３００回×端末数の分だけＢａａＳからＡＰＩ課金がされてしまう。アプリケーションの機能購入時に、エンドユーザーから料金収入を得られる機会は１回なので、端末台数が多いほどアプリケーション開発者の料金負担が増えてしまう。

本発明が解決する目的は、１エンドユーザーが複数台の端末から同じアプリケーションの機能を利用する場合においても、ＢａａＳの利便性を損なわずに、ＡＰＩをアプリケーション開発者に容易に利用してもらえる仕組みを提供することである。

本発明の一実施形に係るシステムは、クライアントから利用可能なサービスを備えるサーバーシステムと、前記サービスを利用するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を呼び出すことで前記サービスを利用するクライアントとを含むシステムであって、前記クライアントに対して一意に割り当てられたクライアント識別子を基に、正規なクライアントであるか否かを判断する認証手段と、前記認証手段により正規なクライアントであると判断されたことに応じて、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を発行する発行手段と、前記クライアントが前記ＡＰＩを呼び出す際に送信する前記権限情報を基に、前記クライアントによる前記サービスの利用を認可する認可手段と、前記権限情報とユーザー識別子とを関連付け、前記ユーザー識別子と前記ＡＰＩの呼出し上限数とを関連付けて保存する保存手段と、を有し、前記認可手段は、前記クライアントから送信された前記権限情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数以下の場合に、前記クライアントによる前記サービスの利用を認可することを特徴とする。

１エンドユーザーが複数台の端末から同じアプリケーションの機能を利用する場合においても、ＢａａＳの利便性を損なわずに、ＡＰＩをアプリケーション開発者に容易に利用してもらえる仕組みを提供できる。

本発明を実施するためのシステム構成およびネットワーク構成情報処理機能ハードウェア構成図本システムのソフトウェア構成説明図テナント管理テーブル、ユーザー管理テーブルＡＰＩ課金メニュー管理テーブル（１）、ＡＰＩ課金メニュー管理テーブル（２）、テナント属性情報管理テーブルクライアント証明書管理テーブル、クライアント管理テーブル、認可トークン管理テーブル、ＡＰＩ呼出し回数管理テーブルＷｅｂサービス利用登録フロー説明図利用登録画面、ＡＰＩ利用設定画面クライアント登録処理フロー、認可トークン発行フロー説明図（ＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔ）リソース要求ＡＰＩ処理フロー説明図（１）ＡＰＩ呼出し上限数への加算処理フロー説明図ＡＰＩ呼出し上限数への加算選択ＵＩ、コスト回収選択ＵＩユーザー登録処理フロー説明図認可トークン発行フロー説明図（ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔ）ログイン画面、ユーザー登録画面、認可確認画面リソース要求ＡＰＩ処理フロー説明図（２）

以下、本発明を実施するための最良の形態について図面を用いて説明する。

本実施の形態においては、Ｗｅｂサービスからアプリケーションに対してセキュアなＡＰＩ認可手段を提供するために、インターネット標準であるＯＡｕｔｈ２．０に準拠した構成とする。ＯＡｕｔｈ２．０のうち、ＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔおよびＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔによるＡＰＩ認可手段を提供する。モバイル端末向けアプリケーションに対して、個々の端末を識別し、端末またはユーザーごとにアクセス制御を実施可能とするために、前記２種類のＡＰＩ認可手段を提供する。なお、ＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）は、Ｗｅｂサービスを利用するために呼出すためのインターフェースである。

図１は、本発明を実施するためのシステム構成およびネットワーク構成の一例を示している。１０１は、インターネットもしくはイントラネットなどのネットワークであり、ネットワークに接続された機器同士は互いに通信可能である。１０２はルータやスイッチなど、ネットワークどうしを接続するネットワーク機器である。１０３はネットワーク間の通信許可の制御を行うファイアウォールである。１０５はＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）である。１０５は、コンピューター等の機器を接続する末端のネットワークであるが、有線通信のネットワークに限らず、無線ＬＡＮや携帯電話通信ネットワークなどの無線通信網の場合もある。１１１は認可サーバーである。１１２はリソースサーバーである。１２１、１２２はクライアントコンピューターである。クライアントコンピューター１２１、１２２としては、パーソナルコンピューター、タブレットコンピューター、スマートフォンなどの種別が存在する。

図２は、認可サーバー１１１、リソースサーバー１１２、クライアントコンピューター１２１、１２２の情報処理機能のモジュール構成図を示している。２０１はユーザーインターフェースであり、ディスプレイ、キーボード、マウス、タッチパネルなどによる、情報の入出力を行う。これらのハードウェアを備えないコンピューターは、リモートデスクトップやリモートシェルなどにより、他のコンピューターから接続・操作することも可能である。２０２はネットワークインターフェースであり、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行う。２０４は組込済みプログラムおよびデータが記録されているＲＯＭである。２０５は一時メモリ領域のＲＡＭである。２０６はＨＤＤに代表されるような二次記憶装置である。２０３はＣＰＵであり、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行する。各部は入出力インターフェース２０７を介して接続されている。

図３は、本システムのソフトウェア構成を示している。認可サーバー１１１は、ＨＴＴＰサーバーモジュール３０１、Ｗｅｂアプリケーション３０２、データベース３０５を備える。ＨＴＴＰサーバーモジュール３０１は、クライアントからのＷｅｂアクセスの要求と応答の通信を管理・制御し、必要に応じて、要求をＷｅｂアプリケーション３０２に転送する。Ｗｅｂアプリケーション３０２は、ブラウザーにＨＴＭＬ等のＷｅｂドキュメントや操作画面を提供するＷｅｂＵＩ３０３と、ＲＥＳＴに代表されるようなＷｅｂサービスＡＰＩにより認可処理を受け付ける認可ＡＰＩ３０４を備える。データベース３０５は、Ｗｅｂアプリケーション３０２が使用するデータを格納する。Ｗｅｂアプリケーション３０２からの要求に応じて、データベース３０５は各種テーブルのレコードを追加・読出・更新・削除する。

リソースサーバー１１２は、ＨＴＴＰサーバーモジュール３１１、Ｗｅｂアプリケーション３１２を備える。ＨＴＴＰサーバーモジュール３１１は、クライアントからのＷｅｂアクセスの要求と応答の通信を管理・制御し、必要に応じて、要求をＷｅｂアプリケーション３１２に転送する。Ｗｅｂアプリケーション３１２は、ＲＥＳＴに代表されるようなＷｅｂサービスＡＰＩにより各種の処理を受け付けるＡＰＩ３１３を備える。ＡＰＩ３１３は、リソースサーバーが提供する機能に必要な処理を実行して、クライアントからのＡＰＩ呼出し要求に対する応答を生成し、ＨＴＴＰサーバーモジュール３１１を介してクライアントに応答を返す。この機能のことをＷｅｂサービスと呼ぶ。なお、リソースサーバーが提供する機能としては様々なものが有り得るので、Ｗｅｂアプリケーション３１２のみでは実行できない場合は、不図示の他のアプリケーションや他のサーバーに機能の実行を依頼して、応答を得ることも可能である。

なお、本実施例における認可サーバー１１１、およびリソースサーバー１１２は同じセキュリティドメイン内に配置されたサーバー群であり、本発明においてサーバーシステムと称した場合は、認可サーバー１１１、およびリソースサーバー１１２の少なくとも２台のサーバーが含まれることを意味する。なお、サーバーシステムは、認可サーバー１１１とリソースサーバー１１２の複数台から構成される例を説明したが、２つのサーバーの機能を備えた１台のサーバーであっても良い。

ブラウザー３２１は、クライアントコンピューター１２１にインストールされて実行可能である。ブラウザー３２１は、ＷｅｂＵＩ３０３が提供するＨＴＭＬ等のＷｅｂドキュメントや操作画面を受信して表示し、ユーザーによる操作結果などをＷｅｂＵＩ３０３に送信する。アプリケーション３３１およびブラウザー３３２は、クライアントコンピューター１２２にインストールされて実行可能である。アプリケーション３３１は、ＡＰＩ３１３にアクセスして、リソースサーバー１１２が提供する各種機能を利用可能である。ブラウザー３３２は、認可操作時の一部ステップにおいて、ＨＴＭＬ等のＷｅｂドキュメントや操作画面を受信して表示し、ユーザーによる操作結果などを認可ＡＰＩ３０４に送信する。

ここで、図３の構成において、各モジュールがＯＡｕｔｈ２．０におけるどのロールに当たるかを説明する。認可サーバー１１１が、ＯＡｕｔｈ２．０の“ＡｕｔｈｏｒｉｚａｔｉｏｎＳｅｒｖｅｒ”ロールである。リソースサーバー１１２が、ＯＡｕｔｈ２．０の“ＲｅｓｏｕｒｃｅＳｅｒｖｅｒ”ロールである。ＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔ利用時には、アプリケーション３３１が、ＯＡｕｔｈ２．０の“Ｃｌｉｅｎｔ”ロールおよび“ＲｅｓｏｕｒｃｅＯｗｎｅｒ”ロールである。ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔ利用時には、アプリケーション３３１が、ＯＡｕｔｈ２．０の“Ｃｌｉｅｎｔ”ロールである。また、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔ利用時には、アプリケーション３３１を使用してリソースサーバー１１２の機能・データを利用するユーザーが“ＲｅｓｏｕｒｃｅＯｗｎｅｒ”ロールである。以降の説明では、各モジュールは前記のＯＡｕｔｈ２．０のロールとしてＡＰＩ認可フローを実行する。また、本文中あるいは図中における「クライアント」とは、ＯＡｕｔｈ２．０の“Ｃｌｉｅｎｔ”ロールとして、認可ＡＰＩ３０４およびＡＰＩ３１３などのＷｅｂサービスＡＰＩの要求元として動作するアプリケーション３３１の事を指す。無論、アプリケーション３３１は端末毎に存在するため、本システム内には複数のクライアントが存在する。

図４、図５、図６は、認可サーバー１１１内のデータベース３０５の各種テーブルを示している。４００はテナント管理テーブルである。４０１はテナントＩＤを格納するカラムである。テナントＩＤ４０１は、認可サーバーおよびリソースサーバーによって提供するＷｅｂサービスが、様々な組織・個人などに利用される場合、セキュアにリソースを分離するための単位である。このようなシステムは一般にマルチテナントシステムと呼ばれる。

４１０はユーザー管理テーブルである。４１１はユーザーが所属するテナントＩＤを格納するカラムである。４１２はユーザーＩＤを格納するカラムである。４１３はユーザーのメールアドレスを格納するカラムである。４１４はユーザーのパスワードを格納するカラムである。４１５はユーザーが所属するテナントにおいて付与されている権限を格納するカラムである。ここでは、権限４１５として、テナント内のすべてのデータに対する権限を持つテナント管理者と、制限された権限のみを持つ一般というユーザー権限があるものとする。

５００および５１０はＡＰＩ課金メニュー管理テーブルである。５０１、５１１は課金メニューＩＤを格納するカラムである。５０２、５１２は課金メニュー名を格納するカラムである。５０３は１クライアントＩＤあたりＡＰＩ呼出し上限数を格納するカラムである。５１３は１ユーザーＩＤあたりＡＰＩ呼出し上限数を格納するカラムである。５０４、５１４は課金ユニットの単価を格納するカラムである。本実施例では、５０３、５１３で定義された１クライアントＩＤまたは１ユーザーＩＤあたりＡＰＩ呼出し上限数を利用する権利を１課金ユニットとして換算し、利用した課金ユニット数分を課金する例を示している。しかしながら、課金形態は多様なものが有り得るので、ここでは一例を示すに留める。

５２０はテナント属性情報管理テーブルである。５２１はテナントＩＤを格納するカラムである。５２２はクライアントＩＤまたはユーザーＩＤのどちらのＩＤを対象とするレコードであるかを示す対象ＩＤ種別を格納するカラムである。５２３はそのテナントが選択している課金メニューＩＤを格納するカラムである。５２４は１クライアントＩＤまたはユーザーＩＤあたりＡＰＩ呼出し上限数の初期値を格納するカラムである。５２５はＡＰＩ呼出し上限数への加算を許可／不許可の設定値を格納するカラムである。５２６は１クライアントＩＤまたは１ユーザーＩＤあたりＡＰＩ呼出し上限数への加算数を格納するカラムである。５２７は、認可フロー切替時動作モードを格納するカラムである。

６００はクライアント証明書管理テーブルである。６０１はクライアント証明書のシリアル番号を格納するカラムである。６０２は証明書の発行者を格納するカラムである。６０３は証明書の主体者を格納するカラムである。６０４は証明書の有効期間の開始日時を格納するカラムである。６０５は証明書の有効期間の終了日時を格納するカラムである。６０６はテナントマスターＤＮ（ＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅ）を格納するカラムである。

６１０はクライアント管理テーブルである。６１１はクライアントとなるアプリケーション３１１を一意に識別するためのクライアント識別子を意味するクライアントＩＤを格納するカラムである。６１２はクライアントのシークレットを保存するカラムである。６１３はクライアントが所属するテナントＩＤを格納するカラムである。６１４はクライアントの種別を格納するカラムである。クライアントの種別６１４として、テナントの管理権限を持つマスターと制限された権限のみを持つ一般のクライアント権限がある。６１５はクライアントのＤＮを格納するカラムである。６１６は認可確認後のリダイレクトＵＲＬを格納するカラムである。クライアント管理テーブル６１０によって、ＯＡｕｔｈ２．０のＣｌｉｅｎｔを個別に識別して管理する。

６２０は認可トークン管理テーブルである。６２１はトークン種別を格納するカラムである。６２２は認可トークンＩＤを格納するカラムである。６２３は認可トークンの有効期限を格納するカラムである。６２４はリフレッシュトークンＩＤを格納するカラムである。６２５はリフレッシュトークンの有効期限を格納するカラムである。６２６は認可トークンの発行対象のクライアントＩＤを格納するカラムである。６２７は認可トークンの所有者を示すオーナーＩＤを格納するカラムである。

６３０はＡＰＩ呼出し回数管理テーブルである。６３１はユーザーを一意に識別するためのユーザー識別子を意味するユーザーＩＤを格納するカラムであり、１人のユーザーに対応する形で１つのユーザーＩＤが存在する。６３２はクライアントＩＤを格納するカラムである。６３３はＡＰＩ呼出し回数集計の対象年月を格納するカラムである。本実施例では月毎にＡＰＩ呼出し回数を集計するが、集計の期間は年や週など別の単位や期間でもよい。６３４はＡＰＩ呼出し回数上限数の設定値を格納するカラムである。６３５は実際にクライアントから呼び出されたＡＰＩ呼出し回数を格納するカラムである。６３６はクライアントからＡＰＩが呼び出された最終アクセス日時を格納するカラムである。

図７、図８を用いて、認可サーバー１１１、リソースサーバー１１２によって提供するＷｅｂサービスに利用登録するための処理フローを説明する。利用登録するユーザーは、アプリケーション３３１の開発者を主たるユーザーとする。ユーザーは、ブラウザー３２１を使用して、ＷｅｂＵＩ３０３が提供する利用登録画面８００を取得して、表示する（Ｓ７０１、７０２、７０３）。８０１はユーザーのメールアドレスやパスワードを入力する利用者情報入力フィールドである。８０２、８０３はそれぞれクライアントＩＤ単位・ユーザーＩＤ単位の料金メニューの選択フィールドである。ＷｅｂＵＩ３０３は、ＡＰＩ課金メニュー管理テーブル５００、５１０を読み出して、８０２、８０３の料金メニューの選択肢を提供する。８０４は利用登録要求を送信するボタンである。ユーザーが利用者情報を８０１に入力して、料金メニューを８０２、８０３で選択して、登録ボタン８０４を押下して、利用登録要求をＷｅｂＵＩ３０３に送信する（Ｓ７０４）。

ＷｅｂＵＩ３０３は、まずテナント管理テーブル４００にテナントＩＤを新規追加する。ＷｅｂＵＩ３０３は、入力された利用者情報に従って、ユーザー管理テーブル４１０に、ユーザーのレコードを追加し、権限４１５にはテナント管理者を付与する。これにより、このユーザーは作成されたテナントの設定値などを変更することができる。ＷｅｂＵＩ３０３は、テナント属性管理テーブル５２０に、作成されたテナントＩＤを５２１に、８０２および８０３で選択された課金メニューＩＤを５２３に格納する。また、クライアントＩＤ・ユーザーＩＤどちらの設定情報であるかを識別するために、５２２にクライアントＩＤまたはユーザーＩＤの種別を格納する。ＷｅｂＵＩ３０３は、クライアント管理テーブル６１０に、種別６１４がマスターのクライアントを１つ作成する。また、前記作成したマスタークライアントのＤＮ６１５と同一のテナントマスターＤＮ６０６を持つクライアント証明書を作成し、その他の証明書情報を６０１、６０２、６０３、６０４、６０５に格納する（Ｓ７０５）。これらのテナントＩＤをはじめとする登録処理が完了すると、ブラウザー３２１に登録完了を応答する（Ｓ７０６）。

次に、ブラウザー３２１は、ＷｅｂＵＩ３０３からＡＰＩ利用設定画面８１０を取得して表示する（Ｓ７０７、７０８、７０９）。８１１は１クライアントＩＤあたりのＡＰＩ呼出し上限数の初期値を入力するフィールドである。８１２はクライアントからの１クライアントＩＤあたりのＡＰＩ呼出し上限数の加算の許可／不許可を選択するチェックボックスである。８１３は１クライアントＩＤあたりのＡＰＩ呼出し上限数への加算数を入力するフィールドである。８１４は１ユーザーＩＤあたりのＡＰＩ呼出し上限数の初期値を入力するフィールドである。８１５はクライアントからの１ユーザーＩＤあたりのＡＰＩ呼出し上限数の加算の許可／不許可を選択するチェックボックスである。８１６は１ユーザーＩＤあたりのＡＰＩ呼出し上限数への加算数を入力するフィールドである。８１７はＡＰＩ認可フロー切替時の設定を選択するフィールドである。８１８はＡＰＩ利用設定の要求を送信するボタンである。ユーザーがＡＰＩ利用設定画面８１０にて、各設定値を入力・選択して、設定ボタン８１８を押下して、設定要求をＷｅｂＵＩ３０３に送信する（Ｓ７１０）。

ＷｅｂＵＩ３０３は、テナント属性情報管理テーブル５２０の５２４、５２５、５２６に、ＡＰＩ利用設定画面８１０にて入力された値をクライアントＩＤ・ユーザーＩＤ種別ごとに格納する。また、ＷｅｂＵＩ３０３は、選択フィールド８１７の選択値を、対象種別ＩＤ５２２がユーザーＩＤであるレコードの認可フロー切替時動作モード５２７に格納する（Ｓ７１１）。ＷｅｂＵＩ３０３は、ブラウザー３２１に設定完了を応答する（Ｓ７１２）。次に、ブラウザー３２１は、クライアント証明書取得要求をＷｅｂＵＩ３０３に送信する（Ｓ７１３）。ＷｅｂＵＩ３０３は、前述の作成したクライアント証明書を読み出して、ブラウザー３２１に応答する（Ｓ７１４、７１５）。

次に、図９を用いて、クライアントの登録処理、ＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔによる認可トークンの発行処理のフローを説明する。アプリケーション３３１には、あらかじめ前述の取得したクライアント証明書がアプリケーション３３１の開発者によって組み込まれており、そのアプリケーション３３１がクライアントコンピューター１２２に配布される。アプリケーション３３１は、ＨＴＴＰサーバーモジュール３０１にクライアント登録要求を送信する（Ｓ９０１）。クライアント登録要求には、後述する認可コード発行時に利用するリダイレクトＵＲＬを含めることも可能である。ＨＴＴＰサーバーモジュール３０１は、クライアント登録要求に対して、クライアント証明書を呼出元に要求する。アプリケーション３３１はクライアント証明書をＨＴＴＰサーバーモジュール３０１に送信し、ＨＴＴＰサーバーモジュール３０１は受信したクライアント証明書が有効であれば、クライアント登録要求を認可ＡＰＩ３０４に転送する（Ｓ９０２、Ｓ９０３）。

本実施例では、アプリケーション３３１が認可サーバー１１１の正当なクライアントであることを認証するためにクライアント証明書を用いているが、Ｂａｓｉｃ認証やＤｉｇｅｓｔ認証など他の認証方式を用いることも可能である。認可ＡＰＩ３０４は、受信したクライアント証明書から得られたシリアル番号６０１を用いて、クライアント証明書管理テーブル６００を検索し、テナントマスターＤＮ６０６を特定する。さらに、認可ＡＰＩ３０４は、クライアント管理テーブル６１０を検索し、前記特定したテナントマスターＤＮ６０６と同じＤＮ６１５を持つレコードを取得する（Ｓ９０４）。

認可ＡＰＩ３０４は、前記取得したレコードのクライアント種別６１４がマスターであることを検証し、テナントＩＤ６１３を読み出す。認可ＡＰＩ３０４は、クライアント管理テーブルにレコードを追加し、ＵＵＩＤに代表されるようなユニークなＩＤを採番してクライアントＩＤ６１１に格納し、前記読み出したテナントＩＤを６１３に格納する。これにより、アプリケーション３３１に対し、一意な識別番号が割り当てられることになる。６１２にも自動生成した十分な文字列長のシークレットを格納し、種別６１４には一般を格納する。また、クライアント登録要求にリダイレクトＵＲＬが含まれている場合には、クライアント管理テーブルの６１６に格納する。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０にレコードを追加し、前記採番されたクライアントＩＤを６３２に格納する。また、６３３には現在の年月を格納し、６３４にはテナント属性情報管理テーブル５２０に設定されている対象種別ＩＤ５２２がクライアントＩＤである該当テナントの１クライアントあたりＡＰＩ呼出し上限数の初期値５２４を格納する。６３５には初期値０を格納する（Ｓ９０５）。

認可ＡＰＩ３０４は、アプリケーション３３１にクライアント登録要求の応答として、生成したクライアントＩＤとシークレットを返信する（Ｓ９０６）。アプリケーション３３１は、受信したクライアントＩＤとシークレットを、後で読み出し可能なように記憶領域に保存しておく（Ｓ９０７）。以上がアプリケーション３３１をクライアントとして認可サーバー１１１に登録する処理フローであり、認可サーバー１１１が発行したクライアント証明書を持つ正当なクライアントのみが認可サーバー１１１に登録できる。

アプリケーション３３１は、前述の取得したクライアントＩＤ・シークレットを使用して、認可ＡＰＩ３０４に認可トークン要求を送信する（Ｓ９０８）。認可ＡＰＩ３０４は、受信したクライアントＩＤ・シークレットがクライアント管理テーブル６１０に存在し、一致するか否かを検証することで、要求元のアプリケーションが正規なクライアントであるか否かを判断する認証処理を行う（Ｓ９０９）。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０を、クライアントＩＤ６３２が要求元のクライアントＩＤかつユーザーＩＤ６３１がＮＵＬＬで検索し、当月のＡＰＩ呼出し回数６３５とＡＰＩ呼出し回数上限数の設定値６３４を取得する（Ｓ９１０）。認可ＡＰＩ３０４は、当月のＡＰＩ呼出し回数６３５がＡＰＩ呼出し回数上限数の設定値６３４より少ないかどうかを判定する（Ｓ９１１）。

ステップ９１１の判定がＹｅｓの場合、認可トークン管理テーブル６２０にレコードを追加し、認可トークンを生成する。トークン種別６２１に認可トークンを、６２２に採番した認可トークンＩＤを、６２３に認可トークン有効期限を、６２６、６２７に要求元クライアントＩＤを格納する（Ｓ９１２）。認可ＡＰＩ３０４は、生成した認可トークンの認可トークンＩＤ６２１および有効期限６２３をアプリケーション３３１に応答する（Ｓ９１３）。ステップ９１１の判定がＮｏの場合、認可ＡＰＩ３０４はＡＰＩ呼出し回数上限到達を通知するエラーをアプリケーション３３１に応答する（Ｓ９１４）。

クライアントＩＤ登録後、初回の認可トークン要求時は、前述のステップＳ９１０、９１１のＡＰＩ呼出し回数上限到達判定は実質的には必要なく、認可トークンをアプリケーション３３１に発行してよい。しかしながら、認可トークンには有効期限６２３があるため、有効期限切れ後は、アプリケーション３３１はステップＳ９０８からの処理を再度実行して、別の認可トークンを再度要求する必要がある。２回目以降の認可トークン要求時に、前述のステップＳ９１０、９１１のＡＰＩ呼出し回数上限到達判定をして、ＡＰＩ呼出し回数が既に上限に到達している場合は、認可トークンは発行されない。発行された認可トークンを用いて、認可されたＡＰＩを呼び出すのがＯＡｕｔｈ２．０のＡＰＩ認可フローである。認可トークンは、クライアントであるアプリケーション３３１がＷｅｂサービスを利用する権限を有していることを証明するための権限情報である。そのため、ＡＰＩ呼出し回数が既に上限に到達している場合は、アプリケーション３３１からのリソースサーバー１１２のＡＰＩ３１３への呼出しが抑止される。これにより、リソースサーバー１１２への通信トラフィック軽減、ＣＰＵ処理の軽減などの効果を得ることができる。

次に図１０、１６を用いて、ＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔで取得した認可トークンを使用してリソースサーバー１１２のＡＰＩ３１３を利用する処理フローを説明する。アプリケーション３３１は、ユーザーからのＷｅｂサービスの利用を開始する指示を受け付けたことに応じて、取得した認可トークンＩＤをパラメーターとしてリソース要求ＡＰＩ呼出し要求をＡＰＩ３１３に送信する（Ｓ１００１）。ＡＰＩ３１３は、認可ＡＰＩ３０４に、受信した認可トークンの検証要求を送信する（Ｓ１００２）。認可ＡＰＩ３０４は、認可トークン管理テーブル６２０を検索して、受信した認可トークンの認可トークンＩＤが６２２に存在し、かつ、現在日時が有効期限６２３以内であることを検証する。また、受信した認可トークンのオーナーＩＤ６２７を取得する。

さらに、認可トークンの発行先のクライアントＩＤ６２６が、クライアント管理テーブル６１０に存在することを確認して、該当のクライアントＩＤが有効であることを確認する（Ｓ１００３）。認可ＡＰＩ３０４は、ステップＳ１００３の検証処理の結果、受信した認可トークンが有効であるかを判定する（Ｓ１００４）。ステップＳ１００４の判定がＮｏの場合、認可ＡＰＩ３０４は、認可トークン検証結果としてトークン無効エラーをＡＰＩ３１３に応答する（Ｓ１００５）。ＡＰＩ３１３は、アプリケーション３３１にリソース要求ＡＰＩの応答として、トークン無効エラーを返信する（Ｓ１００６）。ステップＳ１００４の判定がＹｅｓの場合、ステップＳ１６０１へ進む。認可ＡＰＩ３０４は、受信した認可トークンのオーナーＩＤがクライアントＩＤ、ユーザーＩＤのどちらであるかを判定する（Ｓ１６０１）。ＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔの場合は、ステップＳ１６０１の判定はクライアントＩＤとなるので、ステップＳ１６０２に進む。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０を認可トークン発行先のクライアントＩＤかつユーザーＩＤはＮＵＬＬで検索し、当月のＡＰＩ呼出し回数６３５とＡＰＩ呼出し回数上限数の設定値６３４を取得する（Ｓ１６０２）。

認可ＡＰＩ３０４は、当月のＡＰＩ呼出し回数６３５がＡＰＩ呼出し回数上限数の設定値６３４より少ないかどうかを判定する（Ｓ１６０３）。ステップＳ１６０３の判定がＹｅｓの場合、ＡＰＩ呼出し回数管理テーブル６３０の当月のＡＰＩ呼出し回数６３５に１を加算する（Ｓ１６０４）。認可ＡＰＩ３０４は、ＡＰＩ３１３に認可トークン検証結果が成功（ＯＫ）であることを応答する（Ｓ１０１０）。ＡＰＩ３１３は、ステップＳ１００１で受信したリソース要求の処理を実行し、応答を生成する（Ｓ１０１１）。ＡＰＩ３１３は、リソース要求ＡＰＩ呼出しに対する応答として、ステップＳ１０１１で生成したリソース要求応答およびＡＰＩ呼出し成功（ＯＫ）をアプリケーション３３１に返信する（Ｓ１０１２）。ステップＳ１６０３の判定がＮｏの場合、認可ＡＰＩ３０４はＡＰＩ３１３に認可トークン検証応答として、ＡＰＩ呼出し回数上限到達エラーを返信する（Ｓ１０１３）。ＡＰＩ３１３は、アプリケーション３３１に、リソース要求ＡＰＩの応答として、ＡＰＩ呼出し回数上限到達エラーを返信する（Ｓ１０１４）。

次に、図１１、図１２を用いて、１クライアントＩＤあたりのＡＰＩ呼出し回数が上限に達してしまったときに、ＡＰＩ呼出し上限数に加算する処理フローを説明する。アプリケーション３３１は、前述のステップＳ９１４またはステップＳ１０１４で、自身のクライアントＩＤからのＡＰＩ呼出し回数が上限に達してしまったことを検知する（Ｓ１１０１）。ＡＰＩ呼出し回数の上限到達を検知した場合、ＡＰＩ呼出し上限数加算を選択するＵＩ１２００を表示する（Ｓ１１０２）。アプリケーション３３１は、ＵＩ１２００にて、ユーザーが上限の加算を選択したかどうかを判定する（Ｓ１１０３）。ステップＳ１１０３の判定がＮｏの場合は処理を終了する。ステップＳ１１０３の判定がＹｅｓの場合、アプリケーション３３１はコスト回収処理を実施するＵＩ１２１０を表示し、上限を追加するコスト回収の同意を選択させる（Ｓ１１０４）。

アプリケーション３３１は、ユーザーがコスト回収に同意し、アプリケーションのユーザーから、アプリケーションの開発者または提供者へのコスト回収処理に成功したかどうかを判定する（Ｓ１１０５）。ステップＳ１１０５の判定がＮｏの場合、処理を終了する。ステップＳ１１０５の判定がＹｅｓの場合、即ち、ＡＰＩ呼出し上限数を加算することが許可された場合、アプリケーション３３１は、ＡＰＩ３０４に対して、クライアントＩＤ・シークレットを指定して、ＡＰＩ呼出し上限数に加算する設定ＡＰＩを呼び出す（Ｓ１１０６）。認可ＡＰＩ３０４は、前述のステップＳ９０９同様、要求元のクライアントを認証する（Ｓ１１０７）。

認可ＡＰＩ３０４は、クライアント管理テーブル６１０から、クライアントＩＤ６１１が要求元のクライアントＩＤと一致するレコードを検索し、クライアントＩＤが所属するテナントＩＤを特定する。認可ＡＰＩ３０４は、テナント属性情報管理テーブル５２０の前記テナントＩＤかつ対象ＩＤ種別５２２がクライアントＩＤのレコードを読みだして、ＡＰＩ呼出し上限数への加算の許可設定５２５を取得する。許可設定５２５がＦＡＬＳＥの場合は、認可ＡＰＩ３０４は、アプリケーション３３１に不図示のエラー応答を返却する。認可ＡＰＩ３０４は、テナント属性情報管理テーブル５２０の前記テナントＩＤのレコードを読みだして、対象ＩＤ種別５２２がクライアントＩＤである、１クライアントＩＤあたりＡＰＩ呼出し上限数への加算値５２６を取得する。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０内の６３２が要求元のクライアントＩＤかつユーザーＩＤがＮＵＬＬで、対象年月６３２が現在の年月のレコードを取得する。認可ＡＰＩ３０４は、前記取得したレコードのＡＰＩ呼出し上限数の設定値６３４に、前述の取得した加算値５２６を加算する（Ｓ１１０８）。これにより、ＡＰＩ呼出し上限数の設定値６３４には、新しい上限数が設定される。認可ＡＰＩ３０４は、ＡＰＩ呼出し上限数に加算する設定ＡＰＩに対する応答として、アプリケーション３３１に成功（ＯＫ）を返す。

次に、図１３、図１４、図１５を用いて、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔによる認可トークンの発行処理のフローを説明する。アプリケーション３３１は、ユーザー登録画面１５１０を表示する（Ｓ１３０１）。ユーザー登録画面１５１０は、ログイン画面１５００内のユーザー登録画面へのリンク１５０３などから表示させてもよい。ユーザー登録ボタン１５１２が押下されると、アプリケーション３３１は、ユーザーが入力したメールアドレス、パスワード等のユーザー登録に必要な情報を入力フィールド１５１１から取得する。アプリケーション３３１は、取得したメールアドレス、パスワード等の情報および前述のステップＳ９０７で保存しているクライアントＩＤ、シークレットをパラメーターとして、ユーザー登録ＡＰＩ呼出し要求を認可ＡＰＩ３０４に送信する（Ｓ１３０２）。認可ＡＰＩ３０４は、受信したクライアントＩＤ、シークレットを用いて、前述のステップＳ９０９同様、要求元のクライアントを認証する（Ｓ１３０３）。認可ＡＰＩ３０４は、クライアント管理テーブル６１０から、要求元クライアントＩＤのテナントＩＤ６１３を特定する。認可ＡＰＩ３０４は、ユーザー管理テーブル４１０にレコードを追加し、前記特定したテナントＩＤを４１１に、採番したユーザーＩＤを４１２に、受信したメールアドレス、パスワードを４１３、４１４に、権限４１５には一般を格納する（Ｓ１３０４）。認可ＡＰＩ３０４は、ユーザー登録処理に成功したら、ユーザー登録ＡＰＩ呼出し結果としてＯＫの応答をアプリケーション３３１に返す（Ｓ１３０５）。

アプリケーション３３１は、まずＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔによって発行済の認可トークンを保持しているかを確認する（Ｓ１４０１）。ステップＳ１４０１の判定がＹｅｓの場合、ステップＳ１４２２に進む。ステップＳ１４０１の判定がＮｏの場合、アプリケーション３３１は、クライアントＩＤ、リダイレクトＵＲＬをパラメーターとして認可要求を認可ＡＰＩ３０４に送信する（Ｓ１４０２）。認可ＡＰＩ３０４は、受信したクライアントＩＤがクライアント管理テーブル６１０に存在するか確認し、さらに、受信したリダイレクトＵＲＬが６１６に登録済みのものと一致するかを確認する（Ｓ１４０３）。ステップＳ１４０３の検証に成功した場合、認可ＡＰＩ３０４は、ログイン画面へのリダイレクト要求をアプリケーション３３１に応答する（Ｓ１４０４）。アプリケーション３３１は、後続の画面を表示するために、ブラウザー３３２を呼び出して、リダイレクト先のログイン画面１５００を取得して表示する（Ｓ１４０５）。ログインボタン１５０２が押下されると、ブラウザー３３２は入力フィールド１５０１に入力されたメールアドレス、パスワードをパラメーターとしてログイン要求を認可ＡＰＩ３０４に送信する（Ｓ１４０６）。

認可ＡＰＩ３０４は、ユーザー管理テーブル４１０を検索し、受信したメールアドレス、パスワードが正しいかを確認し、該当のユーザーのテナントＩＤ４１１、ユーザーＩＤ４１２を取得する（Ｓ１４０７）。ユーザー認証に成功したら、認可ＡＰＩ３０４は、認可確認画面へのリダイレクト要求をブラウザー３３２に応答する（Ｓ１４０８）。ブラウザー３３２は、リダイレクト先の認可確認画面１５２０を取得、表示する（Ｓ１４０９）。認可確認画面１５２０は、認可確認メッセージ１５２１を表示して、どのクライアントがどこのリソースサーバーへのアクセスの認可を求めているのかを明示する。許可ボタン１５２２またはキャンセルボタン１５２３が押下されると、ブラウザー３３２は、許可またはキャンセルどちらかの認可操作の結果を認可ＡＰＩ３０４に送信する（Ｓ１４１０）。

キャンセルを受信した場合は、認可ＡＰＩ３０４は、認可処理をキャンセルし、ブラウザー３３２に不図示のキャンセル画面等を表示して処理を終了する。許可を受信した場合は、認可ＡＰＩ３０４は、認可トークン管理テーブル６２０に、トークン種別６２１が認可コードであるレコードを追加する。新しく採番した認可トークンＩＤを６２２に、認可トークン有効期限を６２３に、ステップＳ１４０２で取得したクライアントＩＤを６２６に、ステップＳ１４０７で取得したユーザーＩＤをオーナーＩＤ６２７に格納する（Ｓ１４１１）。認可ＡＰＩ３０４は、ステップＳ１４０３で受信したリダイレクトＵＲＬに、前記生成した認可コードの認可トークンＩＤを付加して、ブラウザー３３２に応答する（Ｓ１４１２）。この際、リダイレクトＵＲＬをカスタムＵＲＬスキームを使用したアプリケーション３３１のカスタムＵＲＬを設定しておき、アプリケーション３３１に処理を戻すとともに、アプリケーション３３１で認可コードの認可トークンＩＤを取得する（Ｓ１４１３）。

アプリケーション３３１は、クライアントＩＤ、シークレット、認可コードの認可トークンＩＤをパラメーターとして、認可ＡＰＩ３０４に認可トークン要求を送信する（Ｓ１４１４）。認可ＡＰＩ３０４は、前述のステップＳ９０９同様、要求元のクライアントＩＤを認証する（Ｓ１４１５）。認可ＡＰＩ３０４は、認可トークン管理テーブル６２０を検索し、受信した認可コードの認可トークンＩＤに対するレコードが存在するかを確認する。また、該当レコードの認可トークン有効期限６２３が有効期限内であるか、クライアントＩＤ６２６が要求元のクライアントＩＤと一致するかを確認し、オーナーＩＤ６２７に登録されている認可コード発行先のユーザーＩＤを取得する（Ｓ１４１６）。

認可ＡＰＩ３０４は、認可トークン管理テーブル６２０を検索し、トークン種別６２１が認可トークンで、クライアントＩＤ６２６とオーナーＩＤ６２７の両方が要求元のクライアントＩＤと一致するレコードが存在するかを確認する（Ｓ１４１７）。ステップＳ１４１７の判定がＮｏの場合は、ステップＳ１４１９に進む。ステップＳ１４１７の判定がＹｅｓの場合は、認可ＡＰＩ３０４は、ステップＳ１４１７で検索条件に合致したレコードの認可トークン有効期限６２３を強制的に期限切れに書き換える、またはレコードを削除する（Ｓ１４１８）。これにより、同一のクライアントＩＤに対し、ＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔで発行済みの認可トークンが存在する場合、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔに切り替え時に、発行済み認可トークンを無効化できる。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０にレコードを追加する。６３１にステップＳ１４１６で取得したユーザーＩＤを、クライアントＩＤ６３２にＡＬＬを、対象年月６３３に現在の年月を格納する。６３４にはテナント属性情報管理テーブル５２０に設定されている対象種別ＩＤ５２２がユーザーＩＤである該当テナントの１ユーザーＩＤあたりＡＰＩ呼出し上限数の初期値５２４を格納する（Ｓ１４１９）。

認可ＡＰＩ３０４は、認可トークン管理テーブル６２０にトークン種別６２１が認可トークンのレコードを追加する。新しく採番した認可トークンＩＤを６２２に、認可トークン有効期限を６２３に、リフレッシュトークンＩＤを６２４に、リフレッシュトークン有効期限を６２５に格納する。また、要求元のクライアントＩＤを６２６に、ステップＳ１４１６で取得したユーザーＩＤを６２７に格納する。また、認可ＡＰＩ３０４は、認可トークン管理テーブル６２０のステップＳ１４１６で検証した認可コードのレコードを無効化または削除する（Ｓ１４２０）。認可ＡＰＩ３０４は、認可トークンとして認可トークンＩＤ、リフレッシュトークンＩＤおよびそれぞれの有効期限を、アプリケーション３３１に応答する（Ｓ１４２１）。

アプリケーション３３１は、現在保持している認可トークンの有効期限が切れているかどうかを判定する（Ｓ１４２２）。ステップＳ１４２２の判定がＮｏの場合、リソース要求ＡＰＩ呼出しフローＳ１００１に進む。ステップＳ１４２２の判定がＹｅｓの場合、クライアントＩＤ、シークレット、リフレッシュトークンＩＤをパラメーターとして、認可トークン再発行要求を認可ＡＰＩ３０４に送信する（Ｓ１４２３）。認可ＡＰＩ３０４は、Ｓ１４１５同様、クライアントを認証する（Ｓ１４２４）。認可ＡＰＩ３０４は、認可トークン管理テーブル６２０を検索し、受信したリフレッシュトークンＩＤに対するレコードが存在するかを確認する。また、該当レコードのリフレッシュトークン有効期限６２５が有効期限内であるか、クライアントＩＤ６２６が要求元のクライアントＩＤと一致するかを確認し、オーナーＩＤ６２７に登録されている認可トークン発行先のユーザーＩＤを取得する（Ｓ１４２５）。

認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０を検索し、６３１が前記取得したユーザーＩＤで、クライアントＩＤ６３２がＡＬＬ、対象月が現在年月であるレコードのＡＰＩ呼出し上限数の設定値６３４を取得する。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０から、ユーザーＩＤ６３１が前記取得したユーザーＩＤで、かつ対象年月６３３が当月であるレコードのＡＰＩ呼出し回数６３５の集計値を取得する（Ｓ１４２６）。認可ＡＰＩ３０４は、前記取得した当月のＡＰＩ呼出し回数６３５の集計値が、前記取得したＡＰＩ呼出し回数上限数の設定値６３４より少ないかどうかを判定する（Ｓ１４２７）。ステップＳ１４２７の判定が、Ｎｏの場合は、ステップＳ１４３０に進み、認可ＡＰＩ３０４はＡＰＩ呼出し回数上限到達を通知するエラーをアプリケーション３３１に応答する（Ｓ１４３０）。ステップＳ１４２７の判定が、Ｙｅｓの場合は、認可ＡＰＩ３０４は、認可トークン管理テーブル６２０にトークン種別６２１が認可トークンのレコードを追加する。新しく採番した認可トークンＩＤを６２２に、認可トークン有効期限を６２３に、リフレッシュトークンＩＤを６２４に、リフレッシュトークン有効期限を６２５に格納する。また、要求元のクライアントＩＤを６２６に、ステップＳ１４２５で取得したユーザーＩＤを６２７に格納する。また、ステップＳ１４２５で検証済みのリフレッシュトークンＩＤに該当するレコードを無効化、または削除する（Ｓ１４２８）。認可ＡＰＩ３０４は、認可トークンとして認可トークンＩＤ、リフレッシュトークンＩＤおよびそれぞれの有効期限を、アプリケーション３３１に応答する（Ｓ１４２９）。

次に、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔの認可フローで取得した認可トークンを使用したリソース要求ＡＰＩ呼出しフローを説明する。フローは図１０、１６と同様であり、異なる処理のみ以下で説明する。ステップＳ１６０１の判定において、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔの場合は、オーナーＩＤはユーザーＩＤとなるので、ステップＳ１６０５に進む（Ｓ１６０１）。認可ＡＰＩ３０４は、テナント属性情報管理テーブル５２０から、５２１が要求元クライアントＩＤの所属するテナントＩＤで、対象ＩＤ種別５２２がユーザーＩＤであるレコードの認可フロー切替時動作モード５２７を取得する（Ｓ１６０５）。前記取得した動作モード５２７を判定し、モード＝１の場合はステップＳ１６０７に進み、モード＝２の場合はステップＳ１６０９に進む（Ｓ１６０６）。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０を認可トークン発行先のクライアントＩＤかつユーザーＩＤはＮＵＬＬで検索し、当月のＡＰＩ呼出し回数６３５とＡＰＩ呼出し回数上限数の設定値６３４を取得する（Ｓ１６０７）。

認可ＡＰＩ３０４は、当月のＡＰＩ呼出し回数６３５がＡＰＩ呼出し回数上限数の設定値６３４より少ないかどうかを判定する（Ｓ１６０８）。ステップＳ１６０８の判定がＹｅｓの場合、ステップＳ１６０４に進む。ステップＳ１６０８の判定がＮｏの場合、ステップＳ１６０９に進む。認可ＡＰＩ３０４は、ステップＳ１４２６と同様に、次の処理を行う。認可ＡＰＩ３０４は、ユーザーＩＤを対象としたＡＰＩ呼出し上限数の設定値６３４と、ユーザーＩＤ６３１が前記取得したユーザーＩＤで、かつ対象年月６３３が当月であるレコードのＡＰＩ呼出し回数６３５の集計値を取得する（Ｓ１６０９）。なお、図６を基に集計値の例を説明すると、ユーザーＩＤが“Ｕ００２＠ＴＮ００１”に関連付くクライアントＩＤのＡＰＩ呼び出し回数は“２２５”と“６４”になるので、集計値は“２８９”となる。認可ＡＰＩ３０４は、前記取得した当月のＡＰＩ呼出し回数６３５の集計値が、前記取得したＡＰＩ呼出し回数上限数の設定値６３４より少ないかどうか、即ち、集計値がＡＰＩ呼出し回数上限数以下であるか否かを判定する（Ｓ１６１０）。ステップＳ１６１０の判定がＹｅｓの場合、ステップＳ１６１１へ進む。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０内の、６３１が前述のステップＳ１００３で取得したオーナーＩＤで、６３２がステップＳ１００３で検証した認可トークン発行先のクライアントＩＤであるレコードを取得する。認可ＡＰＩ３０４は、前記取得したレコードの当月のＡＰＩ呼出し回数６３５に１を加算する（Ｓ１６１１）。ステップＳ１６１０の判定がＮｏの場合、ステップＳ１０１３へ進む。

１ユーザーが複数台の端末を使用している場合は、２台目以降の端末（クライアントコンピューター１２２）でも、図９、１４、１０、１６で説明したフローと同様のクライアント登録・認可トークン発行・リソースＡＰＩ呼出し処理を実行すればよい。１ユーザーが複数台の端末を使用していても、ステップＳ１４２７、Ｓ１６１０の処理により、１ユーザーＩＤあたりのＡＰＩ呼出し上限数を管理・制限可能となる。

次に、１ユーザーＩＤあたりのＡＰＩ呼出し回数が上限に達してしまったときに、ＡＰＩ呼出し上限数に加算する処理フローを説明する。フローは図１１と同様であり、異なる処理のみ以下で説明する。ステップＳ１１０６において、アプリケーション３３１は、ＡＰＩ呼出し上限数に加算したい対象のユーザーＩＤまたはメールアドレスを追加のパラメーターとして、認可ＡＰＩ３０４に送信する。ステップＳ１１０８においては、以下の処理に変更する。認可ＡＰＩ３０４は、テナント属性情報管理テーブル５２０の前記テナントＩＤかつ対象ＩＤ種別５２２がユーザーＩＤのレコードを読みだして、ＡＰＩ呼出し上限数への加算の許可設定５２５を取得する。許可設定５２５がＦＡＬＳＥの場合は、認可ＡＰＩ３０４は、アプリケーション３３１に不図示のエラー応答を返却する。認可ＡＰＩ３０４は、テナント属性情報管理テーブル５２０のステップＳ１１０７で取得したテナントＩＤのレコードを読みだして、対象ＩＤ種別５２２がユーザーＩＤである、１ユーザーＩＤあたりＡＰＩ呼出し上限数への加算値５２６を取得する。認可ＡＰＩ３０４は、ＡＰＩ呼出し回数管理テーブル６３０内の６３１が前記追加のパラメーターとして受信したユーザーＩＤで、クライアントＩＤ６３２がＡＬＬで、対象年月６３３が現在の年月のレコードを特定する。前記特定したレコードのＡＰＩ呼出し上限数の設定値６３４に、前記取得した加算値５２６を加算する。

実施例１によれば、クライアントであるアプリケーションにＡＰＩの呼出し回数を管理する機能を加えることなく、１ユーザーに対して割り当てられたＡＰＩ呼出し上限数を複数の端末におけるクライアント同士で共有することが可能になる。

実施例１では、認可フローがＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔからＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔへ切替え時に、ＡＰＩ呼出し回数の管理・制限がクライアントＩＤ単位からユーザーＩＤ単位に自動的に切替え可能である。また、実施例１では、例えばアプリケーションが無料から有料に切替え時に機能制限を解除するために、認可フロー切り替え時に、同時にＡＰＩ呼出し回数の上限を引き上げることが可能である。実施例２では、アプリケーション３３１がＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔの認可フローを使用せず、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔのみを使用する。実施例１、２において、図は全て共通であるので、実施例２の実施例１との差分のみを以下に説明する。

図９においては、実施例２では、実施例１同様ステップＳ９０１からＳ９０７のクライアント登録処理を実施するが、ステップＳ９０８からＳ９１４までは実行されない。図１３、１４においては、実施例１同様、ユーザー登録、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔによる認可トークン発行の処理を実施する。図１０においては、実施例２では、実施例１同様ステップＳ１００１からＳ１０１４のリソース要求ＡＰＩ呼出し処理を実施する。図１６においては、同一クライアントＩＤからはＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔの利用がないので、ステップＳ１６０５からＳ１６０８までの処理は不要で、ステップＳ１６０９からの処理を実行する。

１ユーザーが複数台の端末を使用している場合、２台目以降の端末（クライアントコンピューター１２２）でも、実施例１同様の処理となる。実施例２においても、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔによって認可された複数のアプリケーション３３１に対して、ＡＰＩ呼出し回数の管理・制限がユーザーＩＤ単位で実施できる。

以上、実施例１および２で説明したように、認可サーバー１１１は、リソースサーバー１１２のＡＰＩ３１３へのＡＰＩ利用要求に対して、ＯＡｕｔｈ２．０の認可フローに準拠したＡＰＩ認可を提供する。特に、クライアントコンピューター１２２のアプリケーション３３１ごとに、クライアントＩＤを払い出す事が可能で、クライアントＩＤまたはユーザーＩＤごとにリソースサーバー１１２のＡＰＩ３１３へのＡＰＩ呼出し回数を管理・制限することが可能である。また、ＯＡｕｔｈ２．０の認可フローで必須の処理である認可トークン発行時、および、認可トークン検証時に、認可トークン発行先のクライアントＩＤまたはユーザーＩＤごとにＡＰＩ呼出し回数の上限到達の検証が可能である。これにより、認可サーバー１１１におけるテナントごとの設定５２０および８１０等を用いて、アプリケーション開発者自身が、配布したアプリケーション３３１からのＡＰＩ呼出し回数を制御可能となる。

アプリケーション３３１からの認可フローがＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔの場合はクライアントＩＤごと、ＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔの場合はユーザーＩＤごとにＡＰＩ呼出し回数が自動的に管理・制限される。また、冒頭の課題で説明したアプリケーションを無料から有料に切り替え時、機能制限を解除するために、同一ユーザーが持つ複数台端末すべてに対しＡＰＩ利用回数の上限数を引き上げるケースにおいてもＢａａＳとしての利便性を損なうことはない。なぜなら、認可フローがＣｌｉｅｎｔＣｒｅｄｅｎｔｉａｌｓＧｒａｎｔからＡｕｔｈｏｒｉｚａｔｉｏｎＣｏｄｅＧｒａｎｔへ切替え時に、ＡＰＩ呼出し回数の管理・制限が自動的にクライアントＩＤ単位からユーザーＩＤ単位に切り替わるからである。そのため、アプリケーション開発者は、アプリケーション３３１に対して、ＯＡｕｔｈ２．０の標準通りの前記２種類の認可フローを実装するだけで良く、ＡＰＩ利用回数の上限数を引き上げるための特別の処理を実装する必要がない。以上により、認可サーバー１１１および他から成るＷｅｂサービス提供システムは、冒頭で述べた課題を解決する効果を得ている。

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

１１１認可サーバー
１１２リソースサーバー
１２１、１２１クライアントコンピューター

Claims

クライアントから利用可能なサービスを備えるサーバーシステムと、前記サービスを利用するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を呼び出すことで前記サービスを利用するクライアントとを含むシステムであって、
前記クライアントに対して一意に割り当てられたクライアント識別子を基に、正規なクライアントであるか否かを判断する認証手段と、
前記認証手段により正規なクライアントであると判断されたことに応じて、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を発行する発行手段と、
前記クライアントが前記ＡＰＩを呼び出す際に送信する前記権限情報を基に、前記クライアントによる前記サービスの利用を認可する認可手段と、
前記権限情報とユーザー識別子とを関連付け、前記ユーザー識別子と前記ＡＰＩの呼出し上限数とを関連付けて保存する保存手段と、を有し、
前記認可手段は、前記クライアントから送信された前記権限情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数以下の場合に、前記クライアントによる前記サービスの利用を認可することを特徴とするシステム。
前記認可手段は、前記クライアントから送信された前記権限情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数を超える場合に、前記クライアントによる前記サービスの利用を認可しないことを特徴とする請求項１に記載のシステム。
前記保存手段は、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数を超えた際、ＡＰＩ呼出し上限数を加算することが許可された前記クライアントから上限数の加算を要求された場合、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数を加算することを特徴とする請求項１または２に記載のシステム。
前記発行手段は、前記クライアントに対する前記権限情報を再発行する際に、前記クライアントから送信された前記権限情報を再発行するために必要な情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数以下の場合に、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を再発行することを特徴とする請求項１乃至３の何れか１項に記載のシステム。
前記発行手段は、前記クライアントに対する前記権限情報を再発行する際に、前記クライアントから送信された前記権限情報を再発行するために必要な情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数を超える場合に、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を再発行しないことを特徴とする請求項１乃至４の何れか１項に記載のシステム。
クライアントから利用可能なサービスを備えるサーバーシステムと、前記サービスを利用するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を呼び出すことで前記サービスを利用するクライアントとを含むシステムで実行される方法であって、
認証手段は、前記クライアントに対して一意に割り当てられたクライアント識別子を基に、正規なクライアントであるか否かを判断し、
発行手段は、前記認証手段により正規なクライアントであると判断されたことに応じて、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を発行し、
認可手段は、前記クライアントが前記ＡＰＩを呼び出す際に送信する前記権限情報を基に、前記クライアントによる前記サービスの利用を認可し、
保存手段は、前記権限情報とユーザー識別子とを関連付け、前記ユーザー識別子と前記ＡＰＩの呼出し上限数とを関連付けて保存し、
更に、前記認可手段は、前記クライアントから送信された前記権限情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数以下の場合に、前記クライアントによる前記サービスの利用を認可することを特徴とする方法。
前記認可手段は、前記クライアントから送信された前記権限情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数を超える場合に、前記クライアントによる前記サービスの利用を認可しないことを特徴とする請求項６に記載の方法。
前記保存手段は、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数を超えた際、ＡＰＩ呼出し上限数を加算することが許可された前記クライアントから上限数の加算を要求された場合、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数を加算することを特徴とする請求項６または７に記載の方法。
前記発行手段は、前記クライアントに対する前記権限情報を再発行する際に、前記クライアントから送信された前記権限情報を再発行するために必要な情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数以下の場合に、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を再発行することを特徴とする請求項６乃至８の何れか１項に記載の方法。
前記発行手段は、前記クライアントに対する前記権限情報を再発行する際に、前記クライアントから送信された前記権限情報を再発行するために必要な情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数を超える場合に、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を再発行しないことを特徴とする請求項６乃至９の何れか１項に記載の方法。
クライアントから利用可能なサービスを備え、前記サービスを利用するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を呼び出すことで前記サービスを利用するクライアントと通信可能なサーバーシステムであって、
前記クライアントに対して一意に割り当てられたクライアント識別子を基に、正規なクライアントであるか否かを判断する認証手段と、
前記認証手段により正規なクライアントであると判断されたことに応じて、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を発行する発行手段と、
前記クライアントが前記ＡＰＩを呼び出す際に送信する前記権限情報を基に、前記クライアントによる前記サービスの利用を認可する認可手段と、
前記権限情報とユーザー識別子とを関連付け、前記ユーザー識別子と前記ＡＰＩの呼出し上限数とを関連付けて保存する保存手段と、を有し、
前記認可手段は、前記クライアントから送信された前記権限情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数以下の場合に、前記クライアントによる前記サービスの利用を認可することを特徴とするサーバーシステム。
クライアントから利用可能なサービスを備え、前記サービスを利用するためのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）を呼び出すことで前記サービスを利用するクライアントと通信可能なサーバーシステムにより実行されるプログラムであって、
前記クライアントに対して一意に割り当てられたクライアント識別子を基に、正規なクライアントであるか否かを判断する認証ステップと、
前記認証ステップにおいて正規なクライアントであると判断されたことに応じて、前記クライアントが前記サービスを利用する権限を有していることを示す権限情報を発行する発行ステップと、
前記クライアントが前記ＡＰＩを呼び出す際に送信する前記権限情報を基に、前記クライアントによる前記サービスの利用を認可する認可ステップと、
前記権限情報とユーザー識別子とを関連付け、前記ユーザー識別子と前記ＡＰＩの呼出し上限数とを関連付けて保存する保存ステップと、を含み、
更に、前記認可ステップにおいて、前記クライアントから送信された前記権限情報に関連付くユーザー識別子を特定し、前記ユーザー識別子に対応するユーザーの指示により前記クライアントを含む複数のクライアントが呼出した前記ＡＰＩの呼出し回数の集計値が、前記ユーザー識別子に関連付く前記ＡＰＩの呼出し上限数以下の場合に、前記クライアントによる前記サービスの利用を認可することを特徴とするプログラム。