JP6198477B2 - 権限移譲システム、認可サーバーシステム、制御方法、およびプログラム - Google Patents

Description

権限移譲システムにおけるクライアント登録を行う権限移譲システム、認可サーバーシステム、制御方法、およびプログラム

ＯＡｕｔｈ２．０と呼ばれる認可の連携を実現させるための標準プロトコルが策定されている（非特許文献１を参照）。ＯＡｕｔｈ２．０によれば、例えばインターネット上に備えられたサービスＡが管理するユーザーのデータに対し、ユーザーにより認可されたアプリケーションであって、そのユーザーが操作する端末に備えられたアプリケーションＢがアクセスすることができる。ＯＡｕｔｈ２．０においては、アプリケーションＢのように権限の移譲を受ける主体をＯＡｕｔｈクライアント、または単にクライアントと呼ぶ。このときサービスＡは、アプリケーションＢからアクセスされる範囲を明らかにした上で、アプリケーションＢによるアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。

ユーザーが認可操作を行うと、アプリケーションＢはサービスＡからアクセスを認められたことを証明するトークン（以下、認可トークンと称する）を受け取り、以降のアクセスはその認可トークンを用いて実現できる。認可トークンを用いるアプリケーションＢは、ユーザーの認証情報の入力を求めずに、認可操作を行ったユーザーの権限でサービスＡにアクセスできる。そのため、ユーザーから認可を受け認可トークンを取得したアプリケーションＢは、その認可トークンを厳重かつ適正に管理する責務を負う。

また、ＯＡｕｔｈ２．０では、アプリケーションＢの成り済ましを防ぐため、認可操作が行われる前にアプリケーションＢを事前に認証し規定された権限を与えておく必要がある。このアプリケーションＢを認証するために、サービスＡは予めアプリケーションＢの認証情報、より具体的にはクライアントＩＤおよびシークレットを発行、管理し、さらにはアプリケーションＢにそれら認証情報を設定しておく必要がある。ＯＡｕｔｈ２．０に付随する仕様として、オンラインによるアプリケーションの登録プロトコルが検討されている（非特許文献２を参照）。このオンライン登録の仕様はＤｙｎａｍｉｃ Ｃｌｉｅｎｔ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌとして定義されている。このＤｙｎａｍｉｃ Ｃｌｉｅｎｔ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌによれば、各クライアント登録の要求元は、クライアント登録用のエンドポイントに対してメタデータを送信する事で動的にクライアント登録され、認証情報を取得する事ができる。エンドポイントはＯＡｕｔｈ２．０を実装したサーバーサイドに備えられた認可サービスとなる。この仕組みにより、大量に配布されるアプリケーションに対して個々に認証情報を設定するのではなく、各アプリケーションが主体的に認証情報を取得する事で個々の設定による煩雑さを回避する事ができる。認可トークンの確認時には、ユーザーから移譲された権限の確認のみならず、アプリケーションＢ自身の権限も確認され、サービスの利用可否が決定される。

"Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ"、［ｏｎｌｉｎｅ］Ｄ．Ｈａｒｄｔ、２０１３年５月 ＜ＵＲＬ ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＞ "ＯＡｕｔｈ ２．０ Ｄｙｎａｍｉｃ Ｃｌｉｅｎｔ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｄｒａｆｔ−ｉｅｔｆ−ｏａｕｔｈ−ｄｙｎ−ｒｅｇ−１１"、［ｏｎｌｉｎｅ］Ｊ．Ｒｉｃｈｅｒ、２０１３年５月 ＜ＵＲＬ ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｏａｕｔｈ−ｄｙｎ−ｒｅｇ−１１＞

ＯＡｕｔｈ２．０を始めとする権限移譲処理におけるアプリケーションの登録プロトコルは、登録を行うアプリケーション全てに対して一律同じ権限を与えている。例えば、特定のアプリケーションに対して不必要な権限を与えてしまった場合、ユーザーの権限がその特定のアプリケーションに与えられてしまえば、利用が想定されていないサービスをその特定のアプリケーションが利用されてしまう可能性がある。

本発明はこれら前述の課題を鑑みてなされたものであり、権限移譲処理におけるアプリケーションの登録プロトコルにおいて、アプリケーションに応じて適切な権限を与えて登録を行う認可サーバーを提供することを目的とする。

本願発明の一実施形に係る権限移譲システムは、アプリケーションを備えたデバイスへサービスを提供するサーバーシステムと、前記サービスにおけるユーザーの権限を前記サービスの利用元へ移譲するための認可処理を行う認可サーバーシステムとを含む権限移譲システムであって、前記アプリケーションを前記利用元として登録する要求を受信したことに応じて前記アプリケーションの権限を特定し、特定された前記権限と前記アプリケーションの識別子とを紐付けて管理する管理手段と、前記サービスを利用するための要求を送信するアプリケーションに前記ユーザーの権限を移譲することを許可する認可操作が行われ、かつ前記アプリケーションが利用する権限が、前記アプリケーションの識別子に紐付く権限内に含まれる場合に前記サービスを提供することを特徴とする。

本発明によれば、権限移譲処理におけるアプリケーションの登録プロトコルにおいて、アプリケーションに応じて適切な権限を与えて登録を行うことが可能となる。

システム構成図 各装置のハードウェア構成図 各装置のソフトウェアモジュール構成図 認可サーバーで管理するクライアント関連テーブル構造 認可サーバーで管理する認可トークン関連テーブル構造 クライアント登録からリソースアクセスまでのシーケンス Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔの場合の認可トークン発行シーケンス 画面例 Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔの場合の認可トークン発行シーケンス 認可トークン検証処理フロー 第２の実施形態における登録シーケンス 登録権限検証処理フロー

本願発明で用いられる用語、および本願発明の各実施例におけるシステムが備えたサービスの概要、およびそのサービスと連携するアプリケーションについて説明する。サービスとはネットワークを介して接続されたサーバーに備えられた機能であり、アクセス元の端末に備えられていない機能を補填することが可能である。サービスを提供すると称した場合、サーバーに備えられた機能をアクセス元、および／またはユーザーに利用させることを意味する。

サービスには、利用量が課金される有償サービスと、課金されない無償サービスとか存在する。有償サービスは基本的に利用者との契約が行われる事で利用可能となり、契約した内容に従ったサービスを安定的に提供する責務を負う。例えば、ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）と呼ばれるサービスの品質を保証する制度がよく知られている。このＳＬＡには、提供するサービスの最低速度や、利用不可能な時間の上限などが定義されている。ユーザーは、このＳＬＡに定義されているサービスの品質の対価として利用料金を支払う。また、ＳＬＡには、定義されている品質が守れなかった場合の処置としてサービス提供者側の罰則や、ユーザーへの保証、例えば利用料金の減額、が定義されている。よって、有償サービスでは、ＳＬＡに定義された品質を守る事が非常に重要となっている。無償サービスは、サービスを受けるためのインターフェース仕様が公開されており、第三者にアプリケーション作成の機会が与えられている。無償サービスにはＳＬＡのような規約は存在しない。

そして、本願発明の各実施例におけるシステムが少なくとも備える３つのサービスは次の通りである。１つ目は、有償サービスであり、インターネット上に登録されたユーザーデータをプロビジョニングするためのユーザープロビジョニングサービスが、インターネット上のサーバーに設置されている。２つ目は、有償サービスであり、端末が保持する文書データを印刷可能なデータに変換する有償データ変換サービスが、インターネット上のサーバーに設置されている。３つ目は、無償サービスであり、２つ目のサービス同様、端末が保持する文書データを印刷可能なデータに変換する無償データ変換サービスが、インターネット上のサーバーに設置されている。夫々のサーバーはリソースサーバーと称することとし、本願発明が想定するシステムを構成するサーバーとする。なお、リソースサーバーには１つのサービスが備えられていることとするが、１台のリソースサーバーに異なる２つ以上のサービスが備えられていても良い。

さらに、スマートフォンやタブレットと言った端末に提供されるアプリケーションであって、サービスと連携するアプリケーションにも、有償アプリケーションと無償アプリケーションとが存在する。有償アプリケーションは、有償サービスと同様にユーザーに対して品質を保証する必要がある。さらには、有償サービスのＳＬＡを守るために、有償サービスと連携するアプリケーションの品質を高いコストをかけて作り込む事があり得る。つまりは、有償サービスのＳＬＡを達成するために、サービス提供者は高いコストをかけてアプリケーションを作成する。そして、有償アプリケーションはお金を払ったユーザーに提供され、無償アプリケーションは一律無料で配布される。

