JP2017107396A - 権限委譲システム、情報処理装置、認可サーバ、制御方法およびプログラム - Google Patents

Abstract

【課題】デバイスの利用者のテナントが変わった場合においても情報漏洩することなくサービスを利用できる権限委譲システムを提供する。【解決手段】デバイス５００は、ベンダークライアント登録に応じて認可サーバ２００から提供されたベンダークライアントＩＤとシークレットを基に、テナント専用クライアントを作成するユーザの権限がベンダークライアントに委譲されたことを示す認可トークンを取得する。デバイス５００は、認可トークンを基に認可サーバ２００にテナント専用クライアントを登録し、登録に応じて認可サーバ２００から提供されたテナント専用クライアントＩＤとシークレットを基に、リソースサーバ３００のサービスにおけるユーザの権限がテナント専用クライアントに委譲されたことを示すアプリケーション用認可トークンを取得する。デバイス５００は、アプリケーション用認可トークンを基に、リソースサーバ３００のサービスを利用する。【選択図】図１

Description

本発明は、権限委譲システム、情報処理装置、認可サーバ、制御方法およびプログラムに関する。

クラウドサービスは、一般的にＷｅｂサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を公開しており、デバイスや他のクラウドサービスからＡＰＩを介してサービスが提供する機能を利用する事ができる。このＡＰＩ利用における認証、認可のプロトコルとして、ＯＡｕｔｈ ２．０と呼ばれる標準プロトコルが策定されている。ＯＡｕｔｈ ２．０では、クライアントとなるデバイスや他のクラウドサービスと認可サーバとが連携することで認証および認可を行う。認証および認可を受けたクライアントは、認可サーバから認可トークンを取得し、その認可トークンを送信することでＡＰＩを利用する。

ＯＡｕｔｈ ２．０では、認可プロトコルのフローをＧｒａｎｔ Ｔｙｐｅと呼んでいる。代表的なＧｒａｎｔ Ｔｙｐｅとして、ユーザがクライアントに権限を委譲するＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔと、クライアントが自身のリソースにアクセスするためのＣｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔが定義されている。

デバイスは、ユースケースによってＧｒａｎｔ Ｔｙｐｅを使い分ける事が考えられる。例えば、デバイスのオーナーであるユーザが、デバイスを操作した事を契機にクラウドサービスと連携する場合は、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔが選択される。一方、デバイスが備えるセンサーや機器における変化を検知し、クラウドサービスと連携する場合は、Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔが選択される。このように、ＯＡｕｔｈ ２．０を利用する事で、様々なユースケースに対応する事が可能である。

ＯＡｕｔｈ ２．０を利用するためには、事前に認可サーバに対してクライアントを登録し、クライアントを識別するためのクライアントＩＤと、認証するためのシークレットとを、クライアントとなるデバイスに登録しておく必要がある。特許文献１は、ＯＡｕｔｈ ２．０のためのクライアントを自動的に登録する権限委譲システムを開示している。特許文献１が開示する権限委譲システムでは、アプリケーションが保持しているＸ．５０９形式のクライアント証明書を利用する事で、認可サーバに対して動的にクライアントが登録される。そして、自動的に取得されたクライアントＩＤおよびシークレットを利用する事で、ＯＡｕｔｈ ２．０の各種プロトコルを利用することが可能となる。

特開２０１５−５２０２号公報

従来の権限委譲システムでは、クラウドサービスに登録されたクライアントが、どのテナントのクライアントなのかが特定される仕組みがなかった。したがって、デバイスから送信されるデータに含まれる、個人のプライバシーに関する情報や機密情報が、他のテナントやクラウドサービスを提供するベンダーに漏洩するリスクがある。

本発明は、デバイスの利用者のテナントが変わった場合においても情報漏洩することなくサービスを利用できる権限委譲システムの提供を目的とする。

本発明の一実施形態の権限委譲システムは、情報処理装置と、ネットワークを介してサービスを提供するサービス提供装置と、認可サーバとを含み、前記情報処理装置をクライアントとして前記認可サーバに登録する権限委譲システムである。前記情報処理装置は、前記認可サーバへの第１のクライアントの登録に応じて前記認可サーバから提供された第１の認証情報を基に、第２のクライアントを作成するユーザの権限が前記第１のクライアントへ委譲されたことを示す第１の認可情報の取得要求をする第１の取得要求手段と、前記第１の取得要求手段による前記取得要求によって前記第１の認可情報が取得されたことに応じて、前記認可サーバへの前記第２のクライアントの登録要求をする登録要求手段と、を有する。前記認可サーバは、前記登録要求とともに送信された前記第１の認可情報を基に前記ユーザのテナントを特定し、特定された前記テナントと新たに登録する前記第２のクライアントとを紐付けて管理する管理手段と、前記テナントと紐付けて管理される前記第２のクライアントに対応する第２の認証情報を発行する発行手段と、を有する。さらに、前記情報処理装置は、前記登録要求による前記第２のクライアントの登録に応じて前記認可サーバから提供された前記第２の認証情報を基に、特定の権限が前記第２のクライアントに委譲されたことを示す第２の認可情報の取得要求をする第２の取得要求手段と、前記第２の取得要求手段による前記取得要求によって取得された前記第２の認可情報を基に、前記サービス提供装置のサービスを利用する利用手段とを有する。また、前記サービス提供装置は、前記第２の認可情報を基に特定された前記テナントを確認し、サービスの提供に関するデータを確認された前記テナントに紐付けて保存する保存手段を有する。

本発明の権限委譲システムによれば、デバイスの利用者のテナントが変わった場合においても情報漏洩することなくサービスを利用できる。

権限委譲システムの構成を示す図である。 認可サーバ、リソースサーバ、端末、およびデバイスのハードウェア構成を示す図である。 認可サーバ、リソースサーバ、デバイスの機能ブロック図の一例である。 クライアント登録処理を説明する図である。 ログイン画面とデバイス登録画面の一例を示す図である。 リソースサーバモジュールのＡＰＩを呼び出す処理を説明する図である。 権限委譲の開始が行われた場合の処理を説明する図である。 認可確認画面の一例である。 リソースサーバモジュールのＡＰＩを呼び出す処理を説明する図である。 認可トークンを用いた処理を説明する図である。 第一、第二、第三の方式を使い分ける判断処理を説明する図である。 第一、第二、第三の方式を使い分ける判断処理を説明する図である。

まず、クライアントの登録方式として複数の方式を説明し、各方式の課題を説明後、それら課題を解決する本実施形態の権限委譲システムを説明する。
前述のとおり、ＯＡｕｔｈ ２．０では、複数のＧｒａｎｔ Ｔｙｐｅが定義されている。本実施形態では、Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔを用いた方式として２種の方式、およびＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを用いた方式について説明する。

第一の方式は、Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔを用いた２種の方式のうちの１種目の方式である。この方式は、デバイスを識別する情報として、クライアントＩＤだけでなく、クライアントの機体ごとに個体識別可能に付与されている機体番号（以後、デバイスシリアルＩＤと呼称する）を用いる事で、各テナントと紐づける方式である。第一の方式では、クラウドサービス側でデバイスとテナントを紐づけるので、デバイス側でユーザの特別な操作を必要としないメリットがある。一方、第一の方式では、デバイスシリアルＩＤが変わらないまま当該デバイスがリサイクルされ、別のテナントのユーザに利用された場合に、情報漏えいのリスクがある。第一の方式の詳細については後述する。

第二の方式は、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを用いた方式である。第二の方式は、デバイスを特定のテナントと紐づけるために、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔで権限委譲したユーザの情報を用いる。第二の方式では、デバイス内にユーザから権限委譲された事を示すトークンを保持し、そのトークンを利用する事でクラウドサービスを利用する。第二の方式では、デバイス内で保持しているトークンを削除する事によって、デバイスとテナントの紐づけが解消されるので、デバイスのリサイクルによる情報漏えいのリスクを下げる事が可能である。一方、第二の方式は、デバイスが権限委譲を実施したユーザ個人に紐づくので、ユーザに対する権限の剥奪や、ユーザ情報がクラウドサービス側で削除される事によりトークンが利用できなくなるデメリットが存在する。第二の方式の詳細については後述する。

第三の方式は、Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔを用いた２種目の方式である。第三の方式は、本実施形態における、最も特徴的な方式である。第三の方式は、Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔを用いるためのクライアントＩＤ、シークレットを、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用して動的に発行することに特徴がある。第三の方式は、第一、第二の方式のデメリットがないため、最も情報の漏洩リスクが低い方式である。第三の方式の詳細については、後述する。なお、これら第一、第二、第三の方式は、排他的にどれか一つの方式のみが実施可能に構成されるわけではなく、デバイスにおけるユースケースによって使い分ける、つまり、全ての方式が実現可能に構成する事が可能である。

次に、本明細書において用いる用語の定義について説明する。
Ｗｅｂサービスとは、サーバ上で起動するソフトウェアがクライアントからの要求に従い実行されることでそのクライアントに対して提供される機能である。なお、ＷｅｂサービスのソフトウェアであるＷｅｂアプリケーションのこともＷｅｂサービスと呼ぶ場合もある。本実施形態においては、クラウドサービスとして、リソースサーバが提供するＷｅｂサービスがあり、ユーザは、デバイスを介してリソースサーバが提供するＷｅｂサービスを利用していることを想定する。もちろん、この想定は、本実施形態を説明する上での想定であり、リソースサーバおよびデバイスは、各々単数で構成される事を限定しているわけではない。例えば、複数台から構成されたサーバ群がサービスを提供していても良い。

図１は、本実施形態の権限委譲システムの構成を示す図である。
ＷＡＮ１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋである。すなわち、本実施形態では、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋである。

認可サーバ２００は、ＯＡｕｔｈ ２．０を実現するための認可処理を行う。リソースサーバ３００は、ネットワーク（ＬＡＮ１０１，ＷＡＮ１００）を介してサービスを提供するサービス提供サーバとして機能する。端末４００は、ユーザが操作する装置である。端末４００は、Ｗｅｂブラウザ４１０を備える。

デバイス５００は、例えば、プリンタやスマートフォンと呼ばれる携帯端末等である。
デバイス５００は、ネットワークを介してクライアントとして認可サーバ２００に登録され、リソースサーバ３００が提供するサービスを利用する。サービスの利用例として、デバイス５００は、データをリソースサーバ３００に送信してアップロードする。デバイス５００は、Ｗｅｂブラウザ５１０等、各種モジュールを備える。ユーザは、Ｗｅｂブラウザ４１０、もしくは５１０（図３（Ｂ））を用いて、認可サーバ２００と通信する。

認可サーバ２００とリソースサーバ３００とは、ＬＡＮ１０１を介して接続されている。また、認可サーバ２００、リソースサーバ３００、端末４００、およびデバイス５００は、それぞれＷＡＮ１００を介して通信可能に接続されている。また、認可サーバ２００、リソースサーバ３００は、不図示のデータベースサーバとＬＡＮ１０１を介して接続しており、各サーバモジュールが利用するデータを格納するよう構成してもよい。さらに、リソースサーバ３００、認可サーバ２００は、同一のサーバ上に構成されていてもよい。また、認可サーバ２００およびリソースサーバ３００は、ＷＡＮ１００を介して接続するように構成する事もできる。

図２は、認可サーバ、リソースサーバ、端末、およびデバイスのハードウェア構成を示す図である。
本実施形態の各サーバおよび端末、デバイスには、一般的な情報処理装置のハードウェア構成を適用できる。さらに、各サーバについては、ＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供される情報処理装置の仮想的なハードウェア構成を適用することもできる。

図２において、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２００１は、ＲＯＭ２００３が有するプログラム用ＲＯＭに記憶されたＯＳやアプリケーション等のプログラムを実行し、システムバス２００４に接続される各ブロックを制御する。また、ＣＰＵ２００１は、ハードディスク（ＨＤ）等の外部メモリ２０１１からＲＡＭ２００２にロードされたプログラムを実行し、各ブロックを制御する。ＯＳとは、コンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理は、ＣＰＵ２００１によるプログラムの実行により実現できる。なお、ＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略称であり、ＲＡＭは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略称である。

ＲＡＭ２００２は、ＣＰＵ２００１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２００５は、キーボード２００９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２００６は、ＣＲＴディスプレイ２０１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２００７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２０１１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２００８は、ＷＡＮ１００、ＬＡＮ１０１を介して接続された他の機器との通信制御処理を実行する。

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

図３は、認可サーバ、リソースサーバ、デバイスの機能ブロック図の一例である。
図３（Ａ）は、認可サーバ２００の構成を示す。認可サーバ２００は、認可サーバモジュール２１０、ＨＴＴＰサーバモジュール２２０を備える。ＨＴＴＰサーバモジュール２２０は、ＷＡＮ１００を介して接続する端末４００に設置されたＷｅｂブラウザ４１０、デバイス５００に設置されたＷｅｂブラウザ５１０とのＨＴＴＰ通信を行うためのモジュールである。また、ＨＴＴＰサーバモジュール２２０は、ＳＳＬ／ＴＬＳによる通信が可能に構成されており、不図示の証明書ストアを持つ。また、本実施形態では、ＨＴＴＰサーバモジュール２２０は、後述するクライアント登録要求を受け付けた場合に、要求元に対してクライアント認証を要求する。

