JP2014142732A - 権限委譲システム - Google Patents

Abstract

【課題】従来、認可トークンを用いてサービスにアクセスするユーザーの権限をクライアントに委譲する技術がある。しかしながら従来の方法には以下の課題がある。すなわち、サービスにアクセスする際に、どのサービスに対しても認可トークンを利用してアクセスしてしまうと、不正なサービスを指定された際に認可トークンが漏えいしてしまう。
【解決手段】認可トークンを用いてサービスにアクセスするアプリケーションが、サービス情報を保持し、アプリケーションへの要求に含まれるサービス情報と照合して正しいサービスの場合にのみ認可トークンを用いてサービスにアクセスことで認可トークン漏えいを防止する。
【選択図】 図１１

Description

本発明は、権限委譲システム、特に複数アプリケーションを追加可能なデバイスにおけるアプリケーションからクラウドサービスへのアクセス方法に関する。

近年、インターネット上でＰＤＦ形式の電子文書を作成するサービスや電子文書を蓄積するサービス等が提供されている。このようなサービスを利用することでユーザーは、自身が所有する端末自体にＰＤＦ作成機能がない場合でもＰＤＦを作成できるようになる他、端末の記憶容量以上に電子文書を保管できるようにもなる。さらに近年、クラウドが一般化するに伴い、前述のような複数のサービスを連携させて付加価値を創造する機会はますます増加している。サービスを連携させることでサービス提供者は、ユーザーに付加価値を提供することができる。例えば作成したＰＤＦ形式の電子文書を、ユーザーが所有する端末を経由することなく、直接インターネット上で保管できるようにもなる。その一方で、サービスが連携することにより、いくつかの課題が生まれる。

すなわち、ユーザーが望んだ以上の情報がサービス間で交換されるので、ユーザーデータや個人情報の漏えいリスクがある。例えばインターネット上には複数のサービスが存在し、様々なサービス間でサービス連携が実現されるが、ユーザーが望む結果を提供するサービス以外のサービスがユーザーデータ、個人情報等を取得することは望ましくない。一方で、サービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。

このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈについては以降でさらに詳細に説明する。

ＯＡｕｔｈによれば、例えばあるサービスＡが管理するユーザーのデータに、そのユーザーから認められた外部サービスＢがアクセスすることができる。このときサービスＡは、外部サービスＢからアクセスされる範囲を明らかにした上で、外部サービスＢによるアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。

ユーザーが認可操作を行うと、外部サービスＢはサービスＡからアクセスを認められたことを証明するトークン（以下、認可トークンと称する）を受け取り、以降のアクセスはその認可トークンを用いて実現できる。

ここで認可トークンを用いると外部サービスＢは、ユーザーの認証情報なしに、認可を行ったユーザーの権限でサービスＡにアクセスできる。またそのため、ユーザーから認可を受け認可トークンを取得した外部サービスＢは、その認可トークンを厳重かつ適正に管理する責務を負う。

また近年の機器には、ＯＡｕｔｈを用いて、クラウドサービスと連携することでユーザーに付加価値を提供するものがある。

例えばソーシャル・ネットワーキング・サービス（以下、ＳＮＳと呼ぶ）と呼ばれるサービスがある。これらのサービスはスマートフォンから利用することができる。ＳＮＳには様々なものがあるが、特定のアプリケーションをスマートフォンにインストールして利用することで、そのＳＮＳを利用しやすくなることがある。例えば定期的に自分の居場所をＳＮＳに投稿したいユーザーは、スマートフォンの測位機能を使い、定期的に測位とＳＮＳへの投稿を行うアプリケーションを利用すると、便利と感じるだろう。

ここでスマートフォンにインストールされたアプリケーションは、ＳＮＳにユーザーの代理でアクセスすることになる。このような場合にＯＡｕｔｈが利用されることがある。

ユーザーは、ＳＮＳを利用するのに必要な最小限の機能、例えば記事を投稿することをアプリケーションに許可することで、アプリケーションを介してＳＮＳを利用できるようになる。

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

ここで画像形成装置がクラウドサービスと連携する場合を考える。例として、クラウド上の文書を印刷データに変換し、画像形成装置から印刷データを取得するような印刷サービスを想定する。ユーザーがＷｅｂブラウザや画像形成装置でクラウドサービスにログインした際に、画像形成装置に対してクラウドサービスのリソースへのアクセスを権限移譲することで、画像形成装置はクラウドサービスと連携できるようになる。Ｗｅｂブラウザの場合は、クラウドサービスで認証した情報がＷｅｂブラウザを介して画像形成装置にリダイレクトして渡され権限移譲が行われる。このようなシステムにおいては、ネットワーク上に認証情報が複数回に渡って流れるため、情報漏えいの可能性が存在する。認証情報が悪意を持ったユーザーに利用されると、成りすましによる不正アクセスが可能となってしまう。また、ユーザーが認証した情報では、例えば画像形成装置が、ジャムなどのエラーで印刷処理を中断している場合には認証情報の有効期限が切れてしまい、ユーザーが再度認証を行分ければ印刷続行ができなくなってしまう。

この課題を解決するため、画像形成装置内の各アプリケーションに権限委譲を行い、クラウドサービス側でアクセス元のアプリケーションを識別し、ユーザーの認証情報無しに画像形成装置とクラウドアプリケーションの連携を行う方法が提案されている。しかし、前述の方法ではアプリケーションに権限委譲された情報を常に付加してクラウドサービスにアクセスを行うため、悪意のあるユーザーに画像形成装置がアクセスする先を変更されてしまうと、容易に権限委譲された情報が取得できてしまう課題があった。

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

本発明の構成は、複数のアプリケーションを追加可能な画像形成装置（３００）であって、
第一のアプリケーション（４００）は、画像形成装置（３００）を認証するための認証情報を保持する手段（１６００）と、
認可サーバー（２００）から第一の認可トークンを取得する手段（Ｓ１．４、Ｓ１．１０）と、
前記第一の認可トークンを保持する手段（１７００）と、を備え、
第二のアプリケーション（５００）は、リソースサーバー（２１０）にアクセスするための第二の認可トークン取得要求を第一のアプリケーションに送信する手段（Ｓ２．５）と、
第一のアプリケーション（４００）は、第二の認可トークン取得要求元を識別するための第二のアプリケーション識別子を取得する手段（Ｓ２．６）と、
前記第一の認可トークンと前記認証情報および、前記アプリケーションＩＤを用いて第二の認可トークンの取得を要求する手段（Ｓ２．１１）と、
前記第二の認可トークンを、前記第二のアプリケーション（５００）に応答する手段（Ｓ２．１３）と、
前記第二のアプリケーション（５００）は、要求先のリソースサーバーの宛先情報（１９２９）を保持する手段と、
前記第二のアプリケーション（５００）は、リソース要求先が前記リソースサーバーの宛先情報と合致するかどうか判断する手段（Ｓ４．５）と、
前記第二のアプリケーション（５００）は、リソース要求先が前記リソースサーバーの宛先情報と合致した場合は、前記リソースサーバー（２１０）に前記第二の認可トークンを用いてリソース要求する手段（Ｓ２．１４）と、を備え、
さらに前記リソースサーバー（２１０）は、第二の認可トークンからリソース要求元の識別するためのアプリケーション識別子を取得する手段（Ｓ２．１８）と、を備える。