このようなシステムの場合、次の様なより具体的な課題が存在する。アプリケーションの配布の煩雑さを回避するために権限移譲処理における従来のアプリケーション登録プロトコルを提供した場合、第三者が作成した無償アプリケーションが有償サービスを利用してしまう事を防ぐことが困難となる。有償サービスにおけるユーザーの権限が無償アプリケーションに移譲されてしまえば、無償アプリケーションは有償アプリケーションと変わらずサービスを利用する権限を有しているため、防げないのである。結果、有償サービス提供者としてはＳＬＡの達成が困難となり有償サービスとしてのビジネスが崩れかねない。さらには、ＳＬＡ達成のために高いコストをかけて作成したアプリケーションが利用されず費用回収が困難となる。

実施例１では、上述した課題を解決するためのシステムの詳細な説明を行う。本実施の形態に係るシステムである権限移譲システムは、図１に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。１０２は各構成要素を接続する公衆回線である。

２００はＯＡｕｔｈ２．０を実現するための認可サーバーであり、トークンを発行するための認可処理を行う認可サーバーモジュールが設置されている。３００はリソースサーバーであり、ユーザープロビジョニングサービスや、有償データ変換サービス、無償データ変換サービスといったリソースサーバーモジュールが設置されている。なお１台のリソースサーバーに設置されるリソースサーバーモジュールは１つでもよく、複数でもよい。４００はスマートフォンと呼ばれる携帯端末や、画像形成装置と言ったデバイス機器であり、１つまたは複数のアプリケーションモジュールがインストールされている。ユーザーはそれらのアプリケーションモジュールを用いてリソースサーバーと通信する。５００はデータベースサーバーであり、認可サーバー２００とＬＡＮ１０１を介して接続しており、認可サーバーモジュールが利用するデータが格納されている。

また認可サーバー２００、リソースサーバー３００、端末４００はそれぞれＷＡＮ１００およびＬＡＮ１０１を介して接続されている。なお認可サーバー２００、リソースサーバー３００、端末４００はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また認可サーバー２００、リソースサーバー３００、ないしはデータベースサーバー５００は同一のサーバー上に構成されていてもよい。なお、夫々のサーバーは複数のサーバーで構成されていても良くサーバーの数に制限はない。そこで、１台または複数のサーバーから構成されるサーバーをサーバーシステムと称し、認可サーバーシステムと記載した場合は、１台または複数の認可サーバーを意味するものとする。

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

図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行しシステムバス２０４に接続される各ブロックを制御する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード２０９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２０６は、ＣＲＴディスプレイ２１０の表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２１１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２０８はＷＡＮ１００、ＬＡＮ１０１、もしくは公衆回線１０２を介して接続された他の機器との通信制御処理を実行する。尚、後述の全ての説明においては、特に断りのない限りサーバーにおける実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は外部メモリ２１１にインストールされたアプリケーションプログラムである。

図３は本実施の形態に係る、認可サーバー２００、リソースサーバー３００、端末４００それぞれのモジュール構成を示す図である。なお認可サーバー２００、リソースサーバー３００、端末４００は図２のものと同一である。図中２００は認可サーバー２００である。認可サーバー２００は認可サーバーモジュール６００、ＨＴＴＰサーバーモジュール６１０を持つ。ＨＴＴＰサーバーモジュール６１０はＷＡＮ１００を介して接続する端末４００とのＨＴＴＰ通信を行うためのモジュールである。また、ＨＴＴＰサーバーモジュール６１０は、ＳＳＬ／ＴＬＳによる通信が可能に構成されており、証明書を保存する機能（不図示）を持つ。また、本実施例では、後述するクライアント登録要求を受け付けるエンドポイントにて、要求元に対してＸ．５０９形式の証明書による認証を要求するよう構成している。次に、認可サーバーモジュール６００は、ＨＴＴＰサーバーモジュール６１０を介して端末４００からの要求を受け付け、処理し、応答する。その際、本実施例では、ＨＴＴＰサーバーモジュール６１０にて、クライアント登録要求を受け付け、要求元の認証に成功した場合、クライアントから受信した証明書を認可サーバーモジュール６００に通知するよう構成されている。

図中３００はリソースサーバー３００である。リソースサーバー３００はリソースサーバーモジュール７００、ＨＴＴＰサーバーモジュール７１０を持つ。ＨＴＴＰサーバーモジュール７１０はＨＴＴＰサーバーモジュール６１０と同様の機能を持つ。リソースサーバーモジュール７００はＨＴＴＰサーバーモジュール７１０を介して端末４００からの要求を受け付け、処理し、応答する。

図中４００は端末４００である。端末４００はアプリ−ション管理モジュール８１０、Ｗｅｂブラウザー８２０を備え、一つないしは複数のアプリケーションモジュール８００を持つ。８１０はアプリケーション管理モジュールであり、端末４００上で動作する管理対象のアプリケーションモジュール８１０のライフサイクルを管理する機能を備えている。ライフサイクルとはアプリケーションのインストール、起動、停止、アンインストールを含むアプリケーションの状態を示すものとする。例えば、アプリケーション管理モジュール８１０はＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）アライアンスで規定されたＯＳＧｉ（登録商標）が考えられる。

アプリケーションモジュール８１０は端末４００が提供するアプリケーション実行環境にて動作するアプリケーションである。このアプリケーションはアプリケーション管理モジュール８１０にてライフサイクル管理されている。ここでアプリケーションモジュール８００は、端末４００が既定で持っていてもよく、またアプリケーション管理モジュール８１０を介して後からインストールされてもよい。さらに、端末４００はＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザー８２０を備える。また、アプリケーションモジュール８００は、自身を証明するためのＸ．５０９形式の証明書および、その秘密鍵を保持している。そして、後述のＨＴＴＰサーバーモジュール６１０との通信確立時に利用する事で、ＨＴＴＰサーバーモジュール６１０によってアプリケーションモジュールからの要求である事を認証する事ができる。

図４ａ、図４ｂ、図４ｃ、図４ｄは認可サーバー２００がＬＡＮ１０１を介して通信可能に構成されたデータベースサーバー５００の外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー２００の外部メモリに構成する事もできる。

図４ａは証明書管理テーブルである。なお、本実施例では、証明書としてＸ．５０９形式の証明書を利用する。証明書管理テーブル１２００は、証明書のシリアル番号１２０１、証明書の発行者１２０２、主体者１２０３、開始日時１２０４、終了日時１２０５、および、後述する関連付けられるテナントのマスターユーザーのＤＮ（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ）１２０６からなる。図４ｂはクライアント管理テーブル１３００である。クライアント管理テーブル１３００はクライアントＩＤ１３０１、クライアントシークレット１３０２、テナントＩＤ１３０３、種別１３０４、ＤＮ１３０５、クライアント名１３０６、リダイレクトＵＲＬ１３０７から成る。認可サーバー２００は、クライアントＩＤ１３０１、シークレット１３０２の情報の組を検証し、正しければ認証情報を生成することで、各クライアントを認証する機能を備える。クライアント名１３０６、リダイレクトＵＲＬ１３０７は後述のシーケンスで利用される値である。また、種別１３０４は、当該レコードのクライアントがテナントのマスターユーザーであるかどうか、を識別するためのデータが格納される。

図４ｃはデフォルト権限管理テーブル１４００である。デフォルト権限管理テーブル１４００はテナントＩＤ１４０１、デフォルト権限ＩＤ１４０２からなる。テナントＩＤ１４０１はクライアント管理テーブル１３００のテナントＩＤ１３０３と互いに参照可能に構成されている。図４ｄはクライアント権限テーブル１５００である。クライアント権限テーブル１５００はクライアントＩＤ１５０１、権限ＩＤ１５０２からなる。クライアントＩＤ１５０１はクライアント管理テーブル１３００のクライアントＩＤ１３０１と互いに参照可能に構成されている。また、権限ＩＤ１５０２はデフォルト権限管理テーブル１４００のデフォルト権限ＩＤ１４０２に設定されている権限ＩＤが格納される。この権限ＩＤ１５０２への権限ＩＤの登録については後述する。なお、図４ｄの情報は、クライアントから受信した証明書を基に、図４ａから図４ｃを用いて証明書に紐付く権限が特定されることで設定される。即ち、クライアントが送信する証明書に応じて与えられる権限が変わることになる。なお、本実施例におけるＩＤは識別子の１つの形態でありそれ以外であっても良く、また、例えばクライアントＩＤと称した場合はクライアントを一意に特定できる情報となる。