認可サーバモジュール２１０は、ＨＴＴＰサーバモジュール２２０上で動作もしくはＨＴＴＰサーバモジュール２２０と連携して動作するＷｅｂアプリケーションである。認可サーバモジュール２１０は、ＨＴＴＰサーバモジュール２２０を介して、Ｗｅｂブラウザ４１０、５１０からの要求を受け付け、処理し、応答する。また、本実施形態では、認可サーバモジュール２１０は、後述する認可要求を受け付けた場合に、要求元に対してユーザＩＤ、パスワードによるユーザ認証を要求する。以下の説明では、ＨＴＴＰサーバモジュール２２０を介して認可サーバモジュール２１０がＷｅｂブラウザと通信する処理について、ＳＳＬ／ＴＬＳの処理について説明が必要でない限り、Ｗｅｂブラウザと認可サーバモジュール２１０が通信すると記述する。

認可サーバモジュール２１０は、ユーザ認証を受け付け、要求元の認証に成功した場合、認証したユーザ情報を紐づけた認証トークンを生成し、Ｗｅｂブラウザ４１０、５１０に応答する。認証トークンは、ユーザが認証されてログインしていること、またはユーザが認証されているかを検証するためのトークンである。認証トークンの利用により、ユーザを識別する事が可能となる。後述の認可コードは認証トークンとは異なる。認可コードは、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔにて、認証されたユーザによる認可操作対象のクライアントが、ユーザの権限をもって、ユーザに成り代わってアクセスする事を許可したことを示すトークンである。

また、認可トークンは、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔの場合は、認可コードを用いて取得され、クライアントがクラウドサービスの公開ＡＰＩを利用する際に送信される。認可トークンは、認可操作を行ったユーザの権限がクライアントに委譲されたことを示すトークンである。認可トークンは、認証トークンとは異なる。特に顕著なのは、認証トークンは、ユーザの確認を目的としているが、認可トークンは、権限の確認を目的としている点である。さらには、リフレッシュトークンは、同じく認可コードを用いて取得し、認可トークンを再発行することが可能であることを示すトークンである。なお、Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔの場合の認可トークンは、クライアント自身の権限を示すトークンである。

認可サーバモジュール２１０は、ＬＡＮ１０１を介してリソースサーバモジュール３１０から認可トークン検証処理を受け付け、処理し、応答する。認可トークン検証処理は、ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）として構成する事も可能である。また、認可トークン検証処理は、ＨＴＴＰサーバモジュール２２０を介してＬＡＮ１０１内、もしくはＷＡＮ１００を介して通信可能なＷｅｂサービスのＡＰＩとして構成する事も可能である。

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

図３（Ｃ）は、デバイス５００の構成を示す。デバイス５００が備えるＣＰＵ２００１（図２）が、ＲＯＭ２００３または外部メモリ２０１１に記憶されたＯＳを実行する事で、各アプリケーションを制御する。

デバイス５００は、Ｗｅｂブラウザ５１０、ログインアプリケーション５２０、アクセストークンプロバイダ５３０、リソースサーバ連携アプリケーション５４０を備える。Ｗｅｂブラウザ５１０は、ＷＷＷを利用するためのユーザエージェントである。

ログインアプリケーション５２０は、デバイスの利用者を認証するための機能を備える。ログインアプリケーション５２０は、ユーザからのユーザＩＤ、パスワードを受け付ける画面（不図示）を表示する。ログインアプリケーション５２０は、この画面を通じて入力されたユーザＩＤ、パスワードの組が、予めデバイス５００に記憶されているデータと一致するか検証する。ログインアプリケーション５２０は、検証結果が正しい場合は、記憶されているユーザの情報を含むログインコンテキストを生成することで、各ユーザを認証する機能を備える。また、ログインアプリケーション５２０は、デバイス５００に接続された不図示のＩＣカードリーダーからＩＣカード情報を取得し、デバイス５００に記憶されているＩＣカード情報の情報と合っているか検証する。

ログインアプリケーション５２０は、検証結果が正しい場合は、対応するユーザの情報を含むログインコンテキストを生成する事で、各ユーザを認証する機能を備えてもよい。また、ログインアプリケーション５２０が、ＷＡＮ１００によって通信可能に接続された不図示のシングルサインオンサーバと連携し、ＳＡＭＬや、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔといったシングルサインオンプロトコルによるユーザ認証を実現してもよい。

アクセストークンプロバイダ５３０は、ＷＡＮ１００を介して、認可サーバ２００と連携し、後述するクライアントの登録や認可トークンの取得を行う。その際、アクセストークンプロバイダ５３０は、Ｗｅｂブラウザ５１０や、端末４００のＷｅｂブラウザ４１０とも通信するよう構成されており、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを実行する。また、アクセストークンプロバイダ５３０は、後述のリソースサーバ連携アプリケーション５４０からのリクエストに応じて、取得した認可トークンを提供する事ができる。

また、アクセストークンプロバイダ５３０は、自身を証明するためのベンダーデフォルトクレデンシャルとして、Ｘ．５０９形式のクライアント証明書およびその秘密鍵を備える。そして、アクセストークンプロバイダ５３０が、クライアント証明書およびその秘密鍵を、認可サーバ２００のＨＴＴＰサーバモジュール２２０との通信確立時に利用する事で、アクセストークンプロバイダ５３０が認証される。

リソースサーバ連携アプリケーション５４０は、アクセストークンプロバイダ５３０から取得した認可トークンを用いて、リソースサーバ３００が公開するＡＰＩを呼び出すように構成されている。また、リソースサーバ連携アプリケーション５４０は、デバイス５００内での各種イベントの発生時に動作するよう構成されている。例えば、リソースサーバ連携アプリケーション５４０は、ユーザがログインアプリケーション５２０を利用してログインした場合や、デバイス５００が備えるセンサーやアプリケーションが変化を検知した場合に動作する。デバイス５００が、例えばプリンタである場合は、端末４００からの印刷リクエストを受け付けた場合や、印刷が完了した際にイベントが発生し、リソースサーバ連携アプリケーション５４０が動作する。

図４は、第一、第二、第三の方式において共通に実施されるクライアント登録処理を説明する図である。
本シーケンスは、デバイス５００から認可サーバモジュール２１０に対してクライアントを登録する処理を示す。本シーケンスで登録されたクライアントは、後述するテナント専用のクライアントと区別するために、以後、ベンダークライアントと呼称する。

Ｓ１．１において、デバイス５００のアクセストークンプロバイダ５３０が、認可サーバ２００のＨＴＴＰサーバモジュール２２０に対して、ベンダークライアント登録要求を行う。なお、アクセストークンプロバイダ５３０が、ベンダークライアント登録要求を行うタイミングは、本実施形態では、デバイス５００にて、ユーザが当該アクセストークンプロバイダ５３０を初めて起動したタイミングとする。なお、他のタイミングとして、ユーザが、アクセストークンプロバイダ５３０の機能を選択し、リソースサーバ３００へのリソース要求が発生するタイミングが考えられる。また、他のタイミングとして、アクセストークンプロバイダ５３０が、明示的に開始する操作を備え、ユーザがデバイス５００にて当該操作をしたタイミングが考えられる。

なお、ベンダークライアント登録要求は、クライアント名、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用するためのリダイレクトＵＲＬ、およびデバイス５００を個体識別可能なデバイスシリアルＩＤを含む。また、ベンダークライアント登録要求が、その他の情報として、クライアントを説明するための文字列や、説明が記載されるサイトのＵＲＬ等の付属情報を含むように構成する事もできる。なお、ベンダークライアント登録要求は、何れの装置のアクセストークンプロバイダ５３０に共通な情報が含まれており、テナントを含むユーザに関する情報が一切含まれていない。これは、アクセストークンプロバイダ５３０を起動した段階ではどのユーザのテナントにアクセストークンプロバイダ５３０が所属しているか不明なためである。これを解消するのが第二の方式および第三の方式である。第一の方式の場合、サービスの提供に関するデータはユーザのテナントに紐付くことはできない。

アクセストークンプロバイダ５３０からのベンダークライアント登録要求を受け付けたＨＴＴＰサーバモジュール２２０は、ＳＳＬ／ＴＬＳ通信のネゴシエーションを開始する。その際、ベンダークライアント登録要求に関してはクライアント認証を要求するよう設定されているため、アクセストークンプロバイダ５３０に対してベンダーデフォルトクレデンシャルによるクライアント認証を要求する。

Ｓ１．２において、ＨＴＴＰサーバモジュール２２０が、不図示の証明書ストアにて設定されている証明書を用いて、取得したクライアント認証情報を検証し、アクセストークンプロバイダ５３０をデバイス登録の要求元として認証する。本実施形態では、ベンダークライアント登録要求の要求元の認証方法として、ＳＳＬ／ＴＳＬのクライアント証明書による認証方式を用いる。認証方法として、Ｂａｓｉｃ認証やＤｉｇｅｓｔ認証などの、ベンダーデフォルトクレデンシャルとしてＩＤおよびパスワードを用いてもよい。また、認証された主体に対してベンダークライアントを登録するための認可トークンを発行し、当該認可トークンを検証する事によってベンダークライアント登録を受け付けるよう構成する事も可能である。認証に失敗した場合、ＨＴＴＰサーバモジュール２２０は、アクセストークンプロバイダ５３０に対してエラーを応答する。

Ｓ１．３において、ＨＴＴＰサーバモジュール２２０が、アクセストークンプロバイダ５３０を認証した後に、認可サーバモジュール２１０に対して、アクセストークンプロバイダ５３０から受信したベンダークライアント登録要求を通知する。ＨＴＴＰサーバモジュール２２０は、認証したアクセストークンプロバイダ５３０を識別する情報（取得したベンダーデフォルトクレデンシャルの情報）も通知する。

Ｓ１．４において、認可サーバモジュール２１０が、ＨＴＴＰサーバモジュール２２０から認証情報として通知されたベンダーデフォルトクレデンシャルの情報を取得する。次に、Ｓ１．５において、認可サーバモジュール２１０が、取得したベンダーデフォルトクレデンシャルの情報に含まれる識別子をキーとして取得する。識別子は、例えば、Ｘ．５０９の証明書の場合は、発行者の識別子、主体の識別子、シリアル番号等である。認可サーバモジュール２１０は、これらキーおよびキーに対応するテナントＩＤが登録されている不図示の証明書管理テーブルを備える。

認可サーバモジュール２１０は、証明書管理テーブルから、キーに紐づくテナントＩＤを取得する。その際、ベンダーデフォルトクレデンシャルの開始日時、終了日時を有効期間として、検証するよう構成する事もできる。証明書管理テーブルに該当のレコードが無い場合や、有効期間の検証に失敗した場合、認可サーバモジュール２１０は、ＨＴＴＰサーバモジュール２２０を介して、アクセストークンプロバイダ５３０にエラーを応答する。

Ｓ１．６において、認可サーバモジュール２１０が、ベンダークライアント登録要求によって取得した情報と、取得したテナントＩＤを基に、クライアント管理テーブルにベンダークライアントを新規登録する。具体的には、認可サーバモジュール２１０は、クライアントＩＤ、シークレットを発行し、それぞれクライアント管理テーブルに格納する。以後、ここで発行し登録したクライアントＩＤについては、後述するテナント専用のクライアントのクライアントＩＤと区別するために、ベンダークライアントＩＤと呼称する。

認可サーバモジュール２１０は、取得したクライアント名、リダイレクトＵＲＬ、デバイスシリアルＩＤおよびテナントＩＤを、それぞれクライアント管理テーブルに格納する。その際、テナントＩＤとして、認可サーバ２００を提供するベンダーを示すＩＤが付与される。

表１に、ベンダークライアントが新規登録された状態のクライアント管理テーブルの例を示す。

なお、登録されたクライアントに対してデフォルトで設定すべき権限を、証明書管理テーブルに予め設定しておき、その設定に従って、Ｓ１．６で登録したベンダークライアントに対してデフォルトの権限を付与するよう構成する事もできる。クライアントの登録が完了した後に、Ｓ１．７において、認可サーバモジュール２１０が、発行したベンダークライアントＩＤとシークレットとを、ＨＴＴＰサーバモジュール２２０を介してアクセストークンプロバイダ５３０に応答する。以上がベンダークライアントの登録処理の説明である。

次に、第一の方式、つまりＣｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔを用いた２種の方式のうちの１種について説明する。この方式は、デバイスを識別する情報として、クライアントＩＤだけでなくデバイスシリアルＩＤを用いる方式である。第一の方式では、まず、デバイスシリアルＩＤとテナントＩＤとを紐づける作業、つまり、デバイスのテナントへの登録作業が必要となる。デバイスを登録する方法としては、リソースサーバ３００にてデバイスシリアルＩＤを入力する方法が考えられる。以下、デバイスの登録について詳細を説明する。なお、デバイスを登録するユーザは、デバイスの管理者か、もしくは管理を委譲されているユーザを想定しており、ユーザは、端末４００またはデバイス５００に設けられたＷｅｂブラウザ４１０、５１０を利用して作業する。