本発明によれば、リソースサービス連携アプリケーションが保持しているサービスへのリクエスト時にのみ子トークンが用いられ、不正なサービスが指定された際にトークンが漏えいすることを防止することが可能となる。

システム構成図 各装置のハードウェア構成図 各装置のソフトウェアモジュール構成図 認可サーバーで管理するテーブル構造 画像形成装置で管理するテーブル構造 親トークン発行までのシーケンス 画面例 子トークン発行までのシーケンス アプリケーション管理シーケンス アプリケーションの構成およびテーブル構造 リソースサービスへのリソース取得要求シーケンス

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

本実施の形態においては、インターネット上で帳票データを生成する帳票サービスと、インターネット上のデータを取得して印刷する印刷サービスが、インターネット上のサーバーに設置されていることを想定している。

以降、帳票サービスや印刷サービスのように、インターネット上で機能を提供しているサービスを、リソースサービスと呼ぶ。

また本実施の形態においては、画像形成装置上にインストールされた印刷アプリケーションおよび帳票アプリケーションがリソースサービスを利用することを想定している。

以降、印刷アプリケーションや帳票アプリケーションのように、リソースサービスを利用するアプリケーションを、リソースサービス連携アプリケーションと呼ぶ。無論、リソースサービスは帳票サービス、印刷サービスには限られず、アプリケーションも帳票アプリケーション、印刷アプリケーションに限られるものではない。また、本実施例において、リソースサービス連携アプリケーションは、一般的なＷｅｂサービスのインターフェースを持つことを想定している。

さらに本実施の形態における権限の移譲ではＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈでは、ユーザーから移譲された権限の証明するための情報として、トークンと呼ばれる情報を利用する。

ここで特に、ユーザーが画像形成装置に対して権限移譲した場合のトークンを親トークンと称する。本願発明では、ユーザーの権限を画像形成装置のようなデバイス機器に移譲することもポイントの１つである。

例えば、画像形成装置上に印刷アプリケーション、帳票アプリケーションが存在する場合を考える。

この場合ユーザーは、印刷アプリケーションからリソースサービスを利用する場合は印刷アプリケーションに、帳票アプリケーションからリソースサービスを利用する場合は帳票アプリケーションに、それぞれ個別に認可を与える必要がある。

ユーザーの立場で考えると、同一の画像形成装置からリソースサービスを利用する場合には、例えば、一度の認可操作でそれぞれのアプリケーションでリソースサービスを利用できるようになった方が、利便性が高い。

そこで、アプリケーションに権限を移譲させる際、ユーザーに代わり画像形成装置がアプリケーションに権限を移譲することで、ユーザーの認可操作の回数を低減させる。

即ち、ユーザーは画像形成装置に権限を移譲した段階で、アプリケーションにも権限を移譲することを認めたこととなる。

なお、本願発明は、画像形成装置に権限を移譲する際にユーザーに認可操作を行わせるが、アプリケーションに権限を移譲する際にはユーザーに認可操作を行わせない。

ただし、認可操作を一度で済ませる手段として、画像形成装置が取得した親トークンを、画像形成装置上のアプリケーションで共有できるようにすると、親トークンを共有する全アプリケーションが全てのリソースサービスにアクセス可能となり好ましくない。これは、アプリケーションが共有された親トークンを用いてリソースサービスにアクセスした場合、リソースサービス側にてアクセス元のアプリケーションが特定できず、利用の可否を判断する事ができないためである。

結果、以下のようなケースでは課題となる。印刷サービスは印刷アプリケーションからアクセスされ、利用される事を想定してサービスが展開されているため、帳票アプリケーションのような想定していないアプリケーションからの接続は拒否したい。また帳票サービスも同様に帳票アプリケーションからのアクセスのみ許可したい。これは、リソースサービスで管理している情報がユーザーの機密性が高い情報を取り扱うサービスである場合に、不特定のアプリケーションからの利用を許可すると情報の漏洩経路になるリスクがあるためである。

また、想定していないアプリケーションからの接続を許可するとしても、どのようなアプリケーションからのアクセスであったのかの記録を残したいという要求も存在する。これは、例えば、より利用頻度の高いアプリケーションを特定し、そのアプリケーションの利用シーンに合わせて機能を拡張していくといった、リソースサービスの機能拡張への戦略を決めるうえで有用な情報である。

そこで本願発明においては、個々のリソースサービス連携アプリケーションは親トークンを直接使うのでなく、親トークンに移譲された情報を継承しつつ、アプリケーションを特定可能な情報を付与して再移譲を行う。

画像形成装置が、親トークンに移譲されたトークン情報を継承し、さらにアプリケーションを特定可能な情報を付与してリソースサービス連携アプリケーションに権限を再移譲した場合に発行されるトークンを子トークンと称する。

本実施の形態に係る権限移譲システムは、図１に示すような構成のネットワーク上に実現される。

１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。

２００はＯＡｕｔｈを実現するための認可サーバーであり、認可サービスモジュールが設置されている。２１０はリソースサーバーであり、印刷サービスや帳票サービスといったリソースサービスが設置されている。なお１台のリソースサーバーに設置されるリソースサービスは１つでもよく、複数でもよい。３００は画像形成装置であり、１つまたは複数のリソースサービス連携アプリケーションがインストールされている。ユーザーはそれらのリソースサービス連携アプリケーションを用いてリソースサービスを利用する。また認可サーバー２００、リソースサービス２１０、画像形成装置３００はそれぞれＷＡＮ１００およびＬＡＮ１０１を介して接続されている。なお認可サーバー２００、リソースサービス２１０、画像形成装置３００はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また認可サーバー２００、リソースサービス２１０は同一のサーバー上に構成されていてもよい。

本実施の形態に係る権限移譲システムは、図２に示すような構成のサーバーおよび画像形成装置から成るシステム上に実現される。

図２は、認可サーバー２００と画像形成装置３００とがＷＡＮ１００およびＬＡＮ１０１を介して通信可能に接続されている様子を示す。

まず、認可サーバー２００の構成について説明する。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の認可サーバー２００には一般的な情報処理装置のハードウェア構成を適用できる。また認可サーバー２００だけでなく、リソースサーバー２１０についても同様である。

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

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

次に、画像形成装置３００の構成について説明する。図示するように、画像形成装置３００において、３０１は画像形成装置３００のＣＰＵであり、ＲＯＭ３０２や、外部メモリ３０３に記憶された制御プログラムに基づいてシステムバス３０４に接続される各ブロックを制御する。ＣＰＵ３０１の処理により生成された画像信号が、印刷部Ｉ／Ｆ３０５を介して、印刷部（画像形成装置エンジン）３０６に出力情報として出力される。また、ＣＰＵ３０１は、入力部３０７とネットワーク部３１０を介して認可サーバー２００との通信処理が可能となっており、画像形成装置３００内の情報等を認可サーバー２００に通知できる。