図５ａ、図５ｂ、図５ｃ、図５ｄは認可サーバー２００がＬＡＮ１０１を介して通信可能に構成されたデータベースサーバー５００の外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー２００の外部メモリに構成する事もできる。図５ａはスコープテーブル１６００である。ここでスコープとは、ＯＡｕｔｈ２．０による権限移譲プロトコル上にて認可情報である認可トークンを発行する際に、その認可トークンによって参照可能なリソースのアクセス範囲のことである。なお、認可情報の表現形式は認可トークン（数字と文字から構成される列）である必要はない。スコープテーブル１６００はスコープＩＤ１６０１、スコープの種別１６０２、後述する画面例で利用するスコープの説明１６０３、権限ＩＤ１６０４からなる。スコープの種別１６０２はオーナースコープとクライアントスコープの２種が定義される。ここで、オーナースコープとは、後述するＯＡｕｔｈ２．０による権限移譲のフローにおいて、権限移譲元（リソースオーナー）のリソースのアクセス範囲を示す。また、クライアントスコープとは、後述するＯＡｕｔｈによる権限移譲フローにおいて、権限移譲先（クライアント）のリソースのアクセス範囲を示す。また、実施例１におけるリソースのアクセス範囲はサービス単位としたが、サービス内の機能を更に細分化しても良いし、複数のサービスをまとめたサービス群としても良い。そこで、認可トークンによって参照可能なリソースのアクセス範囲を権限と称し、アプリケーション、またはサービスが特定の権限を有することで権限移譲元のサービス、またはサービス群と言った機能を利用することができる。

なお、ここで言うリソースオーナーはＯＡｕｔｈ２．０のフローにより対象が変わる。より具体的には、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔによる認可トークン取得フローの場合は、リソースオーナーはユーザーとなる。またＣｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔによる認可トークン取得フローの場合は、リソースオーナーはクライアント自身となる。スコープテーブル１６００における権限ＩＤ１６０４は、当該スコープＩＤが示すスコープに対してアクセスするために必要な権限を示し、０個以上の権限ＩＤを紐づける事ができる。ここで、複数の権限ＩＤが紐づいている場合は、その複数の権限ＩＤのうちの少なくとも１個の権限を有していれば、スコープが示すリソースへアクセスできる。また０個の権限ＩＤが紐づいている場合、つまり、一つも権限ＩＤと紐づいていない場合は、当該スコープに対して認証された主体であれば、だれでもアクセス可能であることを示す。

図５ｂはユーザー管理テーブル１７００である。ユーザー管理テーブル１７００は、ユーザーＩＤ１７０１、パスワード１７０２、テナントＩＤ１７０３から成る。認可サーバー２００は、ユーザーＩＤ１７０１、パスワード１７０２の情報の組を検証し、正しければ認証情報を生成することで、各ユーザーを認証する機能を備える。図５ｃはユーザー権限テーブル１８００である。ユーザー権限テーブル１８００はユーザーＩＤ１８０１、権限ＩＤ１８０２からなる。ユーザーＩＤ１８０１はユーザー管理テーブル１７００のユーザーＩＤ１７０１と互いに参照可能に構成されている。なお、本実施例では、ユーザー権限テーブル１８００とクライアント権限テーブル１５００とは違うテーブルとして記載しているが、テーブルのカラムの構成上一つのテーブルとして管理する事も可能である。図５ｄは認可トークン管理テーブル１９００である。認可トークン管理テーブル１９００は、認可トークンＩＤ１９０１、トークン種別１９０２、有効期限１９０３、スコープＩＤ１９０４、クライアントＩＤ１９０５、オーナーＩＤ１９０６から成る。これら認可トークン管理テーブル１９００の処理詳細については後述する。

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

まず、図６を用いてアプリケーションモジュール８００におけるクライアント登録のシーケンスを説明する。Ｓ１．１にて、端末４００のアプリケーションモジュール８００は、認可サーバー２００のＨＴＴＰサーバーモジュール６１０に対し、アプリケーションモジュール８００をリソースサーバーモジュール３３０の利用元として登録するためのクライアント登録要求を行う。なお、リソースサーバーモジュール３３０は１つとは限らず複数でも良いことは上述した通りである。なお、アプリケーションモジュール８００がクライアント登録要求を行うきっかけとして、本実施例では、端末４００にてユーザーが当該アプリケーションモジュール８００をインストールし、初めて起動したタイミングとして説明する。なお、他のきっかけとして、ユーザーがアプリケーションモジュール８００の機能を選択し、リソースサーバー３００へのリソース要求が発生するタイミングが考えられる。また、アプリケーションモジュール８００が明示的に開始する操作を備え、ユーザーが端末４００にて当該操作をしたタイミングが考えられる。なお、クライアント登録要求は、クライアント名、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用するためのリダイレクトＵＲＬを含む。また、その他の情報として、クライアントを説明するための文字列や、説明が記載されるサイトのＵＲＬ、等の付属情報を含むよう構成する事もできる。

アプリケーションモジュール８００からのクライアント登録要求を受け付けたＨＴＴＰサーバーモジュール６１０はＳＳＬ／ＴＬＳ通信のネゴシエーションを開始する。その際、デバイス登録要求に関してはクライアント認証を要求するよう設定されているため、アプリケーションモジュール８００に対して証明書を要求する。Ｓ１．２にてＨＴＴＰサーバーモジュール６１０は不図示の証明書ストアにて設定されている証明書を用いて、取得した証明書を検証し、アプリケーションモジュール８００をデバイス登録の要求元として認証する。なお、本実施の形態では、クライアント登録要求の要求元の認証方法としてＳＳＬ／ＴＳＬの証明書による認証方式にて説明したが、例えば、Ｂａｓｉｃ認証やＤｉｇｅｓｔ認証といった、ＩＤおよびパスワードを用いる方式等が考えられる。さらには、これら主体を認証する手段を経て、認証された主体に対してクライアントを登録するための認可トークンを発行する手段を設け、当該認可トークンを検証する事によってクライアント登録を受け付けるよう構成する事も可能である。ここで認証に失敗した場合、ＨＴＴＰサーバーモジュール６１０はアプリケーションモジュール８００に対してエラーを応答する。

Ｓ１．３にて、ＨＴＴＰサーバーモジュール６１０は、アプリケーションモジュール８００を認証した後に、認可サーバーモジュール６００に対して、アプリケーションモジュール８００から受信したクライアント登録要求を通知する。その際、認証したアプリケーションモジュール８００を識別するための情報も通知する。より具体的には取得した証明書の情報を通知する。Ｓ１．４にて認可サーバーモジュール６００は、ＨＴＴＰサーバーモジュール６１０より通知された証明書の情報を取得する。次に、Ｓ１．５にて、認可サーバーモジュール６００は、取得した証明書のシリアル番号、発行者、主体者をキーとして証明書管理テーブル１２００の情報を特定し、テナントマスターＤＮ１２０６の情報を取得する。その際、開始日時１２０４、終了日時１２０５を有効期間として、検証するよう構成する事もできる。ここで、証明書管理テーブル１２００にレコードが無い場合や、有効期間の検証に失敗した場合、認可サーバーモジュール６００はＨＴＴＰサーバーモジュール６１０を介してアプリケーションモジュール８００にエラーを応答する。

続いて、Ｓ１．６にて認可サーバーモジュール６００は、取得したテナントマスターＤＮ２０６をキーとして、クライアント管理テーブル１３００からテナントＩＤ１３０３を取得する。そして、取得したテナントＩＤ１３０３をキーとしてデフォルト権限管理テーブル１４００から、デフォルト権限ＩＤ１４０２を取得する。取得されるデフォルト権限ＩＤ４０２は複数である事があり得る。また、デフォルト権限管理テーブル１４００に一つも登録されていない場合は、後述のクライアント権限テーブル１５００への登録は行わない。このように、クライアントであるアプリケーションモジュール８００が送信する認証情報に紐付けられた権限が、アプリケーションモジュール８００に与えられる。