ユーザは、Ｗｅｂブラウザ４１０、５１０を利用して、リソースサーバモジュール３１０のデバイス登録画面へアクセスする。リソースサーバモジュール３１０は、Ｗｅｂブラウザ４１０、５１０からのアクセスを受けると、Ｗｅｂブラウザ４１０、５１０からの通知に、ＨＴＴＰ Ｃｏｏｋｉｅとして有効な認証トークンが含まれているか検証する。ＨＴＴＰ Ｃｏｏｋｉｅに認証トークンが含まれている場合、リソースサーバモジュール３１０は、認証トークンを認可サーバモジュール２１０に通知する。ＨＴＴＰ Ｃｏｏｋｉｅに認証トークンが含まれていない場合は、以下の処理を実行する。リソースサーバモジュール３１０は、Ｗｅｂブラウザ４１０、５１０に対し、認可サーバモジュール２１０が提供する、ユーザを認証するためのログイン画面に対してリダイレクトするよう応答する。

図５は、ログイン画面とデバイス登録画面の一例を示す図である。
図５（Ａ）は、認可サーバモジュール２１０が生成する、ユーザがログインするためのログイン画面例である。この例では、ユーザは、ユーザＩＤおよびパスワードを入力し、それらの組が、後述する認可サーバモジュール２１０のユーザ管理テーブルに登録されている情報の組と一致する場合に認証が成功する。

図５（Ａ）に示すログイン画面５０００は、ユーザＩＤを入力するためのユーザＩＤ入力欄５００１、パスワードを入力するためのパスワード入力欄５００２、およびログイン操作を実行するためのログインボタン５００３を有する。

ユーザは、Ｗｅｂブラウザ４１０、５１０に表示されたログイン画面５０００上で必要な情報を入力し、ログインボタン５００３を押下する。Ｗｅｂブラウザ４１０、５１０は、入力された情報を認可サーバモジュール２１０に送信する。認可サーバモジュール２１０は、ユーザＩＤ、パスワードを取得し、ユーザ管理テーブルのユーザＩＤ、パスワードの情報の組と比較し、一致するかを検証する事でユーザを認証する。表２に、認可サーバモジュール２１０が備えるユーザ管理テーブルの例を示す。

本実施形態では、ユーザＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」、パスワード「ｕｓｅｒ」が、ログイン画面５０００に入力され、認可サーバモジュール２１０は、入力されたデータを検証し、認証する。なお、認可サーバモジュール２１０は、ユーザ認証に失敗、つまり、ユーザ管理テーブルに情報が登録されていない場合は、不図示の認証エラー画面をＷｅｂブラウザ４１０、５１０に応答する。

ユーザ認証に成功した場合、認可サーバモジュール２１０は、認証トークンを生成する。認証トークンは、認可サーバモジュール２１０の不揮発メモリ上に、ユーザＩＤと、ユーザＩＤに対応するＵＵＩＤとテナントＩＤとに対応付けて保存される。なお、ＵＵＩＤとは、Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒの略称であり、重複しないユニークなＩＤである。本実施形態では、認証トークンは、ユーザＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」、ＵＵＩＤ「１００００００１」およびテナントＩＤ「１０００ＡＡ」に対応付けて保存される。

認可サーバモジュール２１０は、認証トークンをＷｅｂブラウザ４１０、５１０に応答する。なお、認証トークンは、ＨＴＴＰ Ｃｏｏｋｉｅとして設定され、認可サーバモジュール２１０からＷｅｂブラウザ４１０、５１０への応答に設定され、通知される。その際、認可サーバモジュール２１０は、リソースサーバモジュール３１０のデバイス登録画面へリダイレクトするよう応答する。

リソースサーバモジュール３１０は、Ｗｅｂブラウザ４１０、５１０からのアクセスを受けると、Ｗｅｂブラウザ４１０、５１０からの通知に、ＨＴＴＰ Ｃｏｏｋｉｅとして有効な認証トークンが含まれているか検証する。ＨＴＴＰ Ｃｏｏｋｉｅに認証トークンが含まれている場合、リソースサーバモジュール３１０は、認証トークンを認可サーバモジュール２１０に通知する。認可サーバモジュール２１０は、受信した認証トークンが有効であるかを検証し、有効である場合は、認証トークンに紐づいた情報であるユーザＩＤ、ＵＵＩＤ、テナントＩＤを応答する。この例では、ユーザＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」、ＵＵＩＤ「１００００００１」および、テナントＩＤ「１０００ＡＡ」が応答される。

認証トークンが無効、つまり認可サーバモジュール２１０の不揮発メモリ上に保存されていない場合は、その旨がリソースサーバモジュール３１０に応答される。以後、Ｗｅｂブラウザからリソースサーバモジュール３１０、認可サーバモジュール２１０へのアクセスの際には、認可サーバモジュール２１０による認証トークンの検証、認証処理、および認証トークンの認可サーバモジュール２１０での検証が実行される。

図５（Ｂ）は、リソースサーバモジュール３１０が生成するデバイスをテナントに登録するためのデバイス登録画面の一例である。デバイス登録画面は、デバイスの管理者か、もしくは管理を委譲されているユーザが利用するＷｅｂブラウザ４１０、５１０にて表示される。

デバイス登録画面５１００は、登録するデバイスのデバイスシリアルＩＤを入力するためのデバイスシリアルＩＤ入力欄５１０１、デバイスを登録するための登録ボタン５１０２を備える。登録の処理については後述する。デバイス登録画面５１００は、既に登録されている状態のデバイスの一覧を表示する、登録デバイス一覧５１０３を備える。表３は、リソースサーバモジュール３１０が管理するデバイス管理テーブルを示す。

ユーザが、Ｗｅｂブラウザ４１０、５１０に表示されたデバイス登録画面５１００のデバイスシリアルＩＤ入力欄５１０１に仮登録するデバイスのデバイスシリアルＩＤを入力する。本実施形態では、デバイスシリアルＩＤ「ＤＳ１００００００３」が入力されたものとする。次に、ユーザは、登録ボタン５１０２を押下する。登録ボタン５１０２を押下されると、Ｗｅｂブラウザ４１０、５１０が、リソースサーバモジュール３１０に対して、デバイスシリアルＩＤ「ＤＳ１００００００３」と、認証トークンとを送信する。リソースサーバモジュール３１０は、取得したデバイスシリアルＩＤがデバイス管理テーブルに登録されていないかを確認する。デバイスシリアルＩＤがデバイス管理テーブルに登録されていない場合は、リソースサーバモジュール３１０は、認証トークンに紐づいているテナントＩＤ「１０００ＡＡ」と共に、デバイス管理テーブルにデータを格納する。表４は、デバイスシリアルＩＤ「ＤＳ１００００００３」のデバイスが登録された状態のデバイス管理テーブルを示す。

以上の処理により、デバイスシリアルＩＤ「ＤＳ１００００００３」のデバイスがテナントＩＤ「１０００ＡＡ」のデバイスに紐づけされる。

次に、デバイスシリアルＩＤとテナントＩＤとが紐づいた状態での、デバイス５００からリソースサーバモジュール３１０へのＡＰＩ呼び出しについて説明する。まず、ＡＰＩ呼び出しを実施する契機であるが、デバイス５００が備えるセンサーや機器における変化を検知した事が契機となる。より具体的には、例えば、デバイス５００がプリンタである場合は、ＡＰＩ呼び出しを実施する契機は、リモートからの印刷要求をうけ、印刷が行われたときや、プリンタが印字するためのインクやトナーといった材料の残量が低下したとき等である。デバイス５００が、スマートフォンである場合は、ＡＰＩ呼び出しを実施する契機は、通話が行われたときである。デバイス５００が、ＧＰＳを備える機器である場合は、ＡＰＩ呼び出しを実施する契機は、特定の場所へ移動したとき等である。その他の契機として、デバイス５００の利用者に関する生体認証の実施時や、心拍の変化等が発生した時等が考えられる。デバイス５００は、デバイス５００が備えるセンサーや機器における変化を検知した場合に、図６に示すシーケンスを実施する。

図６は、デバイスによる、リソースサーバモジュールのＡＰＩを呼び出す処理を説明する図である。
Ｓ２．１において、デバイス５００での変化を検知したことを契機として、リソースサーバ連携アプリケーション５４０が、アクセストークンプロバイダ５３０に対して、認可トークンを要求する。その際、リソースサーバ連携アプリケーション５４０は、リソースサーバモジュール３１０の公開するＡＰＩに合わせたスコープ「ＡＰＩ」を権限範囲として要求する。

Ｓ２．２において、アクセストークンプロバイダ５３０が、認可サーバモジュール２１０に対して認可トークン要求を行う。認可トークン要求には、ベンダークライアントＩＤ、シークレットおよびリソースサーバ連携アプリケーション５４０から取得したスコープ「ＡＰＩ」が含まれる。

Ｓ２．３において、認可サーバモジュール２１０が、ベンダークライアントを認証する。より具体的には、認可サーバモジュール２１０が、取得したベンダークライアントＩＤとシークレットの組が、クライアント管理テーブルに登録されているか否かを検証する。ベンダークライアントＩＤとシークレットの組が、クライアント管理テーブルに登録されている場合に、ベンダークライアントの認証が成功する。続いて、Ｓ２．４において、認可サーバモジュール２１０が、認証したベンダークライアントに紐づく認可トークンを発行する。より具体的には、認可サーバモジュール２１０は、認可トークンＩＤを発行し、トークン管理テーブルにおいて、認可トークンＩＤに紐付けて、トークン種別「認可トークン」、のクライアントＩＤ（ベンダークライアントＩＤ）、スコープ「ＡＰＩ」を管理する。表５に認可サーバモジュール２１０が備えるトークン管理テーブルを示す。

また、前述した表１に示すクライアント管理テーブルにおいて、クライアントＩＤに紐付けて、テナントＩＤ「ベンダー」とデバイスシリアルＩＤが管理されている。したがって、認可サーバモジュールは、トークン管理テーブルとクライアント管理テーブルを介して、デバイス５００とテナントとに紐付けて認可トークンを管理していることになる。

Ｓ２．５において、認可サーバモジュール２１０が、発行した認可トークンＩＤをアクセストークンプロバイダ５３０に応答する。Ｓ２．６において、アクセストークンプロバイダ５３０が、取得した認可トークンＩＤ、ベンダークライアントＩＤ、シークレット、リソースサーバ連携アプリケーション５４０から取得したアプリケーションＩＤ「ＡＰＰ０００１」を用いて、以下の処理を行う。アクセストークンプロバイダ５３０は、認可サーバモジュール２１０に対してアプリケーション用認可トークン発行を要求する。その際、アクセストークンプロバイダ５３０は、リソースサーバ連携アプリケーション５４０から取得したスコープ「ＡＰＩ」を要求する。アプリケーション用認可トークンは、認可トークンＩＤに対して紐づける情報としてアプリケーションＩＤが追加された認可トークンである。アクセストークンプロバイダ５３０は、認可トークンを要求してきたアプリケーションに対して、専用の認可トークンとしてアプリケーション用認可トークンを提供する。

Ｓ２．７において、認可サーバモジュール２１０が、Ｓ２．３における処理と同様に、ベンダークライアントを認証する。Ｓ２．８において、認可サーバモジュール２１０が、取得した認可トークンＩＤがトークン管理テーブルに登録されているか検証する。認可トークンＩＤがトークン管理テーブルに登録されている場合は、認可トークンの認証が成功する。

Ｓ２．９において、認可サーバモジュール２１０が、認証したベンダークライアントおよび取得したアプリケーションＩＤに紐づくアプリケーション用認可トークンを発行する。具体的には、認可サーバモジュール２１０は、認可トークンＩＤを発行する。そして、トークン管理テーブルにおいて、認可トークンＩＤに紐付けて、トークン種別「認可トークン」、クライアントＩＤ（ベンダークライアントＩＤ）、アプリケーションＩＤ「ＡＰＰ０００１」、スコープ「ＡＰＩ」を管理する。表６は、アプリケーション用認可トークンが発行された状態におけるトークン管理テーブルを示す。認可サーバモジュールは、表６のトークン管理テーブルと表１のクライアント管理テーブルを介して、デバイス５００とテナントとに紐付けてアプリケーション用認可トークンを管理していることになる。

Ｓ２．１０において、認可サーバモジュール２１０が、発行したアプリケーション用認可トークンＩＤをアクセストークンプロバイダ５３０に応答する。続いて、Ｓ２．１１において、アクセストークンプロバイダ５３０が、リソースサーバ連携アプリケーション５４０に対して、取得したアプリケーション用認可トークンＩＤを応答する。

Ｓ２．１２において、リソースサーバ連携アプリケーション５４０が、取得したアプリケーション用認可トークンを用いて、リソースサーバモジュール３１０が公開するＡＰＩを呼び出す。ＡＰＩの呼び出しには、検知した変化の情報が含まれる。例えば、デバイス５００がプリンタであり、印刷を契機としてＡＰＩを呼び出す場合は、ＡＰＩの呼び出しには、印刷された文書名や、印刷者、印刷した枚数、カラーかモノクロかを示す情報等が含まれる。