ＲＯＭ３０２内のプログラムＲＯＭには、ＣＰＵ３０１の制御プログラム等を記憶している。ＲＯＭ３０２内のフォント用ＲＯＭには、出力情報を生成する際に使用するフォントデータ等を記憶している。ＲＯＭ３０２内のデータ用ＲＯＭには、ハードディスク等の外部メモリ３０３がない画像形成装置の場合、認可サーバー２００と送受信を行う情報等を記憶している。

ＲＡＭ３０８は、ＣＰＵ３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ３０８は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。

外部メモリ３０３は、メモリコントローラ（ＭＣ）３０９によりアクセスを制御される。外部メモリ３０３は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作部３１１は操作のためのスイッチ及びＬＥＤ表示器等で構成されている。

尚、後述の全ての説明においては、特に断りのない限り画像形成装置における実行のハード上の主体はＣＰＵ３０１であり、ソフトウェア上の主体は外部メモリ３０３にインストールされたアプリケーションプログラムである。

図３は本実施の形態に係る、認可サーバー２００、リソースサーバー２１０、画像形成装置３００それぞれのモジュール構成を示す図である。なお認可サーバー２００、リソースサーバー２１０、画像形成装置３００は図２のものと同一である。認可サーバー２００は認可サーバーモジュール６００を持ち、認可サーバーモジュール６００はユーザー識別部６０１、クライアント検証部６０２、親トークン発行部６０３、子トークン発行部６１１、子トークン検証部６２０を持つ。リソースサーバー２１０はリソースサーバーモジュール７００を持ち、リソースサーバーモジュール７００は子トークン権限確認部７０１とリソース要求処理部７０２を持つ。クライアント端末２２０はＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ１２００を持つ。

図中３００は画像形成装置３００である。画像形成装置３００はＣＰＵ３０１がＲＯＭ３０２、或いは外部メモリ３０３に記憶されたＯＳを実行する事で各アプリケーションを制御する。ここで８２０はそのＯＳであり、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用される事もある。次に、８１０は仮想マシンであり、例えばＪａｖａ（登録商標）ＶＭがよく知られている。この仮想マシン８１０はＯＳで制御されるアプリケーションとして動作する仮想的なアプリケーション実行環境である。次に、８００はアプリケーション管理フレームワークであり、仮想マシン８１０が提供するアプリケーション実行環境上で動作する管理対象のアプリケーションのライフサイクルを管理する機能をもつ。またそれを制御するＩ／Ｆ、および各アプリケーション間での処理要求を仲介するためのＩ／Ｆ公開機能を備えている。ライフサイクルとはアプリケーションのインストール、起動、停止、アンインストールを含むアプリケーションの状態を示すものとする。本実施例におけるアプリケーション管理フレームワーク８００は、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）アライアンスで規定されたＯＳＧｉ（登録商標）として説明する。また、認可サーバー連携クライアント５００、１つまたは複数のリソースサーバー連携アプリケーション４００、ログインアプリケーション１０００は、仮想マシン８１０が提供するアプリケーション実行環境にて動作する各種アプリケーションである。また、これらアプリケーションはアプリケーション管理フレームワーク８００にてライフサイクル管理されている。なお、アプリケーション管理フレームワークは、後述するアプリケーション定義ファイルに記載された定義値に基づきアプリケーションの管理を行う。例えば、アプリケーションに固有に割り当てられているアプリケーションＩＤとインストールされている、もしくは開始されているアプリケーションの実態との紐づけ管理を行う。８３０はアプリケーション管理フレームワーク８００が公開するライフサイクル管理用の制御Ｉ／Ｆを介して、ユーザーからの各種アプリケーションのインストールや、開始リクエストを受け付け実行するアプリケーション管理アプリケーションである。

ここで認可サーバー連携クライアント５００、リソースサーバー連携アプリケーション４００およびログインアプリケーション１０００は、画像形成装置が既定で持っていてもよい。またアプリケーション管理アプリケーション８３０および、アプリケーション管理フレームワーク８００を介して後からインストールされてもよい。さらに、画像形成装置３００はＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ９００を備える。なお、アプリケーション管理フレームワーク８００におけるアプリケーションのインストール、開始のシーケンスについては後述する。

図４（ａ）、図４（ｂ）、図４（ｃ）は認可サーバー２００が外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー２００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。

図４（ａ）はユーザー管理テーブル１２００である。ユーザー管理テーブル１２００は、ユーザーＩＤ１２０１、パスワード１２０２、ユーザー種別１２０３から成る。認可サーバー２００は、ユーザーＩＤ１２０１、パスワード１２０２の情報の組を検証し、正しければ認証情報を生成することで、各ユーザーもしくはクライアントを認証する機能を備える。

図４（ｂ）はクライアント管理テーブル１３００である。クライアント管理テーブル１３００はクライアントＩＤ１３０１、クライアント名１３０２、リダイレクトＵＲＬ１３０３、シリアル番号１３０４から成る。クライアントＩＤ１３０１は、ユーザー管理テーブル１２００のユーザーＩＤ１２０１と関連付いており、互いに参照可能となっている。クライアント名１３０２、リダイレクトＵＲＬ１３０３は後述のＯＡｕｔｈのシーケンスで利用される値である。そして、シリアル番号１３０４はクライアントが画像形成装置３００で合った場合に登録される値であり、画像形成装置をユニークに識別可能な値である。

図４（ｃ）は認可トークン管理テーブル１４００である。認可トークン管理テーブル１４００は、認可トークンＩＤ１４０１、トークン種別１４０２、有効期限１４０３、スコープ１４０４、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６、クライアントＩＤ１４０７、ユーザーＩＤ１４０８、アプリケーションＩＤ１４０９から成る。これら認可トークン管理テーブル１４００の処理詳細については後述する。

図５（ａ）、図５（ｂ）、図５（ｃ）は画像形成装置３００が外部メモリに記憶するデータテーブルである。

図５（ａ）はデバイスユーザー管理テーブル１５００である。デバイスユーザー管理テーブル１５００はログインアプリケーション１０００から参照、更新可能なように構成されている。また、本実施例では画像形成装置３００の外部メモリに記憶するよう記載しているが、画像形成装置３００がＬＡＮ１０１を介して通信可能な別サーバーにて構成する事もできる。デバイスユーザー管理テーブル１５００は、ユーザーＩＤ１５０１、パスワード１５０２、ＩＣカード情報１５０３から成る。ログインアプリケーション１０００は、画像形成装置３００の入力画面を用いてユーザーからのユーザーＩＤ、パスワードを受け付ける画面（不図示）を構成する。そして、入力されたユーザーＩＤ、パスワードの組が、ユーザーＩＤ１５０１、パスワード１５０２の組と合っているか検証し、正しければユーザーＩＤ１５０１の情報を含むログインコンテキストを生成することで、各ユーザーを認証する機能を備える。また、ログインアプリケーション１０００は画像形成装置３００に接続された不図示のＩＣカードリーダーからＩＣカード情報を取得し、ＩＣカード情報１５０３の情報を検証する。その結果が正しければ対応するユーザーＩＤ１５０１の情報を含むログインコンテキストを生成する事で、各ユーザーを認証する機能を備える事もできる。ここで、ログインコンテキストとは、認証を受けたユーザーのユーザーＩＤ１５０１の情報が設定されたオブジェクトである。その他に、ユーザーの属性情報、例えば、ユーザーが所属するドメインやユーザーの電子メールアドレス等の情報を設定するよう構成する事もできる。