そして、Ｓ１．７にて認可サーバーモジュール６００は、取得した情報を元にクライアント管理テーブル１３００にクライアントを新規登録する。より具体的には、クライアントＩＤ、シークレットを発行し、ＤＮを作成し、それぞれ１３０１、１３０２、１３０５に格納する。そして、取得したクライアント名、リダイレクトＵＲＬ、および、テナントマスターＤＮ２０６により特定されたテナントＩＤを、それぞれ１３０６、１３０７および１３０３に格納する。その際、種別１３０４は一般とする。そして、Ｓ１．８にて認可サーバーモジュール６００は発行し、登録したクライアントＩＤとデフォルト権限管理テーブル１４００から取得したデフォルト権限ＩＤとを、クライアント権限テーブル１５００に格納する。この際、複数のデフォルト権限ＩＤが取得されている場合は、複数のデータを格納する事になる。

上記登録が完了した後に、Ｓ１．９にて認可サーバーモジュール６００は、発行したクライアントＩＤとシークレットを、ＨＴＴＰサーバーモジュール６１０を介してアプリケーションモジュール８００に応答する。以上がクライアント登録の説明である。これらシーケンスによって、クライアントをオンライン登録する際に、アプリケーションモジュール８００を識別し、適切な権限を付与する事が可能となる。

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

Ｓ１．１０にて、アプリケーションモジュール８００は認可トークン取得を開始する。なお、認可トークン取得を開始するきっかけとしては、ユーザーが端末４００を用いてアプリケーションモジュール８００を開始した場合が考えられる。また、アプリケーションモジュール８００が明示的に開始する操作を備え、ユーザーが端末４００にて当該操作をしたタイミングが考えられる。ここで、認可トークンの発行処理はＯＡｕｔｈ２．０に定義されているフローに従って実施される。なお本実施例では、フローとしてＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔ、およびＣｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔのケースを説明する。Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔによる認可トークン発行処理については図７、図８ａ、図８ｂおよび図８ｃを用いて後述する。また、Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔによる認可トークン発行処理については図９を用いて後述する。Ｓ１．１１にて、アプリケーションモジュール８００は、各認可トークンの取得フローによって認可トークンを取得する。Ｓ１．１２にて、アプリケーションモジュール８００は取得した認可トークンを用いてリソースサーバーモジュール７００にリソース要求を行う。ここで、リソースサーバーモジュール７００は図６にて不図示のＨＴＴＰサーバーモジュール７１０を介して要求の受信および、応答の送信を行う。

Ｓ１．１３にてリソースサーバーモジュール７００は認可トークン検証要求を認可サーバーモジュール６００に行う。ここで、本実施例では、リソースサーバーモジュール７００および認可サーバーモジュール６００間の通信はＬＡＮ１０１を介して行うよう説明するが、ＷＡＮ１００を介して行うよう構成する事も可能である。その際は、互いのＨＴＴＰサーバーモジュール６１０および、７１０を介して通信する事になる。認可サーバーモジュール６００にて、認可トークン検証要求を受け付けた際に行われる認可トークン検証処理については図１０を用いて後述する。

Ｓ１．１４にてリソースサーバーモジュール７００は、認可サーバーモジュール６００より認可トークン検証応答を受信する。ここで、検証結果が有効（Ｖａｌｉｄ）である場合は、Ｓ１．１５にてリソース取得処理を行う。そして、Ｓ１．１６にてアプリケーションモジュール８００に対して取得したリソースを応答し、処理を終了する。また、認可トークン検証応答の結果が無効（Ｉｎｖａｌｉｄ）である場合は、Ｓ１．１７にてアプリケーションモジュール８００に対してエラー応答を行い、処理を終了する。以上が、アプリケーションモジュール８００における、認可トークンの取得から認可トークンを利用してのリソース取得までの説明である。

次に、ＯＡｕｔｈ２．０における Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔの場合の認可トークン発行処理について図７および、図８ａ、図８ｂ、図８ｃを用いて説明する。Ｓ２．１において、アプリケーションモジュール８００はＷｅｂブラウザー８２０を介してＨＴＴＰサーバーモジュール６１０へ認可要求を行う。なお、ＨＴＴＰサーバーモジュール６１０において、認可要求を受け付けるエンドポイントは、クライアント認証ではなくユーザー認証を要求するよう設定されている。なお、認可要求には、少なくとも、クライアント登録の結果取得したクライアントＩＤおよび登録したリダイレクトＵＲＬ、そして取得する予定のリソース範囲を示す少なくとも一つのオーナースコープを含む、一つないしは複数のスコープＩＤを含む。取得する予定のリソース、即ちアプリケーションモジュール８００が要求する権限は、ユーザーがアプリケーションモジュール８００のどの機能を選択し操作したかによって変わってくる。例えば、セキュリティープリントを選択した場合、リソースサーバーが提供するセキュリティー機能とプリント機能が必要になるので、要求する権限は夫々の機能に対応する２つの権限になる。

Ｓ２．２においてＨＴＴＰサーバーモジュール６１０は認可要求を受ける。そして、ＨＴＴＰサーバーモジュール６１０はＳ２．３ にて、ユーザー認証をするための認証画面であるログイン画面をＷｅｂブラウザー８２０に応答する。ここで図８ａはＨＴＴＰサーバーモジュール８２０が応答するログイン画面例である。本実施例ではユーザーはユーザーＩＤおよびパスワードを入力し、それらの組がユーザー管理テーブル１７００に登録されている情報の組と一致する場合に認証するよう構成されている。なおユーザーを認証する手段として他の手段、例えば、Ｘ．５０９の証明書や、パスワードを複数回入力する多段階認証等、別の手段を構成する事も可能であり、本手段に限定するものではない。図８ａは、ユーザーＩＤを入力するユーザーＩＤ入力欄２００１、パスワードを入力するパスワード入力欄２００２、およびログイン操作を実行するためのログインボタン２００３から成る。

Ｓ２．４にてユーザーはＷｅｂブラウザー８２０に表示された図８ａに必要な情報を入力し、ログインボタン２００３を押下する。Ｓ２．５にてＷｅｂブラウザー８２０は入力された情報をＨＴＴＰサーバーモジュール６１０に送信する。Ｓ２．６にてＨＴＴＰサーバーモジュール６１０はユーザーＩＤ、パスワードを取得し、ユーザー管理テーブル１７００のユーザーＩＤ１７０１、パスワード１７０２の情報の組と比較し一致するかを検証する事でユーザーを認証する。ＨＴＴＰサーバーモジュール６１０は、ユーザー認証に失敗、つまり、ユーザー管理テーブル１７００に取得した情報が登録されていない場合は、不図示の認証エラー画面をＷｅｂブラウザー８２０に応答する。ユーザー認証に成功した場合、ＨＴＴＰサーバーモジュール６１０は認証トークンを生成する。この認証トークンはＨＴＴＰサーバーモジュール６１０の不揮発メモリ上に、ユーザーＩＤと対応付けて保存される。そして、Ｓ２．７にてＨＴＴＰサーバーモジュール６１０は、アプリケーションモジュール８００から受信した認可要求を認可サーバーモジュール６００に通知する。その際、生成した認証トークンを付与して通知する。

Ｓ２．８にて認可サーバーモジュール６００は受信した認可要求のうち、クライアントＩＤとリダイレクトＵＲＬの組が正しいか検証する。より具体的には、クライアント管理テーブル１３００に登録されているクライアントＩＤ１３０１とリダイレクトＵＲＬ１３０７の組が一致するか検証する。不一致の場合、認可サーバーモジュール６００は不図示のエラー画面を、ＨＴＴＰサーバーモジュール６１０を介してＷｅｂブラウザー８２０に応答する。一致した場合、認可サーバーモジュール６００はＳ２．９にてユーザー情報を取得する。より具体的には、ＨＴＴＰサーバーモジュール６１０から通知された認証トークンを用いて、ＨＴＴＰサーバーモジュール６１０から紐づくユーザーＩＤを取得する。そして、そのユーザーＩＤを元にユーザー権限テーブル１８００から権限ＩＤ１８０２を取得する。この時、取得される権限ＩＤ１８０２は、０個である場合や複数個である場合がある。なお、本実施例ではユーザー情報の取得を、認証トークンを元にユーザーＩＤを取得し、認可サーバーモジュール６００がユーザー情報を取得する方法で説明したが、この方法に限定するわけではない。例えば、ＨＴＴＰサーバーモジュール６１０からこれら必要なユーザー情報が通知されるよう構成する事も可能であるし、また、ＨＴＴＰサーバーモジュール６１０へ認証トークンを渡す事で、必要なユーザー情報が取得されるよう構成する事もできる。