Ｓ２．１３において、リソースサーバモジュール３１０が、認可サーバモジュール２１０に対して、取得したアプリケーション用認可トークンの検証を要求する。Ｓ２．１４において、認可サーバモジュール２１０が、取得したアプリケーション用認可トークンが、トークン管理テーブルに登録されているかを検証する。アプリケーション用認可トークンがトークン管理テーブル登録されている場合は、認可サーバモジュール２１０は、以下の処理を実行する。認可サーバモジュール２１０は、トークン管理テーブルおよびクライアント管理テーブルを参照して、アプリケーション用認可トークンＩＤに紐づく情報として、ベンダークライアントＩＤ、デバイスシリアルＩＤ、およびテナントＩＤを応答する。

Ｓ２．１５において、リソースサーバモジュール３１０が、デバイス登録ＡＰＩに応じた処理として、取得したテナントＩＤを確認する。テナントＩＤが「ベンダー」を示す値であった場合に、リソースサーバモジュール３１０は、以下の処理を実施する。リソースサーバモジュール３１０は、取得したデバイスシリアルＩＤがデバイス管理テーブルに登録されているか確認する。登録されている場合は、デバイスシリアルＩＤに紐づいたテナントＩＤを取得する。そして、リソースサーバモジュール３１０は、ＡＰＩ呼び出し時に受信した各種デバイス５００で検出した情報を、デバイスシリアルＩＤに紐づいたテナントＩＤの情報として取り扱う。より具体的には、例えば、テナントＩＤに所属するユーザのみが参照可能な形式で不揮発メモリに記憶する。また、例えば、テナントＩＤに所属するユーザに対して、電子メールを送信する。どのような処理を行うかは、公開するＡＰＩ毎に定義される。続いて、Ｓ２．１６において、リソースサーバモジュール３１０が、ＡＰＩの応答をリソースサーバ連携アプリケーション５４０に返して、処理を終了する。以上、第一の方式による、デバイス５００の情報をクラウドサービス、つまりリソースサーバモジュール３１０が公開するＡＰＩへ通知する処理について説明した。

本実施形態では、デバイスシリアルＩＤとテナントＩＤとを、直接デバイスシリアルＩＤをリソースサーバモジュール３１０に登録することで紐付ける処理例を説明したが、デバイスシリアルＩＤとテナントＩＤとの紐付けを他の処理で実現してもよい。例えば、テナントＩＤ毎にデバイスを登録するためのキーを発番し、そのキーをデバイスに入力し、デバイスがリソースサーバモジュール３１０に自身のデバイスシリアルＩＤと共に通知する構成を採ってもよい。この構成の場合は、リソースサーバ３００に、キーに紐づくテナントＩＤがデバイスシリアルＩＤと紐づけられて登録される。また、別途、不図示のデバイスシリアルＩＤを管理する管理サーバを設け、管理サーバがデバイスシリアルＩＤとテナントとの結びつき情報を管理し、リソースサーバモジュール３１０が通信してテナントの情報を取得するような構成も考えられる。

また、後述する第二の方式で用いるＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔにて発行された認可トークンを利用して、デバイスシリアルＩＤとテナントＩＤを紐づける構成を採ってもよい。この構成を採る場合は、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔによって権限委譲したユーザが所属するテナントのテナントＩＤと、権限委譲されたベンダークライアントに紐づくデバイスシリアルＩＤとが紐づけられる。

第一の方式では、デバイス５００と、デバイス５００を利用するユーザが所属するテナントとの紐づけを、デバイス５００を識別するためのデバイスシリアルＩＤを用いている。そのため、以下の課題が発生する。デバイス５００のユーザが、リサイクルにより別のテナントのユーザに変更されたとする。その際、リソースサーバモジュール３１０に対して通知が行われ、リソースサーバモジュール３１０が保存しているデバイス５００からの通知データが削除されるのであれば問題ない。しかし、リソースサーバモジュール３１０に対して通知が無かった場合、新しいユーザがデバイス５００を利用した場合のデータが、デバイスシリアルＩＤが紐づく旧ユーザのテナントＩＤに紐づいて保存されるリスクがある。その結果、新しいユーザに付随する機密情報や個人情報が別のテナントのユーザに漏洩されるリスクが発生する。以上が、第一の方式による課題の説明である。

次に、第二の方式について説明する。第二の方式では、ユーザが、ベンダークライアントであるアクセストークンプロバイダ５３０に対して、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを用いて自身の権限を委譲する。そして、リソースサーバモジュール３１０は、権限を委譲したユーザが所属するテナントＩＤに紐付けて、サービスの提供に係るデータを保存する。

第二の方式では、まず、ユーザがアクセストークンプロバイダ５３０に対して権限を委譲するフローが必要となる。この権限を委譲するフローを開始するタイミングとしては、以下の２種のパターンが考えられる。第１のパターンは、ユーザが、Ｗｅｂブラウザ４１０、５１０を用いて、アクセストークンプロバイダ５３０が提供するサイトへのアクセスしたことをもって、権限を委譲するフローを開始するパターンである。第２のパターンは、ユーザによるリソースサーバ連携アプリケーションの操作時に、リソースサーバ連携アプリケーションがＷｅｂブラウザ５１０を用いてアクセストークンプロバイダが提供するサイトへアクセスすることでフローを開始するパターンである。

図７は、権限委譲の開始が行われた場合の処理を説明する図である。
認可サーバモジュール２１０のユーザ管理テーブルおよびクライアント管理テーブルは、第一の方式の説明時と同様である。本実施形態において、ユーザは、ユーザＩＤ「ｕｓｅｒ＠ｘｘ．ｃｏｍ」および、そのパスワードを利用するものとして説明する。また、アクセストークンプロバイダ５３０は、ベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」の各種データである、シークレット、リダイレクトＵＲＩを保持している。リダイレクトＵＲＩは、アクセストークンプロバイダ５３０が、認可応答を受け付けるためのＵＲＩである。これら各種データは、図４を参照して説明したベンダークライアント登録処理によって認可サーバモジュール２１０に登録されている。

Ｓ３．１において、Ｗｅｂブラウザ４１０、５１０が、アクセストークンプロバイダ５３０に対して権限委譲開始要求を行う。Ｓ３．２において、権限委譲開始要求を受けたアクセストークンプロバイダ５３０が、Ｗｅｂブラウザ４１０、５１０を介して、認可サーバモジュール２１０に対して認可要求を行う。Ｓ３．３の認可要求から、Ｓ３．２０の認可トークン、リフレッシュトークン応答までの認可トークン、リフレッシュトークンの発行処理は、ＯＡｕｔｈ ２．０に定義されているＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔフローに従って実施される。認可要求は、少なくとも、アクセストークンプロバイダ５３０が保持しているベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」と、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」と、スコープ「リソース」を含む。スコープ「リソース」は、アクセストークンプロバイダ５３０がユーザから権限委譲されるリソースの範囲を示す。リダイレクトＵＲＩは、前述したとおり、認可サーバ２００にて発行された認可コードを受け付けるベンダークライアントのＵＲＬである。

Ｓ３．３において、Ｗｅｂブラウザ４１０、５１０から認可要求を受け付けた認可サーバモジュール２１０が、Ｗｅｂブラウザ４１０、５１０からの通知に、ＨＴＴＰ Ｃｏｏｋｉｅとして有効な認証トークンが含まれているか検証する。Ｗｅｂブラウザ４１０、５１０からの通知に有効な認証トークンが含まれている場合、処理がＳ３．９に移行する。Ｗｅｂブラウザ４１０、５１０からの通知に有効な認証トークンが含まれていない場合は、Ｓ３．１０乃至Ｓ３．７の処理として、図５（Ａ）を参照して説明したログイン処理を実施し、Ｓ３．８においてＳ３．３での認可要求を再実施する。

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

図８は、認可確認画面の一例である。
図８（Ａ）は、第二の方式における認可確認画面を示す。認可確認画面８０００は、認可要求に含まれるクライアントＩＤをキーとして、クライアントテーブルから取得したクライアント名８００１を表示する領域であるアクセス元表示領域８００１を備える。認可確認画面８０００は、さらに、認可要求で取得したスコープに対応する説明を表示する領域である委譲権限表示領域８００２を備える。今回はスコープとして「リソース」が要求されたため、本画面例では、リソースサーバのリソースが権限委譲の範囲として提示される。また、認可確認画面８０００は、ユーザが上記情報の内容について認可操作を実行する許可ボタン８００３と、拒否を実行する拒否ボタン８００４とを備える。

図７の説明に戻る。Ｓ３．１１において、ユーザが許可ボタン８００３を押下して認可操作を行う。Ｓ３．１２において、Ｗｅｂブラウザ４１０、５１０が、認可確認結果を認可サーバモジュール２１０に通知する。Ｓ３．１３において、認可サーバモジュール２１０が、認可コードを発行する。より具体的には、認可サーバモジュール２１０は、トークンＩＤ「ｃｄ＿０００００１」を発行する。認可サーバモジュール２１０は、認可要求内のベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」とリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」、スコープ「リソース」、ＵＵＩＤ「１００００００１」をトークン管理テーブルに登録する。ＵＵＩＤ「１００００００１」は、認証し許可を得たユーザのユーザＩＤに対応するＵＵＩＤである。その際、トークン種別を認可コードとする。なお、不図示の項目として有効期限として，認可コードが有効である期限の日時を登録する事もできる。なお、トークンが有効か否かを示す状態を登録する事もできる。その場合は、有効期限ではなく、状態が有効であるかを検証する事となる。表７は、認可サーバモジュールが備えるトークン管理テーブルの例を示す。

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

Ｓ３．１６において、アクセストークンプロバイダ５３０が、認可サーバモジュール２１０に対して認可トークンを要求する。認可トークン要求は、少なくとも、認可コード「ｃｄ＿０００００１」、ベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」、認可要求時に送信したリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」を含む。

Ｓ３．１７において、認可サーバモジュール２１０が、取得したベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」の組を用いてクライアントを認証する。より具体的には、ベンダークライアントＩＤとシークレットの組がクライアントテーブルにある場合に、クライアント認証が成功する。クライアント認証に失敗した場合は、認可サーバモジュール２１０が、アクセストークンプロバイダ５３０に認証エラーを応答する。クライアント認証に成功した場合は、処理がＳ３．１８に進む。

Ｓ３．１８において、認可サーバモジュール２１０が、取得した認可コード「ｃｄ＿０００００１」を検証する。具体的には、認可サーバモジュール２１０は、取得した認可コードがトークン管理テーブルに登録されているかを検証し、登録されている場合は、認可コードが有効であるかを検証する。認可コードが有効である場合、認可サーバモジュール２１０は、認可トークン要求にて取得したベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」とリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」を用いて、以下の検証を実施する。認可サーバモジュール２１０は、ベンダークライアントＩＤ、リダイレクトＵＲＩが、トークン管理テーブルのベンダークライアントＩＤ、リダイレクトＵＲＩと一致するかを検証する。ベンダークライアントＩＤ、リダイレクトＵＲＩが、トークン管理テーブルのベンダークライアントＩＤ、リダイレクトＵＲＩと一致する場合は、認可コードの検証結果が有効となる。

認可コードの検証結果が無効である場合、認可サーバモジュール２１０は、アクセストークンプロバイダ５３０にエラーを応答する。認可コードの検証結果が有効である場合、Ｓ３．１９において、認可サーバモジュール２１０が認可トークンを発行する。具体的には、認可サーバモジュール２１０は、トークンＩＤ「ａｔ＿０００００１」を発行する。そして、認可サーバモジュール２１０は、認可コードに紐づくユーザのＵＵＩＤ「１００００００１」、スコープ「リソース」、認証したベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークン管理テーブルに登録する。その際、認可サーバモジュール２１０は、トークン種別を認可トークンとし、有効期限として当該認可トークンが有効である期限の日時を登録する。

Ｓ３．２０において、認可サーバモジュール２１０が、リフレッシュトークンを発行する。より具体的には、認可サーバモジュール２１０は、トークンＩＤ「ｒｔ＿０００００１」を発行する。そして、認可サーバモジュール２１０は、認可トークン「ａｔ＿０００００１」に紐づくユーザのＵＵＩＤ「１００００００１」、スコープ「リソース」、および認証したベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークン管理テーブルに登録する。その際、トークン種別をリフレッシュトークンとする。また、有効期限として、リフレッシュトークンが有効である期限の日時を登録する事もできる。また、ＯＡｕｔｈ ２．０では、認可コードは一度しか利用できないように制御することが推奨されている。したがって、認可サーバモジュール２１０は、トークンＩＤ「ｃｄ＿０００００１」の認可コードの状態を「無効」にする。なお、認可コードの状態を無効にする方法として、状態を利用するのではなく、有効期限を過去の日時に更新することで無効扱いとすることや、テーブルのレコードそのものを削除することで無効にするという方法を用いてもよい。表８は、認可サーバモジュールのトークン管理テーブルを示す。表８中、ハッチングを施した行は、無効となったレコードを示す。