図５（ｂ）はデバイス管理テーブル１６００である。デバイス管理テーブル１６００は認可サーバー連携クライアント５００のみから参照、更新可能なように構成されている。デバイス管理テーブル１６００は、クライアントＩＤ１６０１、クライアントシークレット１６０２、エンドポイントＵＲＬ１６０３、リダイレクトＵＲＬ１６０４から成る。ここで、クライアントＩＤ１６０１、クライアントシークレット１６０２は、予め認可サーバー２００にて発行、記憶されたユーザーＩＤ１２０１、パスワード１２０２にそれぞれ対応している。さらに、リダイレクトＵＲＬ１６０４も、認可サーバー２００のクライアント管理テーブルに、クライアントＩＤ１３０１、クライアント名１３０２、画像形成装置３００のシリアル番号１３０４と共に登録されている情報と同様のデータが格納されている。これら情報の登録方法としては、例えば、画像形成装置３００がＬＡＮ１０１、ＷＡＮ１００を介してオンラインで登録する方法や、ユーザーを介して認可サーバー２００、画像形成装置３００にてそれぞれ値を設定する方法でも良い。なお、エンドポイントＵＲＬ１６０３は認可サーバーが公開するＯＡｕｔｈのためのエンドポイントのＵＲＬである。

図５（ｃ）は親トークン管理テーブル１７００である。親トーク管理テーブル１７００は認可サーバー連携クライアント５００からのみ参照、更新可能なよう構成されている。親トークン管理テーブル１７００は、ユーザーＩＤ１７０１、認可トークンＩＤ１７０２、リフレッシュトークンＩＤ１７０３から成る。親トークン管理テーブル１７００の処理詳細については後述する。

ここで、親トークン取得に関する本実施形態のシーケンスを図６、図７を用いて説明する。

本シーケンスは、ユーザーが画像形成装置３００を最初に利用する際に一度だけ行う操作である。

まずユーザーが画像形成装置３００においてログインアプリケーション１０００が提供するログイン手段を用いて画像形成装置３００にログインする（Ｓ１．１）。ここでユーザーＩＤがｕｓｅｒ００１ のユーザーがログインしたとする。すると、ログインアプリケーション１０００はｕｓｅｒ００１を含むログインコンテキストを生成し、アプリケーション管理フレームワーク８００を介して各アプリケーションから取得可能なようＲＡＭ３０８に格納する（Ｓ１．２）。

次に、ユーザーは画像形成装置３００を操作してブラウザ９００を実行する。そして、ブラウザ９００を用いて認可サーバー連携クライアント５００の認可連携を開始するためのＵＲＬへアクセスする（Ｓ１．３）。ここで認可サーバー連携クライアント５００は図７（ａ）に示すような認可連携開始を確認する画面１８０１を応答するよう構成しても良い。

認可サーバー連携クライアント５００は、認可連携の開始を受け付けたら、デバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３に記載のＵＲＬに対して、ＯＡｕｔｈの認可リクエストをするようブラウザ９００にリダイレクト要求する（Ｓ１．４）。この認可リクエストには、デバイス管理テーブル１６００のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０４の情報が含まれる。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施例では、スコープとしてスコープＡがリクエストされたとして説明する。

認可リクエストを受け付けた認可サーバー２００は、ユーザーを認証するために図７（ｂ）に示すログイン画面１８０２をブラウザ９００に応答する（Ｓ１．５）。ユーザーはブラウザ９００に示されたログイン画面１８０２に対して、ユーザーＩＤ、パスワードを入力しログインを実行する（Ｓ１．６）。認可サーバー２００は受け付けたユーザーＩＤ、パスワードの組がユーザー管理テーブル１２００に登録されている情報と合っているかを検証し、合っている場合はユーザーＩＤを紐づいた認証情報を生成して次の処理を実行する。認可サーバー２００は、認可リクエストに含まれているクライアントＩＤとリダイレクトＵＲＬの組みが、クライアント管理テーブル１３００に登録されている情報と合っているか検証する。検証の結果正しければ、クライアント管理テーブル１３００のクライアント名１３０２を取得し、図７（ｃ）に示す認可確認画面１８０３を生成しブラウザ９００に応答する（Ｓ１．７）。その際、認証情報をブラウザ９００に対してＣｏｏｋｉｅ情報として格納して応答する。なお、実施例では、認可確認画面１８０３にクライアント名１３０２を表示するよう説明したが、ここにクライアントの詳細な説明を追加して表示する事や、ログインしているユーザーの情報を表示するよう構成する事もできる。また認可リクエストにスコープを含む場合は、当該スコープの範囲を説明する情報を認可確認画面１８０３に表示するよう構成する事も出来る。

次に、ユーザーはブラウザ９００に表示された認可確認画面１８０３で許可を実行する（Ｓ１．８）。許可を受けた認可サーバー２００は次の処理を実行する。認可トークン管理テーブル１４００に認可コードを発行し登録する。その際、認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２、認可コード、有効期限１４０３、認可リクエスト時に受け付けたクライアントＩＤをクライアントＩＤ１４０７に登録する。また、ブラウザ９００からＣｏｏｋｉｅとして送信された認証情報に紐づくユーザーＩＤをユーザーＩＤ１４０８に登録する。そして、認可応答として、認可コードの認可トークンＩＤを付与したリダイレクトＵＲＬに対してブラウザ９００をリダイレクト要求する（Ｓ１．９）。

認可応答を受けた認可サーバー連携クライアント５００は、認可サーバー２００に対してトークン要求を行う（Ｓ１．１０）。このトークン要求には、認可応答で取得した認可コードの認可トークンＩＤ、デバイス管理テーブル１６００のクライアントＩＤ１６０１、クライアントシークレット１６０２、リダイレクトＵＲＬ１６０４を含む。
トークン要求を受けた認可サーバー２００は以下の検証を行い、正しい場合は親トークンを生成する（Ｓ１．１１）。認可サーバー２００は、トークン要求で受けつけたクライアントＩＤ、クライアントシークレットの組が、ユーザー管理テーブル１２００に登録されているユーザーＩＤ１２０１、パスワード１２０２の組と合っているか検証する。次に、トークン要求で受けつけた認可コードの認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか、有効期限内かを検証する。そして、トークン要求で受けつけたクライアントＩＤとリダイレクトＵＲＬがそれぞれ認可トークン管理テーブル１４００の認可トークンＩＤで特定されるクライアントＩＤ１４０７と、クライアント管理テーブル１３００のリダイレクトＵＲＬ１３０３と合っているかを検証する。ここで、リダイレクトＵＲＬ１３０３はクライアント管理テーブル１３００ではなく、認可トークン管理テーブル１４００にカラムを追加し、認可コード発行時に登録して、該追加カラムと検証するよう構成する事もできる。これらすべての検証が正しい場合に認可サーバー２００は親トークンを生成して、親トークンの認可トークンＩＤを認可サーバー−連携クライアント５００に応答するこの際、応答内容として同時に発行したリフレッシュトークンＩＤも含む（Ｓ１．１２）。親トークンとしては、認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２に親トークン、有効期限１４０３、および、認可コードから引き継ぐ情報として、クライアントＩＤ１４０７、ユーザーＩＤ１４０８を登録する。この際、親トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６に登録する。リフレッシュのフローについては後述する。