Ｓ２．１０にて認可サーバーモジュール６００は、認可要求に含まれるスコープのうち、オーナースコープＩＤをキーとしてスコープテーブル１６００より各オーナースコープの権限ＩＤ１６０４を取得する。そして、Ｓ２．１１にて認可サーバーモジュール６００は、取得したオーナースコープごとの権限ＩＤ１６０４が、ユーザー権限テーブル１８００から取得した権限ＩＤ１８０２に含まれているかを検証する。この時、スコープテーブル１６００にてオーナースコープＩＤに紐づく権限ＩＤ１６０４が複数ある場合は、その複数の権限ＩＤ１６０４のうち少なくとも一つの権限ＩＤがユーザーに設定されている場合は有効（Ｖａｌｉｄ）とみなす。無論、全て含まれる場合に有効と見做してもよく、要求する権限が、予め規定されている権限内に含まれるか否かが重要な点である。また、オーナースコープＩＤに紐づく権限ＩＤが設定されていない場合は、ユーザーの権限に関係なく有効（Ｖａｌｉｄ）とみなす。認可要求に含まれるオーナースコープの内、少なくとも一つ以上の権限ＩＤにて無効（Ｉｎｖａｌｉｄ）となった場合に、認可サーバーモジュール６００はＳ２．２８にて、Ｗｅｂブラウザー８２０に権限エラーを応答する。そして、Ｓ２．２９にて、Ｗｅｂブラウザー８２０はアプリケーションモジュール８００に権限エラーを応答する。より具体的には、認可要求時に取得したリダイレクトＵＲＬに対してＷｅｂブラウザー８２０をリダイレクトするようＷｅｂブラウザー８２０にリダイレクト応答する。Ｓ２．３０にてアプリケーションモジュール８００は図８ｃに例示した権限エラー画面をＷｅｂブラウザー８２０に応答し、処理を終了する。

認可要求に含まれる全てのオーナースコープに対して有効（Ｖａｌｉｄ）となった場合、Ｓ２．１２にて認可サーバーモジュール６００は、Ｗｅｂブラウザー８２０に対して認可確認画面を応答する。図８ｂは応答される認可確認画面の例である。認可確認画面２１００は、認可要求に含まれるクライアントＩＤをキーとしてクライアント管理テーブル１３００から取得したクライアント名１３０６を表示する領域であるアクセス元表示領域２１０１を備える。また、認可要求に含まれるオーナースコープＩＤをキーとしてスコープテーブル１６００から取得したスコープの説明１６０３を表示する領域であるスコープ表示領域２１０２を備える。さらに、認可確認画面２１００は、ユーザーが上記情報の内容について認可操作を実行する許可ボタン２１０３、および拒否を実行する拒否ボタン２１０４を備える。ここで、ユーザーが拒否ボタン２１０４を押下した場合は、認可サーバーモジュール６００は、オーナー権限検証の結果が無効（Ｉｎｖａｌｉｄ）だった場合と同様にＳ２．２８にてアプリケーションモジュール８００に権限エラーを応答する。なお、これら権限エラー応答については、応答を受け付けるアプリケーションモジュール８００にて表示する画面の構成、もしくは文言を変更するために、エラー応答の内容を区別可能に構成する事も可能である。

Ｓ２．１３にてユーザーが認可確認画面２１００を介し許可ボタン２１０３を押下、つまり認可操作を行った場合、Ｗｅｂブラウザー８２０を介し、Ｓ２．１４にて認可サーバーモジュール６００に認可した事が通知される。Ｓ２．１５にて認可サーバーモジュール６００は、認可コードを発行する。より具体的には、認可トークンＩＤを発行し、認可要求に含まれるスコープＩＤ、クライアントＩＤ、認証し許可を得たユーザーのユーザーＩＤをオーナーＩＤとして、認可トークン管理テーブル１９００に登録する。その際、トークン種別１９０２は認可コードとし、有効期限１９０３に当該認可コードが有効である日時を登録する。そして、Ｓ２．１６、Ｓ２．１７にて認可サーバーモジュール６００は発行した認可コードの認可トークンＩＤを付与してＷｅｂブラウザー８２０を介し、アプリケーションモジュール８００に認可を応答する。より具体的には、認可要求時に取得したリダイレクトＵＲＬに対してＷｅｂブラウザー８２０をリダイレクトするようＷｅｂブラウザー８２０にリダイレクト応答する。

Ｓ２．１８にてアプリケーションモジュール８００は、認可サーバーモジュール６００に対して認可トークンを要求する。この認可トークン要求には、少なくとも、取得した認可コード、クライアントＩＤ、シークレット、および認可要求時に送信したリダイレクトＵＲＬを含が含まれる。

Ｓ２．１９にて認可サーバーモジュール６００は取得したクライアントＩＤ、シークレットの組をもってクライアントを認証する。より具体的には、クライアント管理テーブル１３００のクライアントＩＤ１３０１、シークレット１３０２の組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合はアプリケーションモジュール８００に認証エラーを応答する。クライアント認証に成功した場合、Ｓ２．２０にて認可サーバーモジュール６００は、取得した認可コードを検証する。

認可コードの検証としては、取得した認可コードの認可トークンＩＤが認可トークン管理テーブル１９００に登録されているか、登録されている場合は、有効期限１９０３の範囲内かを検証する。さらには、認可トークン要求にて取得したリダイレクトＵＲＬが、認可トークンＩＤに紐づくクライアントＩＤ１９０５をキーとしてクライアント管理テーブル１３００に登録されているリダイレクトＵＲＬ１３０７と一致するかを検証する。認可コード検証の結果が無効であった場合、認可サーバーモジュール６００はアプリケーションモジュール８００にトークン不正エラーを応答する。そして、認可コード検証の結果が有効であった場合、Ｓ２．２１にて認可サーバーモジュール６００はクライアント情報を取得する。より具体的には、認証したクライアントＩＤをキーにクライアント権限テーブル１５００から権限ＩＤ１５０２を取得する。この時、取得される権限ＩＤ１５０２は、０個である場合や複数個である場合がある。

Ｓ２．２２にて認可サーバーモジュール６００は、認可トークン管理テーブル１９００より、取得した認可コードの認可トークンＩＤをキーにスコープＩＤ１９０４を取得する。続いて、取得したスコープのうち、クライアントスコープＩＤをキーとしてスコープテーブル１６００より各クライアントスコープの権限ＩＤ１６０４を取得する。この時、認可トークン管理テーブル１９００より取得したスコープＩＤにクライアントスコープが含まれていない場合、クライアント権限の検証の結果を有効（Ｖａｌｉｄ）とする。

そして、Ｓ２．２３にて認可サーバーモジュール６００は、取得したクライアントスコープごとの権限ＩＤ１６０４が、クライアント権限テーブル１５００から取得した権限ＩＤ１５０２に含まれているかを検証する。この時、スコープテーブル１６００にてクライアントスコープＩＤに紐づく権限ＩＤ１６０４が複数ある場合は、その複数の権限ＩＤ１６０４のうち少なくとも一つの権限ＩＤがクライアントに設定されている場合は有効（Ｖａｌｉｄ）とみなす。また、クライアントスコープＩＤに紐づく権限ＩＤが設定されていない場合は、クライアントの権限に関係なく有効（Ｖａｌｉｄ）とみなす。認可コードに紐づくクライアントスコープの内、少なくとも一つ以上の権限ＩＤの検証にて無効（Ｉｎｖａｌｉｄ）となった場合に、認可サーバーモジュール６００はＳ２．２６にてアプリケーションモジュール８００に権限エラーを応答する。そして、Ｓ２．２７にてアプリケーションモジュール８００は図８ｃに例示した権限エラー画面をＷｅｂブラウザー８２０に応答し、処理を終了する。