Ｓ３．２１において、認可サーバモジュール２１０が、発行した認可トークンのトークンＩＤ「ａｔ＿０００００１」、リフレッシュトークンのトークンＩＤ「ｒｔ＿０００００１」をアクセストークンプロバイダ５３０に応答する。以上が、ＯＡｕｔｈ ２．０における、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用した、ユーザがアクセストークンプロバイダ５３０へ権限を委譲するフローの説明である。

アクセストークンプロバイダ５３０は、取得したリフレッシュトークンを不揮発メモリに保存する。その際、アクセストークンプロバイダ５３０は、リフレッシュトークンをアプリケーションＩＤに紐づけて保存する。これにより、アプリケーションＩＤが示すアプリケーションつまりリソースサーバ連携アプリケーション５４０からのリクエストによりリフレッシュトークンを取り出す事が可能となる。

認可サーバモジュール２１０が、デバイス５００のログインアプリケーション５２０が生成したログインコンテキストに紐づけてリフレッシュトークンを保存する構成を採ってもよい。そして、再度ユーザがデバイス５００にログインした場合に、認可サーバモジュール２１０が、ログインコンテキストを元に保存されたリフレッシュトークンを取り出すようにしてもよい。さらに、権限を委譲するフローを開始するタイミングが、第２のパターン、つまりリソースサーバ連携アプリケーション５４０の操作を契機に開始している場合は、取得した認可トークンを用いて、アプリケーション用認可トークンを発行し、応答してもよい。

次に、デバイス５００とテナントＩＤとを紐づける方法について説明する。ここで、第二の方式においてデバイス５００とテナントＩＤとを紐づける方法としては、以下の２種の方法が考えられる。第一の方法では、アクセストークンプロバイダ５３０が保存したリフレッシュトークンを用いて認可トークンを発行し、認可トークンからアプリケーション用認可トークンを発行する。そして、アプリケーション用認可トークンに紐づくユーザのテナントＩＤを用いて、第一の方式と同様に、リソースサーバモジュール３１０においてデバイスシリアルＩＤとテナントＩＤとを紐づける。なお、第二の方式における第一の方法は、第一の方式と比較して、デバイスの登録方法に差異があるだけであり、結果的にデバイスとテナントを紐づける情報はデバイスのデバイスシリアルＩＤであるので、第一の方式と同様の課題がある。

第二の方法は、アクセストークンプロバイダ５３０が保存したリフレッシュトークンを用いて、都度アプリケーション用認可トークンを発行し、アプリケーション用認可トークンに紐づくユーザのテナントＩＤを利用する方法である。第二の方法は、デバイスとテナントとの紐づけを行うタイミングが，第一の方式や、第二の方式の第一の方法と異なる。第一の方式や、第二の方式の第一の方法では、デバイスシリアルＩＤとテナントＩＤとを予め紐づけておき、その後、デバイス５００が、主体的にリソースサーバモジュール３１０へのＡＰＩ呼び出しを開始する。第二の方式の第二の方法は、デバイスシリアルＩＤとテナントＩＤを紐づけるのではなく、リソースサーバへのＡＰＩ呼び出しに用いられたアプリケーション用認可トークンに紐づくユーザのテナントＩＤを用いて、都度、テナントＩＤを特定し、処理を実行する。以下、詳細について説明する。

まず、ＡＰＩ呼び出しを実施する契機は、アクセストークンプロバイダ５３０にリフレッシュトークンを保存する構成によって異なる。リフレッシュトークンがアプリケーションＩＤに紐づけて保存されている場合は、第二の方法においても第一の方式と同様の契機でＡＰＩ呼び出しを実施する。一方、ログインコンテキストに紐づけて保存された場合は、ＡＰＩ呼び出しを実施する契機は、ユーザがデバイス５００にログインした状態で、デバイス５００を操作した場合に限定される。

デバイス５００が複写機である場合は、ＡＰＩ呼び出しを実施する契機は、例えばデバイス５００にて複写操作をしたとき等である。デバイス５００がスマートフォンである場合は、ＡＰＩ呼び出しを実施する契機は、通話が行われたとき等である。デバイス５００がＧＰＳを備える機器である場合は、ＡＰＩ呼び出しを実施する契機は、特定の場所へ移動したとき等である。その他、デバイス５００の利用者から得られる生体認証が行われたとき、または心拍の変化等が発生したときを、ＡＰＩ呼び出しを実施する契機としてもよい。

図９は、デバイスによる、リソースサーバモジュールのＡＰＩを呼び出す処理を説明する図である。
デバイス５００での変化が検知されたことを契機として、Ｓ４．１において、リソースサーバ連携アプリケーション５４０が、アクセストークンプロバイダ５３０に対して認可トークンを要求する。その際、リソースサーバ連携アプリケーション５４０は、リソースサーバモジュール３１０の公開するＡＰＩに合わせたスコープを権限範囲として要求する。

次に、アクセストークンプロバイダ５３０は、リフレッシュトークンを保存した構成に従って、リフレッシュトークンを特定し取得する。例えば、リフレッシュトークンがログインコンテキストに紐付けて保存されていて、ユーザがログインしている場合は、ログインコンテキストに基づいてリフレッシュトークンを取得する。リフレッシュトークンがアプリケーションＩＤに紐付けて保存されている場合は、アプリケーションＩＤに基づいてリフレッシュトークンを取得する。

Ｓ４．２において、アクセストークンプロバイダ５３０が、認可サーバモジュール２１０に対してリフレッシュ要求を行う。このリフレッシュ要求には、ベンダークライアントＩＤ、シークレットおよび取得したリフレッシュトークンが含まれる。Ｓ４．３において、認可サーバモジュール２１０が、リフレッシュ要求に起因して、ベンダークライアントを認証する。より具体的には、認可サーバモジュール２１０は、取得したベンダークライアントＩＤとシークレットの組がクライアント管理テーブルに登録されているか否かを検証する。続いて、Ｓ４．４において、認可サーバモジュール２１０が、取得したリフレッシュトークンの検証を行う。より具体的には、認可サーバモジュール２１０は、取得したリフレッシュトークンがトークン管理テーブルに登録されているか、登録されている場合は、有効かを検証する。さらに、認可サーバモジュール２１０は、リフレッシュ要求によって取得したベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」がトークン管理テーブルのクライアントＩＤと一致するかを検証する。

次に、Ｓ４．５において、認可サーバモジュール２１０が、認可トークンを発行する。より具体的には、認可サーバモジュール２１０は、トークンＩＤ「ａｔ＿０００００２」を発行する。そして、認可サーバモジュール２１０は、リフレッシュトークンに紐づくユーザのＵＵＩＤ「１００００００１」、スコープ「ＡＰＩ」、および認証したベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」をトークン管理テーブルに登録する。その際、トークン種別は認可トークンとし、有効期限として当該認可トークンが有効である期限の日時を登録する。さらに、認可サーバモジュール２１０が、新たなリフレッシュトークンを発行するようにしてもよい。その際、古いリフレッシュトークンは無効化される。表９は、認可サーバモジュールのトークン管理テーブルの例を示す。

Ｓ４．６において、認可サーバモジュール２１０が、発行した認可トークンのトークンＩＤ「ａｔ＿０００００２」をアクセストークンプロバイダ５３０に応答する。その際、認可サーバモジュール２１０は、新しいリフレッシュトークンを発行した場合は、合わせて応答する。以降、Ｓ４．７からＳ４．１２の処理については、図６を参照して説明したＳ２．６からＳ２．１１の処理と同様である。

Ｓ４．１３において、リソースサーバ連携アプリケーション５４０が、取得したアプリケーション用認可トークンを用いて、リソースサーバモジュール３１０が公開するＡＰＩを呼び出す。ＡＰＩの呼び出しには、検知されたデバイス５００における変化の情報が含まれる。例えば、デバイス５００が複写機であり、複写を契機としてＡＰＩ呼び出しする場合は、ＡＰＩの呼び出しには、複写した者、複写した枚数、カラーかモノクロか、といった情報が含まれる。

Ｓ４．１４において、リソースサーバモジュール３１０が、認可サーバモジュール２１０に対して取得したアプリケーション用認可トークンの検証を要求する。続いて、Ｓ４．１５において、認可サーバモジュール２１０が、取得したアプリケーション用認可トークンがトークン管理テーブルに登録されているかを検証する。アプリケーション用認可トークンがトークン管理テーブルに登録されている場合は、認可サーバモジュール２１０は、アプリケーション用認可トークンＩＤに紐づく情報として、以下の情報を応答する。認可サーバモジュール２１０は、ユーザのＵＵＩＤ、ユーザのテナントＩＤ、ベンダークライアントＩＤ、デバイスシリアルＩＤ、およびベンダークライアントのテナントＩＤを応答する。ベンダークライアントのテナントＩＤは、表１に示すクライアント管理テーブルから取得される。ユーザのテナントＩＤは、表２に示すユーザ管理テーブルから取得される。

Ｓ４．１６において、リソースサーバモジュール３１０が、ＡＰＩに応じた処理として、取得したユーザのテナントＩＤを確認する。リソースサーバモジュール３１０は、ユーザのテナントＩＤを用いて、以下の処理を実施する。リソースサーバモジュール３１０は、ＡＰＩ呼び出し時に受信した、各種デバイス５００で検出した情報を、取得したユーザのテナントＩＤの情報として取り扱う。リソースサーバモジュール３１０は、例えば、ユーザのテナントＩＤに所属するユーザのみが参照可能な形式でＡＰＩ呼び出し時に受信した情報を不揮発メモリに記憶する。また、リソースサーバモジュール３１０は、例えば、ユーザのテナントＩＤに所属するユーザに対して、電子メールを送信する。どのような処理を行うかは、公開するＡＰＩ毎に定義される。

次に、Ｓ４．１７において、リソースサーバモジュール３１０が、ＡＰＩの応答をリソースサーバ連携アプリケーション５４０に返して、処理を終了する。以上、第二の方式における第二の方法を用いた、リソースサーバモジュール３１０が提供するサービスの利用について説明した。

前述した通り、第二の方式に関する構成のうち、リフレッシュトークンをログインコンテキストに紐づけて保存する構成は、ユーザがデバイス５００を操作したときに限って利用可能である。そのため、例えば、ユーザのログインと関係しない契機によって発生する情報を送信する場合には、利用できない。一方、第二の方式に関する構成のうち、リフレッシュトークンをアプリケーションＩＤと紐づけて保存する構成では、デバイスとテナントとを紐づけるためにユーザを仲介している。したがって、当該ユーザが認可サーバモジュール２１０の利用を停止した場合は、継続的に利用できない。

次に、第三の方式、つまりＣｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔを用いた２種目の方式について説明する。第三の方式は、本実施形態における、最も特徴的な方式である。第三の方式は、Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔを用いるためのクライアントＩＤ、シークレットを、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用して動的に発行することに特徴がある。第三の方式は、第一、第二の方式のデメリットがないので、最も情報の漏洩リスクが低い方式である。以下、この第三の方式について図４、図６乃至図９を参照して説明する。

第三の方式では、第二の方式と同様に、まず、ユーザがアクセストークンプロバイダ５３０に対して権限を委譲する。権限を委譲するフローを開始するタイミングとしては、以下の２種のパターンが考えられる。まず第１のパターンは、ユーザが、Ｗｅｂブラウザ４１０、５１０を用いてアクセストークンプロバイダ５３０の権限委譲を開始するサイトへアクセスすることをもって開始するパターンである。第２のパターンは、ユーザによるリソースサーバ連携アプリケーションの操作時に、リソースサーバ連携アプリケーションがＷｅｂブラウザ５１０を用いてアクセストークンプロバイダ５３０のサイトへアクセスすることをもってフローが開始するパターンである。第三の方式では、この２種のパターンによって以降の処理の方法が違うため、それぞれ第一の方法、第二の方法として説明する。

まず、第三の方式における第一の方法、すなわち、ユーザが、Ｗｅｂブラウザ４１０、５１０を用いてアクセストークンプロバイダ５３０の権限委譲を開始するサイトへのアクセスをもって開始する方法について説明する。なお、権限委譲の開始が行われた場合のシーケンスについて、図７を参照して説明するが、第二の方式の説明で図７を参照して述べた処理と同様の処理の説明は省略する。

図７のＳ３．１において、Ｗｅｂブラウザ４１０、５１０からアクセストークンプロバイダ５３０に権限委譲開始要求が行われる。Ｓ３．２において、権限委譲開始要求を受けたアクセストークンプロバイダ５３０が、Ｗｅｂブラウザ４１０、５１０を介して、認可サーバモジュール２１０に対して認可要求を行う。

Ｓ３．３の認可要求から、Ｓ３．２０の認可トークン、リフレッシュトークン応答までの認可トークン、リフレッシュトークンの発行処理は、ＯＡｕｔｈ ２．０に定義されているＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔフローに従って実施される。認可要求には、少なくとも、アクセストークンプロバイダ５３０が保持しているベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」、スコープ「テナント専用クライアント」を含む。スコープ「テナント専用クライアント」は、アクセストークンプロバイダ５３０がユーザから権限委譲されるリソースの範囲を示す。リダイレクトＵＲＩは、認可サーバ２００にて発行された認可コードを受け付けるベンダークライアントのＵＲＬである。Ｓ３．２からＳ３．９までの処理については、第二の方式と同様であるので、説明を省略する。Ｓ３．１０において、認可サーバモジュール２１０が、認可確認画面データをＷｅｂブラウザ４１０，５１０に対して応答する。すなわち、認可サーバモジュール２１０は、認可要求に応じて、ユーザが操作する端末に対して認可確認画面データを送信する画面送信手段として機能する。