親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを取得した認可サーバー連携くクライアント５００は、アプリケーション管理フレームワーク８００を介して画像形成装置３００にログインしているユーザーのログインコンテキストを取得する（Ｓ１．１３）。そして、認可サーバー連携クライアント５００は、ログインコンテキストからデバイスユーザーＩＤを取得し、親トークン管理テーブル１７００に、デバイスユーザーＩＤ、親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを保存する（Ｓ１．１４）。そして、認可サーバー連携クライアント５００は、不図示の認可連携完了の旨を示す画面を画像形成装置のＷｅｂブラウザ９００に応答し、処理を終了する。

続いて、親トークンが発行されたあとの子トークンの取得に関する本実施の形態のシーケンスを、図８を用いて説明する。

本シーケンスは、ユーザーが画像形成装置３００に備えるリソースサービス連携アプリケーション４００を実行する際に行われるシーケンスである。なお、前述の親トークン取得のシーケンスが実施されている必要がある。

まずユーザーが画像形成装置３００においてログインアプリケーション１０００が提供するログイン手段を用いて画像形成装置３００にログインする（Ｓ２．１）。ここでユーザーＩＤがｕｓｅｒ００１ のユーザーがログインしたとする。すると、ログインアプリケーション１０００はｕｓｅｒ００１を含むログインコンテキストを生成し、アプリケーション管理フレームワーク８００を介して各アプリケーションから取得可能なようＲＡＭ３０８に格納する（Ｓ２．２）。なお、前述の親トークン取得のシーケンスの後に連続して実行する場合は、再度ログインする必要はなく、次のＳ２．３からの操作シーケンスとなる。

次に、ユーザーは画像形成装置３００を操作してリソースサービス連携アプリケーション４００のアプリケーション画面（不図示）にアクセスする（Ｓ２．３）。このアプリケーション画面は例えば、リソース連携アプリケーション４００が印刷アプリケーションであった場合は印刷する文書を選択する画面であり、帳票アプリケーションであった場合は、作成する帳票を選択する画面である。ここでアプリケーション画面にアクセスするとは、例えば、画像形成装置３００が備える操作パネル上にアプリケーション管理フレームワーク８００にて開始状態とされている各アプリケーションが選択可能に表示されており、その中から当該アプリケーションを選択する事を指す。

アプリケーション画面にアクセスされたリソースサービス連携アプリケーション４００は、アプリケーション管理フレームワーク８００からログインコンテキストを取得する（Ｓ２．４）。そして、アプリケーション管理フレームワーク８００に登録されている認可サーバー連携クライアント５００のトークン取得インターフェースに対してトークン取得要求を行う（Ｓ２．５）。この際、取得したログインコンテキストを要求に含める。なお、ここでトークンに必要なスコープを要求するよう構成する事もできる。本実施例では、スコープＡが引き続き要求されたとして説明する。

トークン取得要求を受けた認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００を介して、要求元のリソースサービス連携アプリケーション４００のアプリケーションＩＤを取得する（Ｓ２．６）。

これら、アプリケーション管理フレームワーク８００に対するインターフェース登録、インターフェース取得、および、アプリケーションＩＤ取得のシーケンスについては後述する。

アプリケーションＩＤを取得した認可サーバー連携クライアント５００は以下の処理を行う。まず、取得したログインコンテキストが有効かどうかアプリケーション管理フレームワーク８００を介して検証する。そして、正しい場合はログインコンテキストに紐づいたデバイスユーザーＩＤを取得する。なお、このログインコンテキストの検証は、認可サーバー連携クライアント５００で実施するよう説明したが、ログインコンテキストのインスタンス生成をアプリケーション管理フレームワーク８００のみ行えるよう構成し、インスタンスが生成されている事によって、正当であると判断するよう構成する事もできる。次に、認可サーバー連携クライアント５００は、取得したデバイスユーザーＩＤをキーに親トークン管理テーブル１７００からリフレッシュトークンＩＤを取得する。この時、親トークン管理テーブル１７００にユーザーＩＤが登録されていない場合は、親トークン取得シーケンスを実施するようユーザーに促す画面（不図示）を提示するよう構成する事もできる。また、場合によってはブラウザ９００を起動し、親トークン取得シーケンスを自動的に開始するよう構成するでも良い。

認可サーバー連携クライアント５００は取得したリフレッシュトークンＩＤと、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレットを用いて、認可サーバー２００にトークンリフレッシュ要求を行う（Ｓ２．７）。ここでは、親トークン取得シーケンスの実行から、子トークン取得のシーケンスまでの間に時間が経過し、親トークンの有効期限が切れている事として説明しているが、親トークンの有効期限内で合った場合は、トークンリフレッシュ要求を実施せず、Ｓ２．１１の子トークン取得要求を実施するでも良い。

トークンリフレッシュ要求を受けた認可サーバー２００は、以下の処理を実行する。まず、トークンリフレッシュ要求に含まれるクライアントＩＤ、クライアントシークレットの組がユーザー管理テーブル１２００のユーザーＩＤ１２０１とパスワード１２０２の組と合っているかを検証する。正しい場合は、トークンリフレッシュ要求に含まれるリフレッシュトークンＩＤが認可トークン管理テーブル１４００に登録されており、リフレッシュ期限内か確認する。さらに、トークンリフレッシュ要求に含まれるクライアントＩＤがクライアントＩＤ１４０７と一致するか検証し、全ての検証が正しい場合は、親トークンをリフレッシュし、リフレッシュした親トークンの認可トークンＩＤと、リフレッシュトークンＩＤを認可サーバー連携クライアント５００に応答する（Ｓ２．９）。ここで、リフレッシュの方法としては、新たに認可トークンＩＤ、リフレッシュトークンＩＤを発行して認可トークン管理テーブル１４００に登録する。この際、トークンリフレッシュ要求で受けつけたリフレッシュトークンＩＤによって特定されるレコードのトークン種別１４０２、スコープ１４０４、クライアントＩＤ１４０７、ユーザーＩＤ１４０８を引き継ぐ。また、引き継ぎ後、元のリフレッシュトークンＩＤは再度リフレッシュできないよう無効化、より具体的には有効期限を強制的に期限切れにする事も出来るし、リフレッシュトークンＩＤは新規発行せず、引き継ぐよう構成する事も可能である。

リフレッシュされた親トークンを取得した認可サーバー連携クライアント５００は、受け付けた認可トークンＩＤ、リフレッシュトークンＩＤにて、親トークン管理テーブルの情報を上書きし、再登録する（Ｓ２．１０）。そして、親トークンの認可トークンＩＤと、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレット、トークン取得要求で受けつけたスコープ、および、取得したアプリケーションＩＤを用いて、認可サーバー２００に子トークン取得要求を行う（Ｓ２．１１）。ここで子トークン取得要求に含めるアプリケーションＩＤがリソースサービス連携アプリケーション４００による改竄の余地がない事は後述する。