認可コードに紐づく全てのクライアントスコープに対して有効（Ｖａｌｉｄ）となった場合、Ｓ２．２４にて認可サーバーモジュール６００は認可トークンを発行する。より具体的には、認可トークンＩＤを発行し、認可コードに紐づくスコープＩＤ、オーナーＩＤ、認証したクライアントＩＤを認可トークン管理テーブル１９００に登録する。その際、トークン種別１９０２は認可トークンとし、有効期限１９０３に当該認可トークンが有効である日時を登録する。そして、Ｓ２．２４にて認可サーバーモジュール６００は発行した認可トークンの認可トークンＩＤをアプリケーションモジュール８００に応答し、処理を終了する。その際、認可トークンの有効期限を応答するよう構成する事もできる。本実施例では、認可トークンを更新するためのリフレッシュトークンを発行しない例で説明したが、認可トークン管理テーブル１９００にて、リフレッシュトークンのＩＤ、および有効期限を管理するよう構成する事もできる。その際、認可トークン発行時に同時にリフレッシュトークンも発行し、認可トークンの応答時に発行したリフレッシュトークンのＩＤも含めて応答するよう構成する事もできる。

次に、ＯＡｕｔｈ２．０におけるＣｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔの場合の認可トークン発行処理について図９を用いて説明する。Ｓ３．１にてアプリケーションモジュール８００は、認可サーバーモジュール６００に対して認可トークンを要求する。この認可トークン要求には、少なくとも、クライアントＩＤ、シークレット、取得する予定のリソース範囲、または利用するサービスの範囲を示す少なくとも一つのオーナースコープを含む。

Ｓ３．２にて認可サーバーモジュール６００は取得したクライアントＩＤ、シークレットの組をもってクライアントを認証する。より具体的には、クライアント管理テーブル１３００のクライアントＩＤ１３０１、シークレット１３０２の組と一致するかを検証する事で認証する。ここでクライアント認証に失敗した場合はアプリケーションモジュール８００に認証エラーを応答する。クライアント認証に成功した場合、Ｓ３．３にて認可サーバーモジュール６００はクライアント情報を取得する。より具体的には、認証したクライアントＩＤをキーにクライアント権限テーブル１５００から権限ＩＤ１５０２を取得する。この時、取得される権限ＩＤ１５０２は、０個である場合や複数個である場合がある。

Ｓ３．４にて認可サーバーモジュール６００は、認可トークン要求に含まれるスコープのうち、オーナースコープＩＤをキーとしてスコープテーブル１６００より各オーナースコープの権限ＩＤ１６０４を取得する。そして、Ｓ３．５にて認可サーバーモジュール６００は、取得したオーナースコープごとの権限ＩＤ１６０４が、クライアント権限テーブル１５００から取得した権限ＩＤ１５０２に含まれているかを検証する。この時、スコープテーブル１６００にてオーナースコープＩＤに紐づく権限ＩＤ１６０４が複数ある場合は、その複数の権限ＩＤ１６０４のうち少なくとも一つの権限ＩＤがクライアントに設定されている場合は有効（Ｖａｌｉｄ）とみなす。また、オーナースコープＩＤに紐づく権限ＩＤが設定されていない場合は、クライアントの権限に関係なく有効（Ｖａｌｉｄ）とみなす。

認可トークン要求に含まれる全てのオーナースコープに対して有効（Ｖａｌｉｄ）となった場合はＳ３．６に移行する。Ｓ３．６にて認可サーバーモジュール６００は、認可トークン要求に含まれるスコープのうち、クライアントスコープＩＤをキーとしてスコープテーブル１６００より各クライアントスコープの権限ＩＤ１６０４を取得する。この時、認可トークン要求に含まれるスコープＩＤにクライアントスコープが含まれていない場合、クライアント権限の検証の結果を有効（Ｖａｌｉｄ）とする。そして、Ｓ３．７にて認可サーバーモジュール６００は、取得したクライアントスコープごとの権限ＩＤ１６０４が、クライアント権限テーブル１５００から取得した権限ＩＤ１５０２に含まれているかを検証する。この時、スコープテーブル１６００にてクライアントスコープＩＤに紐づく権限ＩＤ１６０４が複数ある場合は、その複数の権限ＩＤ１６０４のうち少なくとも一つの権限ＩＤがクライアントに設定されている場合は有効（Ｖａｌｉｄ）とみなす。また、クライアントスコープＩＤに紐づく権限ＩＤが設定されていない場合は、クライアントの権限に関係なく有効（Ｖａｌｉｄ）とみなす。

これら検証の結果、認可トークン要求に含まれるオーナースコープおよびクライアントスコープの内、少なくとも一つ以上の権限ＩＤにて無効（Ｉｎｖａｌｉｄ）となった場合Ｓ３．１０に移行する。Ｓ３．１０にて認可サーバーモジュール６００はアプリケーションモジュール８００に権限エラーを応答し処理を終了する。そして、認可トークン要求に含まれる全てのオーナースコープおよびクラインとスコープの検証にて有効（Ｖａｌｉｄ）となった場合、Ｓ３．８にて認可サーバーモジュール６００は認可トークンを発行する。より具体的には、認可トークンＩＤを発行し、認可トークン要求に含まれるスコープＩＤ、認証したクライアントのクライアントＩＤおよび、当該クライアントＩＤをオーナーＩＤとして、認可トークン管理テーブル１９００に登録する。その際、トークン種別１９０２は認可トークンとし、有効期限１９０３に当該認可コードが有効である日時を登録する。そして、Ｓ３．９にて認可サーバーモジュール６００は発行した認可トークンの認可トークンＩＤをアプリケーションモジュール８００に応答し、処理を終了する。その際、認可トークンの有効期限を応答するよう構成する事もできる。

次に、認可トークン検証処理について図１０を用いて説明する。図１０は認可サーバーモジュール６００にて実施される認可トークン検証処理のフローである。ステップＳ４．１にて、認可サーバーモジュール６００は、リソースサーバーモジュール７００より認可トークン検証依頼を受ける。この認可トークン検証依頼には、検証対象となる認可トークンの認可トークンＩＤおよび、少なくとも一つ以上のスコープＩＤが含まれている。ステップＳ４．２にて、認可サーバーモジュール６００は、これら認可トークンＩＤおよび、スコープＩＤを取得する。次に、ステップＳ４．３にて認可サーバーモジュール６００は、取得した認可トークンＩＤを元に、認可トークンの情報を取得する。より具体的には、認可トークンＩＤ、およびトークン種別：認可トークンをキーとして認可トークン管理テーブル１９００から有効期限１９０３を取得する。そして、ステップＳ４．４にて、認可トークンが存在しているか、つまり、認可トークン管理テーブル１９００に存在するかの検証、および、有効期限内であるかを検証する。検証の結果、存在しない場合、もしくは存在するが有効期限内でない場合は認可トークンが無効と判断し、ステップＳ４．５にてトークン不正エラーを返却し、処理を終了する。検証の結果、認可トークンが存在し、かつ有効期限内である場合は処理を継続する。

ステップＳ４．６にて認可サーバーモジュール６００は、検証依頼に含まれるスコープの情報を取得する。より具体的には、スコープＩＤをキーにスコープテーブル１６００より各スコープの種別１６０２、権限ＩＤ１６０４を取得する。次に、ステップＳ４．７にて、取得した一つないしは複数のスコープの種別１６０２に少なくとも一つ以上、オーナースコープが含まれているか確認する。結果、一つもない場合はステップＳ４．１１に移行する。一つ以上含まれている場合、ステップＳ４．８にて認可サーバーモジュール６００はオーナー情報を取得する。より具体的には、認可トークンＩＤをキーに認可トークン管理テーブル１９００からオーナーＩＤ１９０８を取得する。そして、取得したオーナーＩＤをキーにクライアント権限テーブル１５００および、ユーザー権限テーブル１８００から、それぞれ権限ＩＤ１５０２および、権限ＩＤ１８０２を取得する。この時、取得される権限ＩＤ１５０２は０個である場合や複数個である場合がある。

次に、ステップＳ４．９にて認可サーバーモジュール６００は、ステップＳ４．６で取得したオーナースコープに対する権限検証を行う。より具体的には、Ｓ４．６で取得したオーナースコープＩＤをキーとしてスコープテーブル１６００より各オーナースコープの権限ＩＤ１６０４を取得する。そして、取得したオーナースコープごとの権限ＩＤ１６０４が、ステップＳ４．８にて取得した権限ＩＤ１５０２か、もしくは権限ＩＤ１８０２に含まれているかを検証する。この時、スコープテーブル１６００にてオーナースコープＩＤに紐づく権限ＩＤ１６０４が複数ある場合は、その複数の権限ＩＤ１６０４のうち少なくとも一つの権限ＩＤがオーナーに設定されている場合は有効とみなす。また、オーナースコープＩＤに紐づく権限ＩＤが設定されていない場合は、オーナーの権限に関係なく有効とみなす。検証の結果、少なくとも一つ以上の権限ＩＤにて無効となった場合、認可サーバーモジュール６００はステップＳ４．１０にてリソースサーバーモジュール７００に権限エラーを応答し処理を終了する。検証の結果、Ｓ４．６で取得した全てのオーナースコープに対して有効となった場合、認可サーバーモジュール６００はステップＳ４．１１に移行する。