図８（Ｂ）は、第三の方式において表示される認可確認画面の例である。
Ｗｅｂブラウザ４１０，５１０が、認可確認画面データに基づいて認可確認画面８０００を表示する。認可確認画面８０００は、アクセス元表示領域８００１を備える。アクセス元表示領域８００１は、認可要求に含まれるクライアントＩＤをキーとしてクライアントテーブルから取得されたクライアント名８００１が表示される領域である。また、認可確認画面８０００は、委譲権限表示領域８００２を備える。委譲権限表示領域８００２は、認可要求で取得したスコープに対応する説明が表示される領域である。今回はスコープとして「テナント専用クライアント」が要求されたので、本画面例では、テナント専用クライアントを作成する権限が権限委譲の範囲として表示される。

また、認可確認画面８０００は、ユーザがアクセス元表示領域８００１，委譲権限表示領域８００２に表示された情報の内容に関する認可操作を実行するための許可ボタン８００３、および拒否操作を実行するための拒否ボタン８００４を備える。以降Ｓ３．１２までは第二の方式と同様の処理である。ユーザは、許可ボタン８００３を押下することで、テナント専用クライアントを作成する権限をデバイス５００に委譲することを許可する指示を出す。本実施形態では、テナント専用クライアントに対応するテナントは、テナント専用クライアントを作成する権限を委譲したユーザが所属するテナントである。

Ｓ３．１３において、認可サーバモジュール２１０が、認可コードを発行する。より具体的には、認可サーバモジュール２１０は、トークンＩＤ「ｃｄ＿０００００１」を発行する。そして、認可要求に含まれるベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」、スコープ「テナント専用クライアント」、ＵＵＩＤ「１００００００１」をトークン管理テーブルに登録する。ＵＵＩＤ「１００００００１」は、認証し許可を得たユーザのユーザＩＤに対応する。なお、不図示の項目として、有効期限として当該認可コードが有効である期限の日時を登録する事もできる。また、トークンが有効か否かを示す状態を「有効」として登録する事もできる。トークンが有効か否かを示す状態を登録する場合は、有効期限ではなく、状態が有効であるかを検証する事となる。表１０は、Ｓ３．１３の処理後の認可サーバモジュールのトークン管理テーブルの例を示す。

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

Ｓ３．１６において、アクセストークンプロバイダ５３０が、認可サーバモジュール２１０に対して認可トークンを要求する。認可トークン要求には、少なくとも、認可コード「ｃｄ＿０００００１」、ベンダークライアントＩＤ「ｃ００１＠ｘｘ．ｃｏｍ」、シークレット「ｘｘｘｘｘｘｘｘｘｘ」、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｘｘ／ｒｅｓ」が含まれる。また、認可トークン要求には、スコープ「テナント専用クライアント」が含まれる。

以降、Ｓ３．２１まで、各種トークンに設定されるスコープが「テナント専用クライアント」である事を除き、第二の方式と同様の処理が行われる。以上が、ＯＡｕｔｈ ２．０におけるＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用した、ユーザがアクセストークンプロバイダ５３０へテナント専用クライアントを作成する権限を委譲するフローの説明である。以上の説明から、認可サーバモジュール２１０は、認可確認画面を介し、ユーザがテナント専用クライアントを作成する権限をデバイス５００に委譲することを許可する指示をした場合に、認可トークンを発行する第１の発行手段として機能する。また、アクセストークンプロバイダ５３０は、認可サーバ２００への第１のクライアント（ベンダークライアント）の登録に応じて提供された第１の認証情報を基に、以下の処理をする第１の取得要求手段として機能する。第１の認証情報は、ベンダークライアントＩＤとシークレットである。アクセストークンプロバイダ５３０は、第２のクライアント（テナント専用クライアント）を作成するユーザの権限が、ベンダークライアントとしてのデバイス５００へ委譲されたことを示す第１の認可情報（認可トークン）の取得要求をする（Ｓ３．１６）。

次に、図４を参照して、アクセストークンプロバイダ５３０が、図７のＳ３．２１において取得した認可トークンを用いて行う処理について説明する。
Ｓ１．１において、デバイス５００のアクセストークンプロバイダ５３０が、認可サーバ２００が備えるＨＴＴＰサーバモジュール２２０に対して、テナント専用クライアントの登録要求（テナント専用クライアント登録要求）を行う。テナント専用クライアント登録要求は、少なくとも図７を参照して説明した処理によって取得された取得した認可トークンを含む。

アクセストークンプロバイダ５３０からのテナント専用クライアント登録要求を受け付けたＨＴＴＰサーバモジュール２２０は、Ｓ１．２の認証を省略し、Ｓ１．３において、テナント専用クライアント登録要求を認可サーバモジュール２１０に通知する。Ｓ１．４において、認可サーバモジュール２１０が、認証情報として、ＨＴＴＰサーバモジュール２２０から通知された認可トークンの情報を取得する。次に、Ｓ１．５において、認可サーバモジュール２１０が、取得した認可トークンに基づいて、トークン管理テーブルから認可トークンに紐づくユーザのテナントＩＤの情報を取得する。トークン管理テーブルに該当のレコードが無い場合、認可サーバモジュール２１０が、ＨＴＴＰサーバモジュール２２０を介して、アクセストークンプロバイダ５３０にエラーを応答する。

次に、Ｓ１．６において、認可サーバモジュール２１０が、クライアント管理テーブルにテナント専用クライアントを新規登録する。より具体的には、認可サーバモジュール２１０は、クライアントＩＤ、シークレットを発行し、それぞれクライアント管理テーブルに格納する。以後、ここで発行し登録したクライアントＩＤは、先述のベンダークライアントＩＤとは異なるＩＤである。また、認可サーバモジュール２１０は、取得したテナントＩＤを、クライアント管理テーブルに格納する。テナントＩＤは、権限委譲したユーザが所属するテナントＩＤとなる。表１１は、テナント専用クライアントが新規登録されたクライアント管理テーブルの例を示す。

なお、登録されたテナント専用クライアントに対してデフォルトで設定すべき権限を証明書管理テーブルに予め設定しておき、その設定に従って、Ｓ１．６で登録したテナント専用クライアントに対してデフォルトの権限を付与するよう構成する事もできる。また、デフォルトで設定すべき権限をスコープとして定義し、そのスコープも合わせて権限委譲することによって、テナント専用クライアントにスコープに対応する権限を付与するよう構成してもよい。

テナント専用クライアントの登録が完了した後に、Ｓ１．７において、認可サーバモジュール２１０が、発行したテナント専用クライアントＩＤとシークレットとを、ＨＴＴＰサーバモジュール２２０を介してアクセストークンプロバイダ５３０に応答する。以上がテナント専用クライアントの登録処理の説明である。

次に、テナント専用クライアントが発行された後の、デバイス５００からリソースサーバモジュール３１０へのＡＰＩ呼び出しについて説明する。
まず、ＡＰＩ呼び出しの実施は、デバイス５００に備えるセンサーや機器における変化を検知した事が契機となる。例えば、デバイス５００がプリンタである場合は、ＡＰＩ呼び出しの実施の契機は、リモートからの印刷要求を受けて印刷が行われたときや、プリンタが印字するためのインクやトナーといった材料の残量が低下したとき等である。例えば、デバイス５００がスマートフォンである場合は、ＡＰＩ呼び出しの実施の契機は、通話が行われたとき等である。また、例えば、デバイス５００がＧＰＳを備える機器の場合は、特定の場所へ移動したとき等が契機として考えられる。その他、デバイス５００の利用者の生体認証が実施されたとき、心拍の変化が生じたとき等が契機として考えられる。デバイス５００はこれらを検知し、以下のシーケンスを実施する。

次に、図６を参照して、デバイス５００によるリソースサーバモジュール３１０のＡＰＩを呼び出すシーケンスについて説明する。なお、図６を参照して前述したシーケンスと同様である部分の説明は省略し、差異がある部分のみ説明する。
デバイス５００での変化の検知を契機として、Ｓ２．１において、リソースサーバ連携アプリケーション５４０が、アクセストークンプロバイダ５３０に対してテナント専用クライアントの認可トークンを要求する。その際、リソースサーバモジュール３１０の公開するＡＰＩに合わせたスコープを権限範囲として要求する。

Ｓ２．２からＳ２．１１までの処理は、スコープ以外については前述した処理と同様である。具体的には、Ｓ２．６において、アクセストークンプロバイダ５３０は、認可トークンＩＤ、テナント専用クライアントＩＤ、シークレット、アプリケーションＩＤを用いて、認可サーバモジュール２１０に対してアプリケーション用認可トークン発行を要求する。すなわち、アクセストークンプロバイダ５３０は、認可サーバから提供された第２の認証情報（テナント専用クライアントＩＤとシークレット）を基に、第２の認可情報（アプリケーション用認可トークン）の取得要求をする第２の取得要求手段として機能する。このアプリケーション用認可トークンは、サービスの利用に関する特定の権限がデバイス５００（この場合は、テナント専用クライアントとしてのデバイス）に委譲されたことを示す。

また、Ｓ２．９において、認可サーバモジュール２１０は、認証したテナント専用クライアントおよびアプリケーションＩＤに紐づくアプリケーション用認可トークンを発行する。認可サーバモジュール２１０は、認可トークンＩＤを発行し、前述した表１０の構成のトークン管理テーブルに、トークン種別を「認可トークン」、クライアントＩＤをテナント専用クライアントＩＤすなわち「ｃ００２＠１０００ＡＡ」として保存する。このトークン管理テーブルと、表１１のクライアント管理テーブルとによって、アプリケーション用認可トークンは、テナント専用クライアントＩＤと、テナント専用クライアントが所属するテナントのテナントＩＤ「１０００ＡＡ」とに紐付くことになる。

Ｓ２．１２において、リソースサーバ連携アプリケーション５４０が、取得したアプリケーション用認可トークンを用いて、リソースサーバモジュール３１０が公開するＡＰＩを呼び出す。すなわち、リソースサーバ連携アプリケーション５４０は、取得されたアプリケーション用認可トークンを基に、リソースサーバ３００のサービスを利用する。ＡＰＩの呼び出しには、検知されたデバイスでの変化の情報が含まれる。例えば、デバイス５００がプリンタであり、印刷を契機としてＡＰＩ呼び出しする場合は、印刷された文書名や、印刷者、印刷した枚数、カラーかモノクロか、といった情報が含まれる。

Ｓ２．１３において、リソースサーバモジュール３１０が、認可サーバモジュール２１０に対して、取得したアプリケーション用認可トークンの検証を要求する。Ｓ２．１４において、認可サーバモジュール２１０が、アプリケーション用認可トークンが、トークン管理テーブルに登録されているかを検証する。アプリケーション用認可トークンがトークン管理テーブルに登録されている場合は、認可サーバモジュール２１０は、以下の処理を実行する。認可サーバモジュール２１０は、トークン管理テーブルとクライアント管理テーブルとを参照して、アプリケーション用認可トークンＩＤに紐づくテナント専用クライアントＩＤとテナントＩＤを応答する。すなわち、認可サーバモジュール２１０は、サービスの利用に伴い送信されるアプリケーション用認可トークンを基に、リソースサーバ連携アプリケーション５４０が特定の権限でサービスを利用することを認可するか否かを検証する認可手段として機能する。

Ｓ２．１５において、リソースサーバモジュール３１０が、ＡＰＩに応じた処理として、取得したテナント専用クライアントのテナントＩＤを確認する。リソースサーバモジュール３１０は、テナント専用クライアントのテナントＩＤを用いて、以下の処理を実施する。リソースサーバモジュール３１０は、ＡＰＩ呼び出し時に受信した各種デバイス５００で検出された情報を、取得したテナント専用クライアントのテナントＩＤの情報として取り扱う。より具体的には、リソースサーバモジュール３１０は、ＡＰＩ呼び出し時に受信した情報を、テナント専用クライアントのテナントＩＤに所属するユーザのみが参照可能な形式で不揮発メモリに記憶する。すなわち、リソースサーバモジュール３１０は、アプリケーション用認可トークンに基づくサービスの提供に関するデータを、テナント専用クライアントに紐付けて保存する保存手段として機能する。リソースサーバモジュール３１０が、テナント専用クライアントのテナントＩＤに所属するユーザに対して、電子メールを送信してもよい。これら、どのようなアクションを行うかは，公開するＡＰＩ毎に定義される。

次に、Ｓ２．１６において、リソースサーバモジュール３１０が、ＡＰＩの応答リソースサーバ連携アプリケーション５４０に応答し、処理を終了する。以上がクライアント登録方式における第三の方式の第一の方法による、リソースサーバモジュール３１０が提供するサービスの利用の説明である。