子トークン取得要求を受けた認可サーバー２００は以下の処理を実行する。まず、子トークン取得要求に含まれるクライアントＩＤ、クライアントシークレットの組がユーザー管理テーブル１２００のユーザーＩＤ１２０１とパスワード１２０２の組と合っているかを検証する。正しい場合は、子トークン取得要求に含まれる認可トークンＩＤが認可トークン管理テーブル１４００に登録されており、有効期限内か確認する。さらに、子トークン取得要求に含まれるクライアントＩＤがクライアントＩＤ１４０７と一致するか検証し、全ての検証が正しい場合は、子トークンを生成し認可サーバー連携クライアント５００に応答する（Ｓ２．１３）。ここで、子トークンは新たに認可トークンＩＤを発行して、トークン種別１４０２を子トークン、アプリケーションＩＤ１４０９に取得したアプリケーションＩＤ、スコープ１４０４に子トークン取得要求に含まれるスコープを、認可トークン管理テーブル１４００に登録する。この際、子トークン取得要求で受けつけた認可トークンＩＤによって特定されるレコードのクライアントＩＤ１４０７、ユーザーＩＤ１４０８を引き継ぐ。結果、この時発行した子トークンには、ユーザーを特定するためのユーザーＩＤ、画像形成装置を特定するためのクライアントＩＤ、およびアプリケーションを特定するためのアプリケーションＩＤが紐づく。なお、子トークンではリフレッシュトークンは発行しない。これは、トークンリフレッシュ要求するためにはクライアントＩＤ、クライアントシークレットが必要であるため、子トークンを利用する各アプリケーションではリフレッシュ要求は出来ない事と、さらには、各アプリケーションがリフレッシュトークンを漏洩する事で、自由にトークンの有効期限を更新されてしまうセキュリティリスクをなくすためである。

そして、子トークンの認可トークンＩＤを取得した認可サーバー連携クライアント５００は要求元のリソースサービス連携アプリケーション４００に子トークンの認可トークンＩＤを応答する。子トークンの認可トークンＩＤを取得したリソースサービス連携アプリケーション４００は、リソースサーバー２１０に認可トークンＩＤを含むリソース要求を行う（Ｓ２．１４）。

リソース要求を受けたリソースサーバー２１０は、要求に含まれる子トークンの認可トークンＩＤのトークン検証を認可サーバー２００に対して要求する（Ｓ２．１５）。このトークン検証要求には、スコープを含める事ができる。

トークン検証要求を受けた認可サーバー２００は、受け付けた認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか、有効期限内か、および、受け付けたスコープがスコープ１４０４の範囲内かを検証（Ｓ２．１６）し、検証結果をリソースサーバー２１０に応答する（Ｓ２．１７）。

次に、リソースサーバー２１０は認可サーバー２００に対して、子トークンの認可トークンＩＤのトークン情報取得を要求する（Ｓ２．１８）。

トークン情報取得要求を受けた認可サーバー２００は、認可トークン管理テーブル１４００から受け付けた認可トークンＩＤにて特定される情報を取得し、それら情報をリソースサーバー２１０に応答する（Ｓ２．１９）。この応答には、例えば、スコープ１４０４、クライアントＩＤ１４０７、ユーザーＩＤ１４０８、アプリケーションＩＤ１４０９の情報を含む。さらには、クライアントＩＤ１４０７にて特定されるクライアント管理テーブル１３００に登録されているシリアル番号１３０４を含むよう構成する事もできる。

トークン情報を取得したリソースサーバー２１０は、取得した情報を元に要求を受け付けたリソースに対するアクセスを許可するか拒否するかを判断する。ここでは、リソースサーバー２１０に予めアクセス可能なアプリケーションＩＤが設定されているとし、その設定されているアプリケーションＩＤと、トークン情報から取得されたアプリケーションＩＤを比較することでアクセスを許可するかを検証する（Ｓ２．２０）。検証の結果、アクセス許可と判断された場合は、リソースサービス連携アプリケーション４００に対して、リソースを応答する（Ｓ２．２１）。ここで、リソースは例えば、リソースサーバー２１０が印刷サービスであった場合は印刷可能な文書のリストであり、帳票サービスであった場合は、作成可能な帳票のリストである。

ここで、Ｓ２．１５から、Ｓ２．２０まで、トークンの検証を認可サーバー２００、リソースサーバー２１０それぞれで行うよう説明したが、リソースに対するアクセス可能なアプリケーションを認可サーバー２００で管理し、全ての検証を認可サーバー２００で行うよう構成する事も可能である。また、本実施例ではアクセス可能なアプリケーションの判断をアプリケーションＩＤを用いて実施するよう説明したが、トークン情報から取得できるシリアル番号やクライアントＩＤを元に画像形成装置３００を識別し、アクセスの可否を判断するよう構成する事もできる。また、同様に、トークン情報から取得できるスコープやユーザーＩＤを元にアクセスの可否を判断するよう構成する事もできる。

リソース応答を受け付けたリソースサービス連携アプリケーション４００は、受信したデータを元に前述のアプリケーション画面を構成し、ユーザーに応答する（Ｓ２．２２）。

次に、リソースサービス連携アプリケーション４００が認可サーバー連携クライアント５００へのトークン取得要求をする方法および、認可サーバー連携クライアント５００が要求元のアプリケーションＩＤを取得する方法について説明する。

図１０（ａ）はインストールするアプリケーションのアプリケーションファイルの構成を示す図である。アプリケーションファイル１９００は、アプリケーション定義ファイル１９０１、アプリケーションの実態であるアプリケーション１９０２から成る。また、アプリケーションファイルはアプリケーション定義ファイル１９０１、アプリケーション１９０２を含む形で暗号化されており、復号するための鍵はライセンスファイル１９１０に記載されている。また、アプリケーション定義ファイル１９０１は、アプリケーションを一意に識別するためのアプリケーションＩＤと、アプリケーションのバージョン、およびアプリケーション名が記述されている。また、アプリケーション定義ファイル１９０１は、その他にも、アプリケーションが消費する記憶領域等のリソース量の定義や、アプリケーションを開始するときに実行するクラスのクラスパス等が記載されている。

図１０（ｂ）は、アプリケーションをインストールする際に必要となるライセンスファイルの構成を示す図である。ライセンスファイル１９１０は、アプリケーションファイル１９００を復号するためのアプリケーション復号鍵１９１１から成る。またライセンスファイル１９１０は、アプリケーション管理アプリケーション８３０にて保持している秘密鍵で復号可能なよう公開鍵にて暗号化されている。

これらの構成により、アプリケーション管理アプリケーション８３０にて保持している秘密鍵が漏洩しない限りは、アプリケーション定義ファイル１９０１、およびアプリケーション１９０２は改竄出来ないよう保護されている。
図１０（ｃ）はアプリケーション管理フレームワーク８００にて管理されるアプリケーション管理テーブル１９２０である。アプリケーション管理テーブル１９２０は、アプリケーションＩＤ１９２１、バージョン１９２２、アプリケーション名１９２３、保存場所１９２４、状態１９２５から成る。