ステップＳ４．１１にて認可サーバーモジュール６００は、Ｓ４．６にて取得した一つないしは複数のスコープの種別１６０２に少なくとも一つ以上、クライアントスコープが含まれているか確認する。結果、一つもない場合はステップＳ４．１５に移行する。一つ以上含まれている場合、ステップＳ４．１２にて認可サーバーモジュール６００はクライアント情報を取得する。より具体的には、認可トークンＩＤをキーに認可トークン管理テーブル１９００からクライアントＩＤ１９０７を取得し、取得したクラインとＩＤをキーにクライアント権限テーブル１５００から権限ＩＤ１５０２を取得する。この時、取得される権限ＩＤ１５０２は０個である場合や複数個である場合がある。

次に、ステップＳ４．１３にて認可サーバーモジュール６００は、ステップＳ４．６で取得したクライアントスコープに対する権限検証を行う。より具体的には、Ｓ４．６で取得したクライアントスコープＩＤをキーとしてスコープテーブル１６００より各クライアントスコープの権限ＩＤ１６０４を取得する。そして、取得したクライアントスコープごとの権限ＩＤ１６０４が、ステップＳ４．１２にて取得した権限ＩＤ１５０２に含まれているかを検証する。この時、スコープテーブル１６００にてクライアントコープＩＤに紐づく権限ＩＤ１６０４が複数ある場合は、その複数の権限ＩＤ１６０４のうち少なくとも一つの権限ＩＤがクライアントに設定されている場合は有効とみなす。また、クライアントスコープＩＤに紐づく権限ＩＤが設定されていない場合は、クライアントの権限に関係なく有効とみなす。検証の結果、少なくとも一つ以上の権限ＩＤにて無効となった場合、認可サーバーモジュール６００はステップＳ４．１４にてリソースサーバーモジュール７００に権限エラーを応答し処理を終了する。

検証の結果、Ｓ４．６で取得した全てのクライアントスコープに対して有効となった場合、認可サーバーモジュール６００はステップＳ４．１５に移行する。ステップＳ４．１５にて認可サーバーモジュール６００は、認可トークンの検証処理結果として権限が有効であることをリソースサーバーモジュール７００に応答し、処理を終了する。これらシーケンスによって、リソースサーバーモジュール７００は適切な権限を有した、アプリケーションモジュール８００からのアクセスのみを有効とし、意図しないアプリケーションモジュール８００からのを権限エラーとして防ぐことが可能となる。

本実施の形態によれば、オンライン登録されるアプリケーションモジュール８００に付与する権限を、当該アプリケーションモジュール８００を識別して付与する事が可能となる。そして、リソースサーバーモジュール７００に対する意図しないアプリケーションモジュール８００からの利用を防ぐことが可能となる。例えば、リソースサーバーモジュール７００の有償サービスに対しては、有償サービスを利用できるアプリケーションモジュール８００（有償アプリケーション）に予め有償サービスが利用できる証明書が組み込まれているので、そのようなアプリケーションモジュール８００しか利用できない。

図６で説明したクライアント登録シーケンスでは、認可サーバーモジュール６００側にて、クライアントに設定される権限ＩＤを決定する処理を説明した。しかしながら、その処理フローでは、クライアント登録は成功するが、その後の認可トークン発行要求時に権限エラーが発生する可能性がある。その場合、クライアント登録処理が無駄になってしまう。一方、クライアントは、認可要求、もしくは認可トークン発行要求時に指定するクライアントスコープＩＤは予めわかっている。そこで、クライアントから、クライアント登録時に利用するクライアントスコープをリクエストし、権限が不足なのであれば、その時点で登録エラーが返却されるよう処理する事で無駄なクライアント登録を回避する事ができる。

上記課題を解決するための第２の実施形態について図１１、および図１２を用いて説明する。なお、第２の実施形態では、図６中のクライアント登録シーケンス以外には差異が無いため説明を省略する。また、図６と同様の処理を実施するシーケンスについては同じシーケンス番号を付与し、説明を省略する。

図１１は、第２の実施形態のクライアント登録シーケンスである。Ｓ５．１にて、端末４００のアプリケーションモジュール８００は、認可サーバー２００のＨＴＴＰサーバーモジュール６１０に対してクライアント登録要求を行う。なお、アプリケーションモジュール８００がクライアント登録要求を行うきっかけとして、本実施例では、端末４００にて、ユーザーが当該アプリケーションモジュール８００をインストールし、初めて起動したタイミングとして説明する。なお、他のきっかけとして、ユーザーがアプリケーションモジュール８００の機能を選択し、リソースサーバー３００へのリソース要求が発生するタイミングが考えられる。また、アプリケーションモジュール８００が明示的に開始する操作を備え、ユーザーが端末４００にて当該操作をしたタイミングが考えられる。なお、クライアント登録要求は、クライアント名、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを利用するためのリダイレクトＵＲＬ、および、認可要求、もしくは認可トークン要求時に指定するクライアントスコープＩＤを含む。また、その他の情報として、クライアントを説明するための文字列や、説明が記載されるサイトのＵＲＬ、等の付属情報を含むよう構成する事もできる。

次の、アプリケーションモジュール８００からのクライアント登録要求を受け付けた際のＨＴＴＰサーバーモジュール６１０でのクライアント認証処理Ｓ１．２の説明は省略する。Ｓ５．２にて、ＨＴＴＰサーバーモジュール６１０は、アプリケーションモジュール８００を認証した後に、認可サーバーモジュール６００に対して、アプリケーションモジュール８００から受信したクライアント登録要求を通知する。その際、認証したアプリケーションモジュール８００を識別するための情報も通知する。より具体的には取得した証明書の情報を通知する。Ｓ１．４、Ｓ１．５、Ｓ１．６を経て、認可サーバーモジュール６００デフォルト権限ＩＤ１４０２を取得する。処理詳細については前述のとおりである。

次に、Ｓ５．３にて認可サーバーモジュール６００は登録権限検証を開始する。この登録権限検証処理については図１２を用いて説明する。図１２は認可サーバーモジュール６００における登録権限検証処理のフローである。ステップＳ６．１にて認可サーバーモジュール６００は、登録権限検証依頼を受け付ける。次に、ステップＳ６．２にてクライアント登録要求で受けたクライアントスコープ情報を取得する。より具体的には、指定のスコープＩＤおよび、スコープの種別：クライアントスコープをキーとしてスコープテーブル１６００より権限ＩＤ１６０４を取得する。ここで、ステップＳ６．３にて、指定のスコープＩＤにクライアントスコープが含まれない場合は、ステップＳ６．４に移行し、検証結果が有効であったとしてＳ１．６にて取得したデフォルト権限ＩＤを返却し、処理を終了する。指定のスコープＩＤにクライアントスコープが含まれる場合は、ステップＳ６．５に移行する。

ステップＳ６．５にて認可サーバーモジュール６００は、取得したクライアントスコープの権限ＩＤ１６０４がＳ１．６にて取得したデフォルト権限ＩＤに含まれているかを検証する。少なくとも一つ以上の権限ＩＤ１６０４が、デフォルト権限ＩＤに含まれていない場合、ステップＳ６．６にて権限エラーを返却し処理を終了する。ステップＳ６．２にて取得した全ての権限ＩＤ１６０４がデフォルト権限ＩＤに含まれている場合、認可サーバーモジュール６００は、ステップＳ６．７にて、検証結果が有効であったとしてステップ取得した全ての権限ＩＤ１６０４を返却し、処理を終了する。