次に、第三の方式の第二の方法について説明する。ユーザによるリソースサーバ連携アプリケーション５４０の操作時に、リソースサーバ連携アプリケーションがデバイス５００のＷｅｂブラウザを用いてアクセストークンプロバイダの権限委譲を開始するサイトへのアクセスしたことをもって、処理が開始する。

第二の方法では、まず、図７を参照して前述した、第一の方法における、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを用いた認可トークンの取得処理が実施される。次に、アクセストークンプロバイダ５３０が、認可サーバモジュール２１０から取得した認可トークンを用いて、図１０に示す処理を行う。

図１０は、認可サーバモジュールから取得された認可トークンを用いた処理を説明する図である。
図１０のＳ４．８からＳ４．１２までの処理は、図９のＳ４．８からＳ４．１２までの処理と同様であるので、説明を省略する。
Ｓ５．１において、アクセストークンプロバイダ５３０が、認可トークンＩＤ、ベンダークライアントＩＤ、シークレット、リソースサーバ連携アプリケーション５４０から取得したアプリケーションＩＤ「ＡＰＰ０００１」を用いて、以下の処理を実行する。すなわち、アクセストークンプロバイダ５３０は、認可サーバモジュール２１０に対してアプリケーション用認可トークン発行を要求する。その際、リソースサーバ連携アプリケーション５４０から取得したスコープ「テナント専用クライアント」を要求する。このアプリケーション用認可トークンは、アプリケーションＩＤが追加された認可トークンであり、認可トークンＩＤに紐づけられる。アクセストークンプロバイダ５３０は、認可トークンの要求元であるリソースサーバ連携アプリケーション５４０に対して、アプリケーション用認可トークンを提供する。ここでは、認可トークン発行要求と、アプリケーション用認可トークン発行要求とを別シーケンスとして記載するが、認可トークン発行要求時にアプリケーションＩＤを追加し、１回のシーケンスでアプリケーション用認可トークンが取得されるようにしてもよい。

Ｓ５．２において、デバイス５００のリソースサーバ連携アプリケーション５４０が、テナント専用クライアント登録要求を認可サーバモジュール２１０に通知する。その際、取得したアプリケーション用認可トークンを認証情報として送信する。リダイレクトＵＲＩを登録する場合は、リソースサーバ連携アプリケーション５４０が認可コードを受信するＵＲＩを登録する事になる。本実施形態ではリダイレクトＵＲＩを指定しないものとして説明する。

次に、図１０のＳ１．４において、認可サーバモジュール２１０が、認証情報として通知されたアプリケーション用認可トークンを取得する。Ｓ１．５において、認可サーバモジュール２１０が、取得したアプリケーション用認可トークンに基づき、トークン管理テーブルとユーザ管理テーブル（表２）とを参照して、アプリケーション用認可トークンに紐づくユーザのテナントＩＤの情報を取得する。アプリケーション用認可トークンに紐づくユーザのテナントＩＤの情報がない場合、認可サーバモジュール２１０は、リソースサーバ連携アプリケーション５４０にエラーを応答する。

次に、Ｓ１．６において、認可サーバモジュール２１０が、クライアント管理テーブルにテナント専用クライアントを新規登録する。より具体的には、認可サーバモジュール２１０は、クライアントＩＤ、シークレットを発行し、それぞれクライアント管理テーブルに格納する。以後、ここで発行し登録したクライアントＩＤは、先述のベンダークライアントＩＤとは異なるＩＤである。そして、認可サーバモジュール２１０は、取得したテナントＩＤを、記憶手段が有するクライアント管理テーブルに格納する。その際、テナントＩＤは権限委譲したユーザが所属するテナントＩＤとなる。表１２は、テナント専用クライアントが新規登録されたクライアント管理テーブルの例を示す。

なお、登録されたテナント専用クライアントに対してデフォルトで設定すべき権限を、証明書管理テーブルに予め設定しておき、その設定に従って、Ｓ１．６で登録したテナント専用クライアントに対してデフォルトの権限を付与するよう構成する事もできる。また、デフォルトで設定すべき権限をスコープとして定義し、スコープも合わせて権限委譲することによって、テナント専用クライアントにスコープに対応する権限を付与するよう構成してもよい。

次に、Ｓ５．３において、認可サーバモジュール２１０が、クライアント登録応答として、発行したテナント専用クライアントＩＤとシークレットとを、リソースサーバ連携アプリケーション５４０に返す。以上がテナント専用クライアントの登録処理の説明である。

次に、テナント専用クライアントが発行された後の、デバイス５００からリソースサーバモジュール３１０へのＡＰＩ呼び出しについて説明する。まず、ＡＰＩ呼び出しは、デバイス５００が備えるセンサーや機器における変化を検知した事が契機となる。例えば、デバイス５００がプリンタである場合は、ＡＰＩ呼び出しの実施の契機は、リモートからの印刷要求を受けて印刷が行われたときや、プリンタが印字するためのインクやトナーといった材料の残量が低下したとき等である。例えば、デバイス５００がスマートフォンである場合は、ＡＰＩ呼び出しの実施の契機は、通話が行われたとき等である。また、例えば、デバイス５００がＧＰＳを備える機器の場合は、特定の場所へ移動したとき等が契機として考えられる。その他、デバイス５００の利用者の生体認証が実施されたとき、心拍の変化が生じたとき等が契機として考えられる。デバイス５００はこれらを検知し、以下のシーケンスを実施する。

デバイス５００での変化の検知を契機として、Ｓ５．４において、リソースサーバ連携アプリケーション５４０が、認可サーバモジュール２１０に対してテナント専用クライアントの認可トークンを要求する。その際、リソースサーバモジュール３１０の公開するＡＰＩに合わせたスコープを権限範囲として要求する。Ｓ２．３からＳ２．４までの処理は、スコープ以外については前述した処理と同様であるので、説明を省略する。

Ｓ５．５において、認可サーバモジュール２１０が、発行した認可トークンＩＤをリソースサーバ連携アプリケーション５４０に応答する。続いて、Ｓ５．６において、リソースサーバ連携アプリケーション５４０が、取得した認可トークンを用いて、リソースサーバモジュール３１０が公開するＡＰＩを呼び出す。ＡＰＩの呼び出しには、検知されたデバイス５００での変化の情報が含まれる。例えば、デバイス５００がプリンタであり、印刷を契機としてＡＰＩの呼び出しを行う場合は、ＡＰＩの呼び出しには、印刷された文書名や、印刷者、印刷した枚数、カラーかモノクロか、といった情報が含まれる。

Ｓ２．１３において、リソースサーバモジュール３１０が、認可サーバモジュール２１０に対して、認可トークンの検証を要求する。続いて、Ｓ２．１４において、認可サーバモジュール２１０は、認可トークンがトークン管理テーブルに登録されているかを検証する。認可トークンがトークン管理テーブルに登録されている場合は、認可サーバモジュール２１０は、以下の処理を行う。認可サーバモジュール２１０は、トークン管理テーブルとクライアント管理テーブルとを参照して、アプリケーション用認可トークンＩＤに紐づく情報として、テナント専用クライアントＩＤとテナントＩＤとを応答する。

Ｓ２．１５において、リソースサーバモジュール３１０が、ＡＰＩに応じた処理として、取得したテナント専用クライアントのテナントＩＤを確認する。リソースサーバモジュール３１０は、テナント専用クライアントのテナントＩＤを用いて、以下の処理を実施する。リソースサーバモジュール３１０は、ＡＰＩ呼び出し時に受信した、各種デバイス５００で検出された情報を、テナント専用クライアントのテナントＩＤの情報として取り扱う。より具体的には、リソースサーバモジュール３１０は、ＡＰＩ呼び出し時に受信した情報を、テナント専用クライアントのテナントＩＤに所属するユーザのみが参照可能な形式で不揮発メモリに記憶する。また、例えば、リソースサーバモジュール３１０は、テナント専用クライアントのテナントＩＤに所属するユーザに対して、電子メールを送信する。どのようなアクションを行うかは、公開するＡＰＩ毎に定義される。

次に、Ｓ２．１６において、リソースサーバモジュール３１０が、ＡＰＩの応答としてリソースサーバ連携アプリケーション５４０に応答し、処理を終了する。以上が、第三の方式の第二の方法による、リソースサーバモジュール３１０が提供するサービスの利用である。

第三の方式では、デバイス利用者のテナント専用のクライアントとしてデバイスを登録する事が可能となるため、デバイスから送信されるデータは、デバイスの利用者のテナントと紐づけられる。第三の方式では、デバイスとテナントの紐づけを、第一の方式のようにデバイスシリアルＩＤを使って実施しないので、リマニュファクチャリングやリファービッシュが発生しても、情報が漏洩するリスクが低減する。また、第三の方式では、第二の方式のようにユーザを仲介していないので、ユーザのログイン状況や、ユーザの登録状況に依存した制限は発生しない。したがって、マルチテナントの形態であるクラウドサービスを利用する場合においても、クライアントが特定のテナントに所属する事が可能となる。その結果、データに含まれる個人のプライバシーに関する情報や機密情報が、他のテナントやクラウドサービスを提供するベンダーに漏洩するリスクが低減される。

なお、第一、第二、第三の方式は、デバイスにおけるユースケースによって使い分けることができる。つまり、全ての方式を実現可能に構成する事が可能である。もちろん、排他的にいずれかの方式を実施するようにしてもよい。

図１１および図１２は、リソースサーバ連携アプリケーションとリソースサーバモジュールにおいて第一、第二、第三の方式を使い分ける判断処理を説明する図である。
図１１は、リソースサーバ連携アプリケーション５４０によるデータ送信処理を説明するフローチャートである。送信されるデータは、ＡＰＩ呼び出しの際つまりサービスの利用時にリソースサーバモジュール３１０に送信されるデータ（例えばアップロード対象となるデータ）である。

Ｓ１１．１において、リソースサーバ連携アプリケーション５４０が、データを検出する。続いて、Ｓ１１．２において、リソースサーバ連携アプリケーション５４０は、データに個人情報を含むか否かを判断する。データに個人情報を含まない場合は、処理がＳ１１．３に進む。そして、リソースサーバ連携アプリケーション５４０が、第一の方式を用いて、リソースサーバモジュール３１０のＡＰＩを呼び出す。なお、データに個人情報を含まない場合に、処理がＳ１１．４に進むようにしてもよい。また、Ｓ１１．４乃至Ｓ１１．７の処理を省略し、データに個人情報を含む場合に、Ｓ１１．８に進んで、第三の方式でＡＰＩ呼び出しを行うようにしてもよい。

Ｓ１１．４において、リソースサーバ連携アプリケーション５４０が、送信するデータが認可サーバモジュール２１０のユーザに関連するデータであるか否かを判断する。ユーザに関連するデータは、例えば、ユーザの操作ログである。送信するデータが認可サーバモジュール２１０のユーザに関連するデータである場合は、処理がＳ１１．５に進む。Ｓ１１．５において、リソースサーバ連携アプリケーション５４０が、ユーザがデバイス５００にログイン状態であるか否かを判断する。ユーザがデバイス５００にログイン状態である場合は、処理がＳ１１．６に進む。そして、Ｓ１１．６において、リソースサーバ連携アプリケーション５４０が、第二の方式の第二の方法のうち、ログインコンテキストに紐づけてリフレッシュトークンを保存している構成を用いて、リソースサーバモジュール３１０のＡＰＩを呼び出す。

ユーザがデバイス５００にログインしていない状態である場合は、処理がＳ１１．７に進む。そして、Ｓ１１．７において、リソースサーバ連携アプリケーション５４０が、第二の方式の第二の方法のうち、アプリケーションＩＤに紐づけてリフレッシュトークンを保存している構成を用いて、リソースサーバモジュール３１０のＡＰＩを呼び出す。なお、Ｓ１１．４において、送信するデータが認可サーバモジュール２１０のユーザに関連するデータであると判断された場合に、Ｓ１１．５の判断処理を省略してもよい。この場合には、リソースサーバ連携アプリケーション５４０は、第二の方式、つまりリソースサーバ３００のサービスにおける権限をデバイス５００に委譲したユーザが所属するテナントを利用する方式でＡＰＩを呼び出す。

Ｓ１１．４において、送信するデータが認可サーバモジュール２１０のユーザに関連するデータでない場合は、処理がＳ１１．８に進む。そして、Ｓ１１．８において、リソースサーバ連携アプリケーション５４０が、第三の方式を用いて、リソースサーバモジュール３１０のＡＰＩを呼び出す。以上の処理により、リソースサーバ連携アプリケーション５４０は、データの特性によって複数の方式を使い分けて、リソースサーバモジュール３１０のサービスを利用することが可能となる。

図１２は、リソースサーバモジュール３１０によるデータの受信処理を説明するフローチャートである。
Ｓ１２．１において、リソースサーバモジュール３１０が、データを受信する。その際、リソースサーバモジュール３１０は、ＡＰＩとして認可トークンまたはアプリケーション用認可トークンを合わせて受信する。続いて、Ｓ１２．２において、認可トークンに紐づく情報を取得する。具体的には、リソースサーバモジュール３１０は、認可サーバモジュール２１０に対して認可トークンの検証を依頼し、その応答として認可トークンに紐づく情報を取得する。認可トークンに紐づく情報として、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを用いる方式の場合は、ユーザのＵＵＩＤ、ユーザのテナントＩＤ、クライアントＩＤ、クライアントのテナントＩＤが取得される。認可トークンに紐づく情報として、デバイスシリアルＩＤ、アプリケーションＩＤが取得される場合もある。