また、アプリケーション管理フレームワーク８００は、各アプリケーションが実行され、ＲＡＭ３０８上に展開された状態であるアプリケーションオブジェクトをリストで管理している。このアプリケーションオブジェクトのリストの各アプリケーションは、アプリケーション管理テーブル１９２０の情報とアプリケーションＩＤで紐づいており、アプリケーション管理テーブル１９２０の各情報を参照可能に構成されている。また、アプリケーションオブジェクトのリストは、アプリケーション管理フレームワーク８００のＩ／Ｆを介してアプリケーション管理アプリケーション８３０から取得可能なよう構成されている。

図１０（ｄ）はリソースサービス連携アプリケーションが保持するサービス管理テーブルである。サーバ名１９２６は、リソースサービス連携アプリケーションがサービスにアクセスする際に使用される情報であり、後述のリソース取得のリクエスト先の判定に使用される。ホスト名１９２７は、サービスのホスト名、サービスＵＲＬ１９２８はサービスのＵＲＬを示す。該情報は、アプリケーションがあらかじめ保持する場合と、アプリケーションの管理者が追加することも可能である。

次に、画像形成装置３００にアプリケーションをインストールシーケンスと、各アプリケーションを開始するシーケンスを、図９を用いて説明する。また、図８で説明したシーケンスと同じ処理に関しては共通のシーケンス番号とし、説明を省略する。

まず、アプリケーションのインストールシーケンスについて説明する。

ユーザーは、クライアント端末２２０に備えるＷｅｂブラウザ１２００を用いて、画像形成装置３００のアプリケーション管理アプリケーション８３０が備えるアプリケーション管理画面（不図示）にアクセスする（Ｓ３．１）。アプリケーション管理アプリケーション８３０は、アプリケーション管理画面を応答する（Ｓ３．２）。このとき、アプリケーション管理アプリケーション８３０へのアクセス認証として不図示のログイン画面を表示し、認証を実施するよう構成する事もできる。

次にユーザーは、アプリケーション管理画面に、インストールするアプリケーションファイル１９００およびライセンスファイル１９１０をアップロードし、インストール指示を行う（Ｓ３．３）。本実施例では、アプリケーションとして、リソースサービス連携アプリケーション４００として印刷アプリケーションがアップロードされたとして説明する。

アプリケーションファイル１９００および、ライセンスファイル１９１０を受け付けたアプリケーション管理アプリケーション８３０は、以下の処理を行う。アプリケーション管理アプリケーション８３０が保持している秘密鍵でライセンスファイルを復号する。復号に成功するとライセンスファイル１９１０からアプリケーション復号鍵１９１１を取得する。次に、受け付けたアプリケーションファイル１９００をアプリケーション復号鍵１９１１で復号する。復号したアプリケーションファイルより、アプリケーション定義ファイル１９０１を取得し定義内容を解析する。アプリケーション復号鍵１９１１にて復号でき、さらにアプリケーション定義ファイル１９０１が解析出来たことにより、アプリケーション定義ファイル１９０１内に記載の内容は正当であると判断できる。

また、アプリケーションファイル１９００はアプリケーション定義ファイル１９０１とアプリケーション１９０２の署名値が記載されたファイルを保持するよう構成する事も可能である。その場合は、アプリケーション復号鍵１９１１にて復号後に、署名値を検証する事でより検証の精度を高める事も可能である。

次に、アプリケーション管理アプリケーション８３０は、復号し、取得したアプリケーション定義ファイル１９０１および、アプリケーション１９０２を、アプリケーション管理フレームワーク８００のＩ／Ｆを介して、アプリケーションを画像形成装置３００に保存する。その際、アプリケーション定義ファイルを展開し、アプリケーションＩＤ、バージョン等の情報と共に保存場所をアプリケーション管理テーブル１９２０に記憶する（Ｓ３．５）。また、その際、アプリケーションの状態１９２５に「インストール済み」として登録する。

次に、アプリケーションの開始シーケンスについて説明する。なお、画像形成装置３００には、前述したリソースサービス連携アプリケーション４００および、既に認可サーバー連携クライアント５００がインストールされているとする。

ユーザーは、クライアント端末２２０に備えるＷｅｂブラウザ１２００を用いてアプリケーション管理アプリケーション８３０に対して、認可サーバー連携クライアント５００を開始するよう指示する（Ｓ３．６）。アプリケーション管理アプリケーション８３０は、アプリケーション管理フレームワーク８００のＩ／Ｆを介してアプリケーション管理テーブル１９２０の情報を元に、認可サーバー連携クライアント５００の保存場所を特定し、アプリケーションを開始する。

アプリケーション開始指示を受けた認可サーバー連携クライアント５００は、自身の子トークン取得要求を受け付けるためのインターフェースをアプリケーション管理フレームワーク８００に登録する。登録を受けたアプリケーション管理フレームワーク８００は、インターフェースを記憶する。

インターフェース登録が完了した認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００にアプリケーション開始を応答する（Ｓ３．８）。

アプリケーション管理フレームワーク８００は、認可サーバー連携クライアント５００の状態１９２５を開始状態に変更し、開始されたアプリケーションオブジェクトをアプリケーションオブジェクトリストにて保持する（Ｓ３．９）。

次に、ユーザーは、クライアント端末２２０に備えるＷｅｂブラウザ１２００を用いてアプリケーション管理アプリケーション８３０に対して、リソースサービス連携アプリケーション４００を開始するよう指示する（Ｓ３．１０）。アプリケーション管理アプリケーション８３０は、アプリケーション管理フレームワーク８００を介して、アプリケーション管理テーブル１９２０の情報を元に、リソースサービス連携アプリケーション４００の保存場所を特定し、アプリケーションを開始する。

アプリケーション開始指示を受けたリソースサービス連携アプリケーション４００は、アプリケーションの初期化処理を実行し、アプリケーション管理フレームワーク８００に対してアプリケーション開始を応答する（Ｓ３．１１）。

アプリケーション管理フレームワーク８００は、リソースサービス連携アプリケーション４００の状態１９２５を開始に変更し、開始されたアプリケーションオブジェクトをアプリケーションオブジェクトリストにて保持する（Ｓ３．１２）。

上記シーケンスによって、アプリケーション管理フレームワーク８００は画像形成装置３００にインストールされている各アプリケーションを開始し、各アプリケーションのアプリケーション定義ファイルに記載されているアプリケーションＩＤを各アプリケーションオブジェクトから参照可能なように保持する事ができる。また、アプリケーション管理フレームワーク８００は、アプリケーションからインターフェース登録を受け付ける事で、他のアプリケーションから登録されたインターフェースを実行可能に保持する事ができる。この時、インターフェース登録の方法としては、インターフェースが定義されたクラスへのクラスパス（クラス定義への参照パス）を渡す。

次に、Ｓ２．３にてリソースサービス連携アプリケーション４００のアプリケーション画面にユーザーがアクセスした際のシーケンスの詳細を説明する。