Ｓ５．４にて認可サーバーモジュール６００は登録権限検証の処理終了結果を取得する。結果、無効（Ｉｎｖａｌｉｄ）の場合、Ｓ５．６にてアプリケーションモジュール８００にクライアント登録エラーを応答する。そして、登録権限検証の結果が有効（Ｖａｌｉｄ）の場合、Ｓ１．７にて認可サーバーモジュール６００は、クライアントを新規登録する。処理の詳細については前述のとおりである。次に、Ｓ５．５にて認可サーバーモジュール６００は発行し、登録したクライアントＩＤと登録権限検証の結果取得した権限ＩＤとを、クライアント権限テーブル１５００に格納する。この際、複数の権限ＩＤが取得されている場合は、複数のデータを格納する事になる。上記登録が完了した後に、Ｓ１．９にて認可サーバーモジュール６００は、発行したクライアントＩＤとシークレットを、ＨＴＴＰサーバーモジュール６１０を介してアプリケーションモジュール８００に応答する。以上が第２の実施形態におけるクライアント登録の説明である。

上記処理により、認可サーバーモジュール６００は、クライアントから、クライアント登録時に利用するスコープのリクエストを受け付け、権限が不足なのであれば、その時点で登録エラーが返却されるよう処理する事が可能となる。結果、無駄なクライアント登録を回避する事ができる。

［その他の実施例］
本願発明の各実施例においては、有償サービス、無償サービス、有償アプリケーション、および無償アプリケーションを例に説明をした。しかし、サービス、およびアプリケーションは必ずしもこれに限るものではない。特定のアプリケーションが、特定のサービスに対し不必要なアクセスを行わせないよう、権限移譲処理におけるアプリケーション登録プロトコルを制限できるものであればどのようなサービス、アプリケーションであっても良い。

また、本願発明の各実施例においては、端末に備えられたアプリケーションと、インターネット上のサービスとの処理における権限移譲の方法を説明した。しかし、端末に備えられたアプリケーションに限らず、インターネットを介して接続されたサーバー型のサービスであっても良い。そこで、本願発明では、連携元の主体をサービスと称することとする。

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

２００ 認可サーバー
２１０ リソースサーバー
３００ 画像形成装置
４００ 端末
５００ データベースサーバー
６００ 認可サーバーモジュール
７００ リソースサーバーモジュール
８００ アプリケーションモジュール
８２０ Ｗｅｂブラウザー

Claims (11)

1. アプリケーションを備えたデバイスへサービスを提供するサーバーシステムと、前記サービスにおけるユーザーの権限を前記サービスの利用元へ移譲するための認可処理を行う認可サーバーシステムとを含む権限移譲システムであって、
   前記アプリケーションを前記利用元として登録する要求を受信したことに応じて前記アプリケーションの権限を特定し、特定された前記権限と前記アプリケーションの識別子とを紐付けて管理する管理手段と、
   前記サービスを利用するための要求を送信するアプリケーションに前記ユーザーの権限を移譲することを許可する認可操作が行われ、かつ前記アプリケーションが利用する権限が、前記アプリケーションの識別子に紐付く権限内に含まれる場合に前記サービスを提供する提供手段と、を有する権限移譲システム。
2. 前記管理手段は、前記アプリケーションを前記利用元として登録する要求とともに前記アプリケーションの認証情報を受信し、受信された認証情報を基に前記アプリケーションの権限を特定することを特徴とする請求項１に記載の権限移譲システム。
3. 前記ユーザーの認証情報を入力するための認証画面を提供し、前記認証画面を介して入力された認証情報を基に前記ユーザーの権限を特定し、
   前記提供手段は、更に、前記アプリケーションが利用する権限が、特定された前記ユーザーの権限内に含まれる場合に前記サービスを提供することを特徴とする請求項１または２に記載の権限移譲システム。
4. 前記サービスを利用するための要求を送信するアプリケーションに前記ユーザーの権限を移譲することを許可する認可操作が行われなかった場合、または前記アプリケーションが利用する権限が、前記アプリケーションの識別子に紐付く権限内に含まれない場合、または、前記アプリケーションが利用する権限が、特定された前記ユーザーの権限内に含まれない場合、エラー応答を送信することを特徴とする請求項３に記載の権限移譲システム。
5. 前記管理手段は、前記アプリケーションを前記利用元として登録する要求とともに前記アプリケーションが利用する権限の情報と前記アプリケーションの認証情報を受信し、前記アプリケーションが利用する権限が、前記アプリケーションの認証情報を基に特定された前記アプリケーションの権限内に含まれる場合は、特定された前記権限と前記アプリケーションの識別子とを紐付けて管理し、
   前記アプリケーションが利用する権限が、前記アプリケーションの認証情報を基に特定された前記アプリケーションの権限内に含まれない場合は、前記アプリケーションの登録を行うことなくエラー応答を送信することを特徴とする請求項１乃至４の何れか１項に記載の権限移譲システム。
6. 第１のサービスにおけるユーザーの権限を、前記第１のサービスを利用する第２のサービスへ移譲するための認可処理を行う認可サーバーシステムであって、
   前記第２のサービスを前記第１のサービスの利用元として登録する要求を受信したことに応じて前記第２のサービスの権限を特定し、特定された前記権限と前記第２のサービスの識別子とを紐付けて管理する管理手段と、
   前記第２のサービスの識別子と、前記第２のサービスが利用する権限とを、前記第１のサービスの利用を開始した前記第２のサービスから受信する受信手段と、
   前記第２のサービスに前記ユーザーの権限を移譲することを許可する認可操作が行われ、かつ前記受信手段により受信された前記第２のサービスが利用する権限が、前記受信手段により受信された前記第２のサービスの識別子に紐付く権限内に含まれる場合に、前記第２のサービスに前記ユーザーの権限が移譲されたことを示す認可情報を発行する発行手段と、を有する認可サーバーシステム。
7. 前記管理手段は、前記第２のサービスを前記第１のサービスの利用元として登録する要求とともに前記第２のサービスの認証情報を受信し、受信された認証情報を基に前記第２のサービスの権限を特定することを特徴とする請求項６に記載の認可サーバーシステム。
8. 前記管理手段は、前記第２のサービスを前記利用元として登録する要求とともに前記第２のサービスが利用する権限の情報と前記第２のサービスの認証情報を受信し、前記第２のサービスが利用する権限が、前記第２のサービスの認証情報を基に特定された前記第２のサービスの権限内に含まれる場合は、特定された前記権限と前記第２のサービスの識別子とを紐付けて管理し、
   前記第２のサービスが利用する権限が、前記第２のサービスの認証情報を基に特定された前記第２のサービスの権限内に含まれない場合は、エラー応答を送信することを特徴とする請求項６または７に記載の認可サーバーシステム。
9. 前記第２のサービスは、デバイスに備えられたアプリケーションであることを特徴とする請求項６乃至８の何れか１項に記載の認可サーバーシステム。
10. アプリケーションを備えたデバイスへサービスを提供するサーバーシステムと、前記サービスにおけるユーザーの権限を前記サービスの利用元へ移譲するための認可処理を行う認可サーバーシステムとを含む権限移譲システムを制御する制御方法であって、
    認可サーバーシステムが有する管理手段は、前記アプリケーションを前記利用元として登録する要求を受信したことに応じて前記アプリケーションの権限を特定し、特定された前記権限と前記アプリケーションの識別子とを紐付けて管理し、
    サーバーシステムが有する提供手段は、前記アプリケーションが前記サービスの利用を開始した際に、前記サービスを利用するための要求を送信するアプリケーションに前記ユーザーの権限を移譲することを許可する認可操作が行われ、かつ前記アプリケーションが利用する権限が、前記アプリケーションの識別子に紐付く権限内に含まれる場合に前記サービスを提供することを特徴とする制御方法。
11. 第１のサービスにおけるユーザーの権限を、前記第１のサービスを利用する第２のサービスへ移譲するための認可処理を行う認可サーバーシステムを制御するためのプログラムであって、
    前記第２のサービスを前記第１のサービスの利用元として登録する要求を受信したことに応じて前記第２のサービスの権限を特定し、特定された前記権限と前記第２のサービスの識別子とを紐付けて管理する管理ステップと、
    前記第２のサービスの識別子と、前記第２のサービスが利用する権限とを前記第１のサービスの利用を開始した前記第２のサービスから受信する受信ステップと、
    前記第２のサービスに前記ユーザーの権限を移譲することを許可する認可操作が行われ、かつ前記受信ステップにおいて受信された前記第２のサービスが利用する権限が、前記受信ステップにおいて受信された前記第２のサービスの識別子に紐付く権限内に含まれる場合に、前記第２のサービスに前記ユーザーの権限が移譲されたことを示す認可情報を発行する発行ステップと、を含むプログラム。

Images