Ｓ１２．３において、リソースサーバモジュール３１０が、認可トークンに紐づく情報に、ユーザのＵＵＩＤが含まれているか否かを判断する。認可トークンに紐づく情報に、ユーザのＵＵＩＤが含まれている場合は、処理がＳ１２．４に進む。そして、Ｓ１２．４において、リソースサーバモジュール３１０が、ユーザのＵＵＩＤとユーザのテナントＩＤとに紐づけてデータを保存し、処理を終了する。

認可トークンに紐づく情報にユーザのＵＵＩＤが含まれていない場合は、処理がＳ１２．５に進む。そして、Ｓ１２．５において、リソースサーバモジュール３１０が、認可トークンに紐づく情報のクライアントのテナントＩＤを確認することで、クライアントのテナントがベンダーであるか否かを判断する。クライアントのテナントがベンダーである場合は、処理がＳ１２．６に進む。そして、Ｓ１２．６において、リソースサーバモジュール３１０が、データをベンダーに紐づけて保存し、処理を終了する。

クライアントのテナントがベンダーでない場合は、処理がＳ１２．７に進む。そして、Ｓ１２．７において、リソースサーバモジュール３１０が、クライアントのテナントＩＤに紐づけてデータを保存し、処理を終了する。以上の処理により、デバイス５００が送信したデータは、データの特性に従ってリソースサーバモジュール３１０で保存されるようになる。その結果、リソースサーバ連携アプリケーション５４０は、個人のプライバシーに関する情報や機密情報が含まれるような詳細なデータを送信できるようになる。その結果、リソースサーバモジュール３１０もセキュリティが確保された状態でデータを取り扱う事が可能となる。また、例えばビッグデータとして蓄積される情報に関して、テナント内では、より有用な解析結果を得る事が可能となる。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

２００ 認可サーバ
３００ リソースサーバ
４００ 端末
５００ デバイス

Claims (18)

1. 情報処理装置と、ネットワークを介してサービスを提供するサービス提供装置と、認可サーバとを含み、前記情報処理装置をクライアントとして前記認可サーバに登録する権限委譲システムであって、
   前記情報処理装置は、
   前記認可サーバへの第１のクライアントの登録に応じて前記認可サーバから提供された第１の認証情報を基に、第２のクライアントを作成するユーザの権限が前記第１のクライアントへ委譲されたことを示す第１の認可情報の取得要求をする第１の取得要求手段と、
   前記第１の取得要求手段による前記取得要求によって前記第１の認可情報が取得されたことに応じて、前記認可サーバへの前記第２のクライアントの登録要求をする登録要求手段と、を有し、
   前記認可サーバは、
   前記登録要求とともに送信された前記第１の認可情報を基に前記ユーザのテナントを特定し、特定された前記テナントと新たに登録する前記第２のクライアントとを紐付けて管理する管理手段と、
   前記テナントと紐付けて管理される前記第２のクライアントに対応する第２の認証情報を発行する発行手段と、を有し、
   さらに、前記情報処理装置は、
   前記登録要求による前記第２のクライアントの登録に応じて前記認可サーバから提供された前記第２の認証情報を基に、特定の権限が前記第２のクライアントに委譲されたことを示す第２の認可情報の取得要求をする第２の取得要求手段と、
   前記第２の取得要求手段による前記取得要求によって取得された前記第２の認可情報を基に、前記サービス提供装置のサービスを利用する利用手段とを有し、
   前記サービス提供装置は、前記第２の認可情報を基に特定された前記テナントを確認し、サービスの提供に関するデータを確認された前記テナントに紐付けて保存する保存手段を有する
   ことを特徴とする権限委譲システム。
2. 前記認可サーバは、
   前記第１の認可情報の取得要求に応じて、前記ユーザが操作する端末に対して認可確認画面データを送信する画面送信手段と、
   前記端末にて表示される認可確認画面を介し、前記ユーザが前記第２のクライアントを作成する権限を前記第１のクライアントに委譲することを許可する指示をした場合、前記第１の認可情報を提供する第１の提供手段と、
   前記第２の取得要求手段からの前記取得要求に応じて、前記第２の認可情報を提供する第２の提供手段と、
   前記利用手段による前記サービス提供装置のサービスの利用の際に送信される前記第２の認可情報を基に、前記利用手段が前記特定の権限で前記サービス提供装置のサービスを利用することを認可するか否かを検証する認可手段と、を有する
   ことを特徴とする請求項１に記載の権限委譲システム。
3. 前記認可サーバへの第１のクライアントの登録は、前記ユーザのテナントの情報を含んでいない登録要求によってなされる
   ことを特徴とする請求項１または請求項２に記載の権限委譲システム。
4. 前記認可サーバは、少なくとも前記第２のクライアントと前記テナントとに紐付けられる前記第２の認可情報を記憶する記憶手段を有する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の権限委譲システム。
5. 前記利用手段は、前記サービスの利用時に前記サービス提供装置に送信するデータに個人情報を含むかを判断し、前記データに個人情報を含む場合に、前記第２の認可情報を基に、前記サービス提供装置のサービスを利用する
   ことを特徴とする請求項１乃至４のいずれか１項に記載の権限委譲システム。
6. 前記利用手段は、前記データに個人情報を含む場合に、前記データが前記認可サーバのユーザに関連するデータであるかを判断し、前記データが前記認可サーバのユーザに関連するデータでない場合に、前記第２の認可情報を基に、前記サービス提供装置のサービスを利用する
   ことを特徴とする請求項５に記載の権限委譲システム。
7. 前記利用手段は、前記データに個人情報を含まない場合に、前記認可サーバに登録される前記情報処理装置とテナントとに紐付く認可情報と、前記サービス提供サーバに登録される前記情報処理装置に紐付くテナントとを利用する第一の方式で、前記サービス提供装置のサービスを利用する
   ことを特徴とする請求項５または請求項６に記載の権限委譲システム。
8. 前記情報処理装置が、前記情報処理装置を示すデバイスシリアルＩＤとともに、前記テナントを示すテナントＩＤに紐付くキーを前記サービス提供サーバに送信することで、前記テナントが前記情報処理装置と紐付けられて前記サービス提供サーバに登録される
   ことを特徴とする請求項７に記載の権限委譲システム。
9. 前記利用手段は、
   前記データが前記認可サーバのユーザに関連するデータである場合に、前記サービス提供装置のサービスに関する権限を前記情報処理装置に委譲したユーザに紐付く認可情報を利用する第二の方式で、前記サービス提供装置のサービスを利用する
   ことを特徴とする請求項６に記載の権限委譲システム。
10. 前記利用手段は、
    前記データが前記認可サーバのユーザに関連するデータである場合に、前記ユーザが前記情報処理装置にログインしているかを判断し、
    前記ユーザが前記情報処理装置にログインしていない場合に、前記第二の方式のうち、前記権限の委譲によって前記情報処理装置にアプリケーションＩＤに紐付けて保存されるリフレッシュトークンのリフレッシュ要求に起因して発行される認可情報を用いる方式で、前記サービス提供装置のサービスを利用する
    ことを特徴とする請求項９に記載の権限委譲システム。
11. 前記利用手段は、
    前記データが前記認可サーバのユーザに関連するデータである場合に、前記ユーザが前記情報処理装置にログインしているかを判断し、
    前記ユーザが前記情報処理装置にログインしている場合に、前記第二の方式のうち、前記権限の委譲によって前記情報処理装置にログインコンテキストに紐付けて保存されるリフレッシュトークンのリフレッシュ要求に起因して発行される認可情報を用いる方式で、前記サービス提供装置のサービスを利用する
    ことを特徴とする請求項９に記載の権限委譲システム。
12. 前記第１の認可情報の取得要求は、前記第１のクライアントを示すクライアントＩＤとシークレットとを有する前記第１の認証情報を含み、
    前記第２の認可情報の取得要求は、前記第２のクライアントを示すクライアントＩＤとシークレットとを有する前記第２の認証情報を含む
    ことを特徴とする請求項１乃至１１のいずれか１項に記載の権限委譲システム。
13. ネットワークを介して認可サーバにクライアントとして登録され、サービス提供装置が提供するサービスを利用する情報処理装置であって、
    前記認可サーバへの第１のクライアントの登録に応じて前記認可サーバから提供された第１の認証情報を基に、第２のクライアントを作成するユーザの権限が前記第１のクライアントへ委譲されたことを示す第１の認可情報の取得要求をする第１の取得要求手段と、
    前記第１の取得要求手段による前記取得要求によって前記第１の認可情報が取得されたことに応じて、前記認可サーバへの前記第２のクライアントの登録要求をする登録要求手段と、を有し、
    前記認可サーバによって、前記登録要求とともに送信された前記第１の認可情報を基に特定される前記ユーザのテナントと新たに登録する前記第２のクライアントとが紐付けて管理され、前記テナントと紐付けて管理される前記第２のクライアントに対応する第２の認証情報が発行され、
    さらに、前記情報処理装置は、前記登録要求による前記第２のクライアントの登録に応じて前記認可サーバから提供された前記第２の認証情報を基に、特定の権限が前記第２のクライアントに委譲されたことを示す第２の認可情報の取得要求をする第２の取得要求手段と、
    前記第２の取得要求手段による前記取得要求によって取得された前記第２の認可情報を基に、前記サービス提供装置のサービスを利用する利用手段と、を有する
    ことを特徴とする情報処理装置。
14. 前記認可サーバへの前記第１のクライアントの登録は、前記ユーザのテナントの情報を含んでいない登録要求によってなされる
    ことを特徴とする請求項１３に記載の情報処理装置。
15. 情報処理装置をクライアントとして登録し、前記情報処理装置がネットワークを介してサービス提供装置が提供するサービスを利用するための認可処理を行う認可サーバであって、
    前記情報処理装置からの第１のクライアントの登録要求に応じて前記第１のクライアントを登録するとともに、第１の認証情報を発行する第１の発行手段と、
    前記第１の認証情報を提供された前記情報処理装置が実行する、第２のクライアントを作成するユーザの権限が前記情報処理装置へ委譲されたことを示す第１の認可情報の取得要求に応じて、前記第１の認可情報を前記情報処理装置に提供する第１の提供手段と、
    前記第１の認可情報を提供された前記情報処理装置が実行する、前記第２のクライアントの登録要求に応じて、前記登録要求とともに送信された前記第１の認可情報を基に前記ユーザのテナントを特定し、特定された前記テナントと新たに登録する前記第２のクライアントとを紐付けて管理する管理手段と、
    前記テナントと紐付けて管理される前記第２のクライアントに対応する第２の認証情報を発行する第２の発行手段と、
    前記情報処理装置からの、前記第２のクライアントの登録に応じて提供される前記第２の認証情報を基にした、特定の権限が前記情報処理装置に委譲されたことを示す第２の認可情報の取得要求に応じて、前記第２の認可情報を前記情報処理装置に提供する第２の提供手段と、を有し、
    前記情報処理装置によって、前記第２の認可情報を基に、前記サービス提供装置のサービスが利用される
    ことを特徴とする認可サーバ。
16. 前記認可サーバへの前記第１のクライアントの登録は、前記ユーザのテナントの情報を含んでいない登録要求によってなされる
    ことを特徴とする請求項１５に記載の認可サーバ。
17. 情報処理装置をクライアントとして登録し、前記情報処理装置がネットワークを介してサービス提供装置が提供するサービスを利用するための認可処理を行う認可サーバの制御方法であって、
    前記情報処理装置からの第１のクライアントの登録要求に応じて前記第１のクライアントを登録するとともに、第１の認証情報を発行する第１の発行工程と、
    前記第１の認証情報を提供された前記情報処理装置が実行する、第２のクライアントを作成するユーザの権限が前記情報処理装置へ委譲されたことを示す第１の認可情報の取得要求に応じて、前記第１の認可情報を前記情報処理装置に提供する第１の提供工程と、
    前記第１の認可情報を提供された前記情報処理装置が実行する、前記第２のクライアントの登録要求に応じて、前記登録要求とともに送信された前記第１の認可情報を基に前記ユーザのテナントを特定し、特定された前記テナントと新たに登録する前記第２のクライアントとを紐付けて管理する管理工程と、
    前記テナントと紐付けて管理される前記第２のクライアントに対応する第２の認証情報を発行する第２の発行工程と、
    前記情報処理装置からの、前記第２のクライアントの登録に応じて提供される前記第２の認証情報を基にした、特定の権限が前記情報処理装置に委譲されたことを示す第２の認可情報の取得要求に応じて、前記第２の認可情報を前記情報処理装置に提供する第２の提供工程と、を有し、
    前記情報処理装置によって、前記第２の認可情報を基に、前記サービス提供装置のサービスが利用される
    ことを特徴とする制御方法。
18. コンピュータに請求項１７に記載の制御方法を実行させることを特徴とするプログラム。

Images