リソースサービス連携アプリケーション４００は、前述したように、Ｓ２．４にてログインコンテキストを取得後、Ｓ２．５にて認可サーバー連携クライアント５００にトークン取得要求を行う。その際、Ｓ３．１３にて、アプリケーション管理フレームワーク８００に対して登録されているインターフェースの取得要求を行う。インターフェース取得要求を受けたアプリケーション管理フレームワーク８００は、要求元のアプリケーションをアプリケーションオブジェクトのリストより特定し、アプリケーション定義ファイルに記載されているアプリケーションＩＤを取得する（Ｓ３．１４）。ここで、本実施例ではインターフェース取得要求を行ったアプリケーションオブジェクトの特定方法として、インターフェース取得要求の引数に、アプリケーションのオブジェクトを参照として格納するよう構成する。ただし、インターフェース取得要求元のアプリケーションオブジェクトの特定方法としては記載の方法に限定せず、例えば、仮想マシン８１０が備える要求元を逆引きするような機能を利用し特定する事も考えられる。そして、登録されている認可サーバー連携クライアント５００から登録されたインターフェース定義クラスのクラスパスから、参照先のインターフェース定義クラスを実体化してオブジェクト生成するようリクエストする（Ｓ３．１５）。この際、取得したリソースサービス連携アプリケーション４００のアプリケーションＩＤをオブジェクト生成リクエストに設定する。オブジェクト生成リクエストを受けた認可サーバー連携クライアント５００は、アプリケーションＩＤが設定されたインターフェース定義クラスのオブジェクトを生成し、アプリケーション管理フレームワーク８００に応答する。そして、アプリケーション管理フレームワーク８００は生成されたインターフェースクラスのオブジェクトをリソースサービス連携アプリケーション４００に応答する（Ｓ３．１６）。

認可サーバー連携クライアント５００のインターフェースのオブジェクトを取得したリソースサービス連携アプリケーション４００は、インターフェース定義クラスに定義されているトークン取得要求を実行する（Ｓ２．５）。認可サーバー連携クライアント（５００）は、トークン取得要求を受けたインターフェース定義クラスのオブジェクトに設定されたアプリケーションＩＤを取得する（Ｓ２．６）。

これらシーケンスによって、アプリケーションによる改竄を防止した形で、アプリケーションＩＤを認可サーバー連携クライアント５００にて取得する事が可能となる。

次にリソースサービス連携アプリケーション４００がリソースサーバー２１０からデータを取得する際の具体的な処理に関して図１１を用いて説明する。リソースサービスへのリソース取得リクエストは、ユーザーがクライアント端末２２０に備えるＷｅｂブラウザ１２００または、リソースサービス連携アプリケーション４００の不図示のユーザーインターフェースを介して行われる。

Ｗｅｂブラウザの場合、Ｗｅｂブラウザ上で操作された内容に応じて、リソースサービス２１０へ情報が送信される（Ｓ４．１）。リソースサービス２１０は、受信した情報に応じて、リソースサービス連携アプリケーションに対してリクエストを実行させるためのスクリプトが含まれた画面を生成し（４．２）、Ｗｅｂブラウザに送信する（Ｓ４．３）。Ｗｅｂブラウザ１２００がＪａｖａＳｃｒｉｐｔ（登録商標）のクロスドメイン通信機能または、同等の機能を備えたＷｅｂブラウザの場合、Ｗｅｂブラウザによって前記スクリプトが実行され、リソースサーバー連携アプリケーション４００に対してリソース取得リクエストが行われる（Ｓ４．４）。リソースサービス連携アプリケーション４００のユーザーインターフェース（不図示）上で操作が行われた場合は、リソースサービス連携アプリケーションがリソース取得リクエストを生成しリソースサービス２１０に対してリクエストを行う。本実施例ではリソース取得リクエストは、リソースサーバー連携アプリケーション以外からを想定しているため、Ｗｅｂブラウザ１２００を例に説明するが、Ｗｅｂブラウザに相当するリソースサービス２１０のＷｅｂＡＰＩを利用するアプリケーション等であってもよく、特に限定はしない。リソースサービス連携アプリケーション４００は、リソースサーバー２１０に対するリソース取得リクエストを受け付けると、リソース取得リクエストに含まれるリクエスト先と自身が保持しているリクエスト先（ホスト名１９２７、サービスＵＲＬ１９２８）を照合する（Ｓ４．５）。ここで、リクエスト先が合致しない場合は、以降の子トークン取得処理は行わずにリソース取得リクエストに含まれるリクエスト先に対して通信を行う。合致した場合は前述の子トークン取得処理（Ｓ２．４−Ｓ２．１３）の処理を行い、該子トークンを用いてリソースサービス２１０にリソース取得要求を行う。リソースサービス２１０がリソース取得要求を受けた際の処理は、Ｓ２．１５−Ｓ２．２１と同様の処理を行う。

本実施の形態によれば、リソースサービス連携アプリケーションが保持しているサービスへのリクエスト時にのみ子トークンが用いられ、不正なサービスが指定された際にトークンが漏えいすることを防止することが可能となる。

２００ 認可サーバー
２１０ リソースサーバー
３００ 画像形成装置
４００ リソースサーバー連携アプリケーション
５００ 認可サーバー連携クライアント
８００ アプリケーション管理フレームワーク
９００ Ｗｅｂブラウザ
１０００ ログインアプリケーション

Claims (2)

1. 複数のアプリケーションを追加可能な画像形成装置（３００）であって、
   第一のアプリケーション（４００）は、画像形成装置（３００）を認証するための認証情報を保持する手段（１６００）と、
   認可サーバー（２００）から第一の認可トークンを取得する手段（Ｓ１．４、Ｓ１．１０）と、
   前記第一の認可トークンを保持する手段（１７００）と、を備え、
   第二のアプリケーション（５００）は、リソースサーバー（２１０）にアクセスするための第二の認可トークン取得要求を第一のアプリケーションに送信する手段（Ｓ２．５）と、
   第一のアプリケーション（４００）は、第二の認可トークン取得要求元を識別するための第二のアプリケーション識別子を取得する手段（Ｓ２．６）と、
   前記第一の認可トークンと前記認証情報および、前記アプリケーションＩＤを用いて第二の認可トークンの取得を要求する手段（Ｓ２．１１）と、
   前記第二の認可トークンを、前記第二のアプリケーション（５００）に応答する手段（Ｓ２．１３）と、
   前記第二のアプリケーション（５００）は、要求先のリソースサーバーの宛先情報（１９２９）を保持する手段と、
   前記第二のアプリケーション（５００）は、リソース要求先が前記リソースサーバーの宛先情報と合致するかどうか判断する手段（Ｓ４．５）と、
   前記第二のアプリケーション（５００）は、リソース要求先が前記リソースサーバーの宛先情報と合致した場合は、前記リソースサーバー（２１０）に前記第二の認可トークンを用いてリソース要求する手段（Ｓ２．１４）と、を備え、
   さらに前記リソースサーバー（２１０）は、第二の認可トークンからリソース要求元の識別するためのアプリケーション識別子を取得する手段（Ｓ２．１８）と、を備える。
2. 請求項１記載のリソースサーバー（２１０）は、第二の認可トークンから取得した情報を元にリソースアクセスの可否を判断する手段（Ｓ２．１５、Ｓ２．１８）と、を備える。