(57)【要約】      （修正有）【課題】サービスが依存する認証サーバーが別のシステムに変わった場合、ユーザーに再度認可操作を求めることなく認可トークンを自動更新する。【解決手段】旧認証システムで発行した認可トークンが認証した顧客ユーザーに関連づいて存在しＳ１２０６、認証した顧客ユーザーが旧認可トークンを発行した発行者と同一でありＳ１２０７、新認証システムで発行する認可トークンの権限が旧認可トークン発行時以下でありＳ１２０８、新認証システムで発行する認可トークンの移譲先のサービスプロバイダーが旧認可トークン発行時と同じであると判断した場合、ユーザー認証したユーザーの権限を使用して新認証システムでの認可トークンを発行するＳ１２１０。【選択図】図１２
2016224684.tif 000002
【特許請求の範囲】
【請求項１】
外部サービスを利用することで所定のサービスを提供することが可能なサービスプロバイダーを備えたサーバーシステムであって、
クライアントに表示された認可確認画面を介し、前記外部サービスに対するユーザーの権限を前記サーバーシステムへ移譲するための認可操作を前記ユーザーが行ったことに応じて認可情報を発行する発行手段と、
認可情報を保存する保存手段と、
前記保存手段により保存された認可情報を使用し前記ユーザーの認証情報を用いずに前記外部サービスを利用し、前記所定のサービスを提供する提供手段と、
前記保存手段により保存された認可情報が前記サーバーシステムとは異なる別のサーバーシステムにおいて発行された旧認可情報である場合、前記旧認可情報を基に特定された認可に関する情報が条件を満たすことに応じて、前記旧認可情報を新たな認可情報に更新させる更新手段と、を有するサーバーシステム。
【請求項２】
前記条件とは、前記旧認可情報を基に特定された前記旧認可情報の発行者が、ユーザー認証されたユーザーと同一である第１の状態であるか否かを指すことを特徴とする請求項１に記載のサーバーシステム。
【請求項３】
前記条件とは、前記旧認可情報を基に特定された前記旧認可情報が示す移譲された権限の範囲が、新たな認可情報が示す移譲された権限の範囲よりも狭い第２の状態であるか否かを指すことを特徴とする請求項１に記載のサーバーシステム。
【請求項４】
前記条件とは、前記旧認可情報を基に特定された前記旧認可情報が示す権限の移譲先が、新たな認可情報が示す権限の移譲先と同一である第３の状態であるか否かを指すことを特徴とする請求項１に記載のサーバーシステム。
【請求項５】
前記更新手段は、請求項２乃至４の何れか1項に記載の前記条件の内、少なくとも何れか１つの条件を確認し、確認された全ての条件を満たすことに応じて、前記旧認可情報を新たな認可情報に更新させることを特徴とするサーバーシステム。
【請求項６】
前記旧認可情報を基に特定した認可に関する情報が条件を満たすことに応じて、前記発行手段が前記認可確認画面を前記クライアントに表示させることなく、前記更新手段は前記発行手段に認可情報を発行させ、発行された認可情報を基に、前記旧認可情報を新たな認可情報に更新させることを特徴とする請求項１乃至５の何れか１項に記載のサーバーシステム。
【請求項７】
前記旧認可情報を基に特定した認可に関する情報が条件を満たさないことに応じて、前記発行手段が前記認可確認画面を前記クライアントに表示させ、前記更新手段は再び認可操作を前記ユーザーが行ったことに応じて前記発行手段により発行された認可情報を基に、前記旧認可情報を新たな認可情報に更新させることを特徴とする請求項１乃至６の何れか１項に記載のサーバーシステム。
【請求項８】
前記更新手段による更新とは、前記保存手段に対し、前記旧認可情報を破棄させ、代わりに前記新たな認可情報を保存させる処理を指すことを特徴とする請求項１乃至７の何れか１項に記載のサーバーシステム。
【請求項９】
前記更新手段による更新が行われている際は、前記旧認可情報を新たな認可情報に自動的に更新している旨を示す更新画面を前記クライアントに表示させることを特徴とする請求項１乃至８の何れか１項に記載のサーバーシステム。
【請求項１０】
外部サービスを利用することで所定のサービスを提供することが可能なサービスプロバイダーを備えたサーバーシステムを制御する方法であって、
クライアントに表示された認可確認画面を介し、前記外部サービスに対するユーザーの権限を前記サーバーシステムへ移譲するための認可操作を前記ユーザーが行ったことに応じて認可情報を発行させる発行ステップと、
認可情報を保存する保存ステップと、
前記保存ステップにおいて保存された認可情報を使用し前記ユーザーの認証情報を用いずに前記外部サービスを利用し、前記所定のサービスを提供する提供ステップと、
前記保存ステップにおいて保存された認可情報が前記サーバーシステムとは異なる別のサーバーシステムにおいて発行された旧認可情報である場合、前記旧認可情報を基に特定された認可に関する情報が条件を満たすことに応じて、前記旧認可情報を新たな認可情報に更新させる更新ステップと、を含む方法。
【請求項１１】
請求項１０に記載の方法をコンピューターに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認可情報を基にサービスを提供するサーバーシステム、サーバーシステムの制御方法、およびプログラムに関するものである。
【背景技術】
【０００２】
近年、クラウドが一般化するに伴い、複数のサービスを連携させて付加価値を創造する機会が増加している。複数のサービスを連携する場合、各サービスが有するユーザーの情報やサービスの機能を、安全かつ容易に連携可能な仕組みが必要となる。
【０００３】
このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈによれば、例えばあるサービスＡが管理するユーザーのデータに、そのユーザーから認められた外部サービスＢがアクセスすることができる。このときサービスＡは、外部サービスＢからアクセスされる範囲を明らかにした上で、外部サービスＢによるアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを“認可操作”と称する。
【０００４】
ユーザーが認可操作を行うと、外部サービスＢはサービスＡからアクセスを認められたことを証明するトークン（以下、“認可トークン”と称する）を受け取り、以降のアクセスはその認可トークンを用いて実現できる。そして、認可トークンを用いると外部サービスＢは、ユーザーの認証情報なしに、認可を行ったユーザーの権限でサービスＡにアクセスできる。
【０００５】
また、特許文献１には、認可情報の一例である認証トークンを使用してプリントサービスを利用する方法と、プリント指示してから実際に印刷するまでに認証トークンの有効期限が切れないように、一定間隔で認証トークンの有効期限を更新する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１３−３３４３７
【非特許文献】
【０００７】
【非特許文献１】Ｄ．  Ｈａｒｄｔ、“Ｔｈｅ  ＯＡｕｔｈ  ２．０  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ”、２０１５年５月８日検索、インターネット＜ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７４９＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
先行技術では、サービスが依存する認証サーバーが別のシステムに変わった場合、旧認証システムで発行した認可情報は使用することができず、再度ユーザーに認可操作を行ってもらう必要がある。認可してもらうユーザーの権限が変わらないにも関わらず、再度ユーザーに認可操作を求めることは難しい場合がある。
【０００９】
本発明は上述した課題を解決することを目的とし、認可トークンを自動更新する新たな方法を提供する。
【課題を解決するための手段】
【００１０】
本願発明の一実施形に係るサーバーシステムは、外部サービスを利用することで所定のサービスを提供することが可能なサービスプロバイダーを備えたサーバーシステムであって、クライアントに表示された認可確認画面を介し、前記外部サービスに対するユーザーの権限を前記サーバーシステムへ移譲するための認可操作を前記ユーザーが行ったことに応じて認可情報を発行する発行手段と、認可情報を保存する保存手段と、前記保存手段により保存された認可情報を使用し前記ユーザーの認証情報を用いずに前記外部サービスを利用し、前記所定のサービスを提供する提供手段と、前記保存手段により保存された認可情報が前記サーバーシステムとは異なる別のサーバーシステムにおいて発行された旧認可情報である場合、前記旧認可情報を基に特定された認可に関する情報が条件を満たすことに応じて、前記旧認可情報を新たな認可情報に更新させることを特徴とする。
【発明の効果】
【００１１】
ユーザーに再度認可操作を求めることなく、新しい認認可トークンに更新することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】ネットワーク構成を示す図である。
【図２】実施例におけるサービス内容を説明した図である。
【図３】情報処理装置のハードウェア構成を示す図である。
【図４】画像形成装置のハードウェア構成を示す図である。
【図５】アプリケーションサーバーのソフトウェア構成を示す図である。
【図６】アクセス権管理部が管理するデータ構造図の一例である。
【図７】画像形成装置のソフトウェア構成を示す図である。
【図８】認証サーバーのソフトウェア構成を示す図である。
【図９】外部アプリケーションサーバー１０２のソフトウェア構成を示す図である。
【図１０】認可画面表示部の画面例である。
【図１１】認可トークン管理部が管理するデータ構造図の一例である。
【図１２】認可トークン自動更新の判断における処理フローチャートである。
【図１３】認証画面の画面例である。
【図１４】認可トークン自動更新の画面例である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための形態について図面を用いて説明する。
【００１４】
＜実施例１＞
実施例１におけるシステムを構成している各装置について、図１を参照して説明する。図１には、アプリケーションサーバー１０１、外部アプリケーションサーバー１０２、認証サーバー１０３、クライアントＰＣ１０４、画像形成装置１０５がネットワーク１０６を介して接続されている。
【００１５】
アプリケーションサーバー１０１は、ネットワーク１０６を介してユーザーにサービスを提供する情報処理装置である。外部アプリケーションサーバー１０２は、ネットワーク１０６を介したクライアントＰＣ１０４あるいはアプリケーションサーバー１０１からのリクエストに応じて、外部サービスを提供する情報処理装置である。本実施例では、ユーザーに対して直接サービスを提供するものをアプリケーションサーバー１０１と称し、アプリケーションサーバー１０１が連携して間接的にサービスを提供するものを外部アプリケーションサーバー１０２と呼ぶ。ただし、上記の構成に限定するものではなく、クライアントＰＣ１０４上のアプリケーションが連携して、外部アプリケーションサーバー１０２からサービスを提供される構成でもよいことは、当業者には明白であろう。
【００１６】
認証サーバー１０３は、所定のユーザーの認証情報及び認可情報を管理する情報処理装置である。本実施例では、外部アプリケーションサーバー１０２と認証サーバー１０３を別の装置としているが、１台の装置に両方の機能を搭載していても良い。なお、これらサーバーは１台で構成されているモノとして本実施例では説明するが、各サーバーが複数台から構成されていても良ので、便宜上サーバーシステムと称する。サーバーシステムと記載された場合は、１台または複数台のサーバーで構成されたサーバーを示す。
【００１７】
クライアントＰＣ１０４は、ネットワーク１０６を介してアプリケーションサーバー１０１のサービスを利用する際に使用されるパーソナルコンピューターやモバイル端末などの情報処理装置である。画像形成装置１０５はＭＦＰ（Ｍｕｌｔｉ  Ｆｕｎｃｔｉｏｎ  Ｐｅｒｉｐｈｅｒａｌ）に代表される情報処理端末である。本実施例では、図２で後述するようにアプリケーションサーバー１０１が提供するサービス例として画像形成装置１０５を使用するが、アプリケーションサーバー１０１の提供するサービスによっては必ずしも必要ない。ネットワーク１０６は、上述の各装置の間で情報をやり取りするための通信回線であり、インターネット、イントラネットの種別や、有線・無線は問わない。
【００１８】
図２は、本実施におけるアプリケーションサーバー１０１が提供するサービスを図式化したものである。本実施例は、サービスプロバイダーが顧客の画像形成装置１０５の管理業務を、アプリケーションサーバー１０１を使用してアウトソーシングで行うサービス例である。アプリケーションサーバー１０１は、顧客の画像形成装置２０１の稼働情報を収集し、顧客毎に管理された領域２０２で管理する。サービスプロバイダー２０３は、適切にアクセス管理された顧客の稼働情報にアクセスし、画像形成装置２０１の管理業務をサービスとして提供する。サービスプロバイダーは、アプリケーションサーバー１０１とは別の外部アプリケーションサーバー１０２が提供する機能や顧客の情報２０４を使用してサービスを提供する場合もある。例えば、カレンダーサービスに登録された顧客のスケジュールに合わせて管理業務を設定する他、レポートサービスに登録された顧客のテンプレートを使用して管理レポートを作成する場合である。この場合、予め顧客のユーザーの認可操作により発行された認可トークンを、許可されたサービスプロバイダーが使用して外部アプリケーションサーバー１０２にリクエストを送信する。
【００１９】
本実施例では、外部アプリケーションサーバー１０２の一例として、レポート生成機能を持つレポートサービスを例示する。アウトソーシングサービスは、保存している認可情報を使用することでレポートサービスを利用する際に必要となるユーザーの認証情報を用いずにレポートサービスを利用し、アウトソーシングサービスをユーザーに提供するのである。また、顧客のユーザーに代わりアウトソーシングサービスを管理する別のユーザーがアウトソーシングサービスの利用を開始するものである。
【００２０】
なお、その認可トークンの表現形式は実施例にとらわれることはなく、顧客のユーザーの権限がサービス（本実施例の場合はレポートサービスが該当する）に移譲されたことを示すデータであればどのような形式でも良い。認可トークンを含むそのようなデータを認可情報と称する。なお、ここで留意すべきは、ユーザーがサービスを利用するための認証時に入力するユーザーＩＤおよび／またはパスワードは認証情報であって認可情報ではない点であり、両者は全く異なるものとして認識されなければならない。
【００２１】
図２のようなアウトソーシングサービスの場合、サービスプロバイダーは顧客のユーザーの手間をできるだけ省きたいと考える。そのため、顧客から認可される権限が変わらないにも関わらず、認証システムが変わったために顧客のユーザーに再度認可操作を行ってもらうという操作を省きたい。
【００２２】
次に、システムを構成する各装置のハードウェア構成について説明する。
【００２３】
図３は、アプリケーションサーバー１０１、外部アプリケーションサーバー１０２、認証サーバー１０３、クライアントＰＣ１０４のハードウェア構成を示す図である。３０１は、ＣＰＵであり、各種プログラムを実行し、さまざまな機能を実現するユニットである。メモリ３０２は、各種情報を一時的に記憶するユニットであり、ハードディスク３０３に記憶されているプログラムをメモリ３０２にロードしプログラムを実行する。また、メモリは、ＣＰＵ３０１の一時的な作業記憶領域としても利用されるユニットである。ハードディスク３０３は、各種データを記憶するユニットであり、フラッシュメモリなどの同機能を持つ他のハードウェアでもよい。ユーザーインターフェース３０４は、ユーザーからの処理依頼を受け付ける他、ユーザーに対して画面を出力するためのユニットである。ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）３０５は、デバイス管理サーバー１０１、クライアント端末１０４をネットワークに接続するためのユニットであり、ＮＩＣ３０５を使用してネットワーク１０６に接続可能である。図３は代表的なハードウェア構成であり、この構成に限定しないことは当業者には明白であろう。
【００２４】
図４は、画像形成装置１０５のハードウェア構成を示す図である。画像形成装置は、画像処理ユニット４０１、印刷ユニット４０２、および読み込みユニット４０３から構成される。画像形成装置１０５が複合機ではない場合は、読み込みユニット４０３が存在しない構成であってもよい。画像処理ユニット４０１は、ＣＰＵ４０４、メモリ４０５、ハードディスク４０６、ユーザーインターフェース４０７から構成されている。４０４はＣＰＵであり、各種プログラムを実行し、さまざまな機能を実現するユニットである。メモリ４０５は、各種情報を一時的に記憶するユニットであり、ハードディスク４０６に記憶されているプログラムをメモリ４０５にロードしプログラムを実行する。また、メモリは、ＣＰＵ４０４の一時的な作業記憶領域としても利用されるユニットである。ハードディスク４０６は、各種データを記憶するユニットであり、フラッシュメモリなどの同機能を持つ他のハードウェアでもよい。ユーザーインターフェース４０７は、ユーザーからの処理依頼を受け付ける他、ユーザーに対して画面を出力するためのユニットである。ＮＩＣ４０８は、画像形成装置１０２をネットワーク１００に接続するためのユニットである。図２は、画像形成装置１０２の代表的なハードウェア構成であり、この構成に限定しないことは当業者には明白であろう。例えば、ＦＡＸボードや外部制御装置が接続されている構成であってもよい。
【００２５】
次に、システムを構成する各装置のソフトウェア構成について説明する。
【００２６】
図５は、アプリケーションサーバー１０１のソフトウェア構成を示している。各ソフトウェア構成の機能を実現するプログラムは、ハードディスク３０３に記憶されており、ＣＰＵ３０１がメモリ３０２にプログラムをロードし実行することで、これらの機能は実現される。
【００２７】
稼働情報管理部５０１は、画像形成装置１０５から受信した稼働情報を、画像形成装置を所有する顧客毎に管理する。稼働情報とは、ジョブの実行履歴、エラー発生情報、稼働情報、消耗品情報、設定情報、操作履歴、修理情報、問合せ情報など、画像形成装置１０５を利用することで発生する情報であり、特定の情報に限定しないことは当業者には明白であろう。
【００２８】
認可画面表示部５０２は、顧客のユーザーから外部アプリケーションサーバー１０２へのアクセスに対して認可操作を受けるために、アクセス範囲を認可確認画面により表示する。認可トークン発行依頼部５０３は、顧客のユーザーから認可操作を受けられた時に、認証サーバー１０３に対して認可トークンの発行を依頼する。認可トークンの発行方法について、ＯＡｕｔｈの中でもいくつかの方法が提唱されているが、発行方法を限定しないことは当業者には明白であろう。認可トークン管理部５０４は、発行された認可トークンを顧客毎に管理する。また、一般的に認可トークンは有効期限が短いため、認可トークン発行時に併せて発行されたリフレッシュトークンを使用して、有効期限が切れる前に認可トークンを更新してもよい。
【００２９】
アクセス権管理部５０５は、サービスプロバイダーが顧客のデータ２０２や発行された認可トークンを使用する際に、契約関係のある顧客のみアクセスが可能なように管理する。図６は、アクセス権管理部５０５が管理するデータ構造図の一例であり、顧客に対してアクセスが許可されたサービスプロバイダーを管理する。サービスプロバイダーのユーザーがアプリケーションサーバー１０１にユーザー認証すると、ユーザーが所属するサービスプロバイダーの情報から、アクセス可能な顧客を導き出す。図６はデータ構造の一例であり、これに限定しないことは当業者には明白であろう。
【００３０】
レポート生成依頼部５０６は、外部アプリケーションサーバー１０２に対してレポート生成を依頼する。レポート生成を依頼する際には、稼働情報管理部５０１で管理するデータと、認可トークン管理部５０４で管理する顧客ユーザーの認可トークンを併せて依頼する。認可トークン自動更新判断部５０７は、図１２で後述するが、認可トークンを発行した認証サーバー１０１が別の認証システムに変わった場合に、ユーザーが再度認可操作することなく新システムで認可トークンを再発行するかを判断する。
【００３１】
図７は、画像形成装置１０５のソフトウェア構成を示している。各ソフトウェア構成の機能を実現するプログラムは、ハードディスク４０６に記憶されており、ＣＰＵ４０４がメモリ４０５にプログラムをロードし実行することで、これらの機能は実現される。稼働情報保存部７０１は、前述した稼働情報を保存する。稼働情報送信部７０２は、保存した稼働情報をアプリケーションサーバー１０１に送信する。定期的に送信する方法、保存して即時に送信する方法、稼働情報が一定量以上蓄積された後に送信する方法などがあるが、特に限定しないことは当業者には明白であろう。また、稼働情報送信部７０２を持たない画像形成装置に対して、不図示の情報端末装置が稼働情報を収集してアプリケーションサーバー１０１に送信してもよい。
【００３２】
図８は、認証サーバー１０３のソフトウェア構成を示している。各ソフトウェア構成の機能を実現するプログラムは、ハードディスク３０３に記憶されており、ＣＰＵ３０１がメモリ３０２にプログラムをロードし実行することで、これらの機能は実現される。
【００３３】
認可トークン発行部８０１は、アプリケーションサーバー１０１からの認可トークンの発行依頼に対して、発行依頼を検証して認可トークンを発行する。認可トークン検証部８０２は、外部アプリケーションサーバー１０２から認可トークンの検証依頼に対して、認可トークンが正当なものかを検証する。認証部８０３は、アプリケーションサーバー１０１を使用するユーザーを、図１３で後述する認証画面で認証する。
【００３４】
サービス呼出管理部８０４は、認証部８０３で認証した後に、予め登録したＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を呼び出すためのものである。サービス呼出管理部８０４にアプリケーションサーバー１０１の認可トークン自動更新判断部５０７のＡＰＩを登録しておくことで、ユーザー認証直後に認可トークンの自動更新を判断することができる。
【００３５】
図９は、外部アプリケーションサーバー１０２のソフトウェア構成を示している。各ソフトウェア構成の機能を実現するプログラムは、ハードディスク３０３に記憶されており、ＣＰＵ３０１がメモリ３０２にプログラムをロードし実行することで、これらの機能は実現される。
【００３６】
リクエスト受付部９０１は、アプリケーションサーバー１０１からのレポート生成依頼を受け付ける。認可トークン検証依頼部９０２は、レポート生成依頼に添付された認可トークンが正当なものか、必要な権限があるかを、認証サーバー１０１に検証依頼する。レポート生成部９０３は、認可トークンが有効と判断された際に、レポート生成依頼に添付されたデータを使用してレポートを生成し、アプリケーションサーバー１０１に返信する。生成するレポートについては、ＰＤＦ、Ｗｏｒｄ、ＨＴＭＬ形式など、特に限定しないことは当業者には明白であろう。レポート保存部９０４は、アップロードされたレポートを外部アプリケーションサーバー１０２に保存する。
【００３７】
図１０は、顧客ユーザーが認可操作をする際に、アプリケーションサーバー１０１の認可画面表示部５０２が表示する、認可画面の例である。説明文表示部１００１は、顧客ユーザーに対して権限を認可してもらう目的を表示する。権限表示部１００２は、顧客ユーザーからアプリケーションサーバー１０１に認可してもらう権限を表示する。移譲先表示部１００３は、認可した顧客ユーザーの権限を使用するサービスプロバイダーを表示する。認可画面表示部５０２は、図６で先述したアクセス権管理部５０５が管理するデータを使って表示する。
【００３８】
同意ボタン１００４は、顧客ユーザーが表示された内容に同意し、認可を行うためのボタンである。同意ボタン１００４が押下されると、認可トークン発行依頼部５０３は権限表示部１００２に表示した権限で、認可トークンの発行を依頼する。また発行された認可トークンは、アクセス権管理部５０５を使用して、移譲先表示部１００３に表示したサービスプロバイダーのユーザーが利用する。また、認可画面は表示内容や操作を上記に限定しないことは、当業者には明白であろう。
【００３９】
同意する指示、即ち認可操作をユーザーが行ったことに応じて外部アプリケーションサーバー１０２における顧客ユーザーの権限がアプリケーションサーバー１０１に移譲され、発行された認可トークンはその権限が移譲されたことを示す識別情報となる。
【００４０】
図１１は、アプリケーションサーバー１０１の認可トークン管理部５０４が管理するデータ構造図の一例であり、顧客ごとに発行された認可トークンを管理する。顧客ＩＤ１１０１は顧客を一意に表す情報であり、本実施例では顧客ごとに認可トークンを管理する。認可トークンの管理単位を顧客に限定しないことは当業者には明白であろう。
【００４１】
認可トークン１１０２は、認証サーバー１０３から発行された認可トークンを保存する。本実施例では、認可トークンは文字列で発行されている。リフレッシュトークン１１０３は、認証サーバー１０３から認可トークン発行時に一緒に発行されたリフレッシュトークンを保存する。アプリケーションサーバー１０１は、認可トークンの有効期限が切れた時に、リフレッシュトークンを使って有効期限が延長された認可トークンを取得することができる。
【００４２】
旧認可トークン発行フラグ１１０４は、アプリケーションサーバー１０１が依存する認証サーバー１０３が古い認証システムだった時に、顧客のユーザーが認可トークンを発行したかを表すフラグである。本フラグは、アプリケーションサーバー１０１が依存する認証システムを切り替える際に、既に古い認証システムで認可トークンを発行済みだった顧客に対してフラグを“有”に設定する。旧認可トークンとは旧認可情報の一種である。データ構造を上記に限定しないことは、当業者には明白であろう。例えば、旧認可トークン発行フラグ１１０４は、フラグという形でなくても古い認証システムでトークンが発行済であったかを判断できればよい。
【００４３】
図１２は、認証サーバー１０１が別のシステムに変わった場合に、アプリケーションサーバー１０１の認可トークン自動更新判断部５０７が、ユーザーが再度認可操作することなく新システムで認可トークンを発行するかを判断する際の処理フローチャートである。以下の処理は、図５と図８に示したアプリケーションサーバー１０１と認証サーバー１０３のソフトウェア構成において、各々のメモリ３０２、ハードディスク３０３のいずれかの記憶手段に記憶され、ＣＰＵ３０１により実行される。
【００４４】
最初にＳ１２０１で、認証サーバー１０３の認証部８０３は、図１３の認証画面を顧客のユーザーのクライアントＰＣ１０１上に表示させる。認証部８０３は認証画面で入力された顧客ユーザーの認証情報を使用して、ユーザー認証する。Ｓ１２０２でユーザー認証に失敗した場合、認証サーバー１０３の認証部８０３は、Ｓ１２０３で認証が失敗したことをユーザーに示す。一方、Ｓ１２０２でユーザー認証に成功した場合、Ｓ１２０４で認証サーバー１０３のサービス呼出管理部８０４は認証後に呼び出すＡＰＩが登録されているかを確認し、登録されている場合はＡＰＩを呼び出す。本実施例では、アプリケーションサーバー１０１の認可トークン自動更新判断部５０７のＡＰＩを呼び出す。また、認可トークン自動更新判断部５０７のＡＰＩを呼び出す別の方法として、認証画面のＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）にリダイレクト先として、認可トークン自動更新判断部５０７のＵＲＬを指定してもよい。リダイレクト先として指定した場合は、Ｗｅｂブラウザーの機能で認可トークン自動更新判断部５０７のＵＲＬを呼び出すため、認証サーバー１０３にサービス呼出管理部８０４がなくてもよい。
【００４５】
Ｓ１２０５で、アプリケーションサーバー１０１の認可トークン自動更新判断部５０７は、図１１で先述した認可トークン管理部５０４を使用して、認証した顧客ユーザーに関連づいて、新認証システムで発行した認可トークンが存在するかを確認する。認可トークン自動更新判断部５０７は、後述するＳ１２１０、もしくはＳ１２１２で新認証システムの認可トークンが発行済みの場合、以降の判断処理を行わず終了する。
【００４６】
次にＳ１２０６で、アプリケーションサーバー１０１の認可トークン自動更新判断部５０７は、図１１で先述した認可トークン管理部５０４を使用して、認証した顧客ユーザーに関連づいて、旧認証システムで発行した認可トークンが存在するかを確認する。認可トークンが存在する場合は、自動更新候補と判断する。
【００４７】
次にＳ１２０７で、認可トークン自動更新判断部５０７は、認証した顧客ユーザーが旧認可トークンを発行した発行者と同一であるかを判断し、同一であれば自動更新候補とする。本実施例では、顧客の管理者権限のように、認可トークンを発行するために顧客ユーザーに必要な特別なロールが存在するか否かで判断する。別の方法として、図１１で旧認可トークンの発行有無だけではなく旧認可トークンを発行したユーザーを特定する情報を記録しておき、認証した顧客ユーザーが等しいか否かで判断してもよい。Ｓ１２０７により、自動更新の際に、旧認証システムで認可操作したユーザーと、同一であるかをチェックしている。
【００４８】
次にＳ１２０８で、認可トークン自動更新判断部５０７は、新認証システムで発行する認可トークンの権限が旧認可トークン発行時以下であるかを判断し、権限が旧認可トークン発行時以下の場合は自動更新候補とする。新認証システムで発行する認可トークンの権限が旧認可トークン発行時以下というのは、旧認可トークンが示すユーザーから移譲された権限の範囲よりも狭いということを意味する。以下、具体例の説明となる。認証システムが変わってもアプリケーションサーバー１０１が外部アプリケーションサーバー１０２に対して必要な権限が変わらない場合は、旧認可トークンが存在することで権限が同じと判断する。また、アプリケーションサーバー１０１が外部アプリケーションサーバー１０２に対して必要な権限が小さくなる場合も、既に顧客ユーザーから認可されたアクセス範囲と判断し、自動更新候補とする。例えば旧認証システムではレポートの作成権限とレポートの保存権限が必要だったのに対し、新システムではレポートの作成権限だけ必要な場合などである。また、必要な権限が顧客毎に変わるような場合は、図１１で旧認可トークンの発行有無だけではなく、認可された権限を記録しておき、新システムで発行する権限と比較してもよい。Ｓ１２０８により、自動更新の際に、旧認証システムで認可した権限を超える認可トークンを自動更新しないかをチェックしている。
【００４９】
次にＳ１２０９で、認可トークン自動更新判断部５０７は、新認証システムで発行する認可トークンの移譲先のサービスプロバイダーが、旧認可トークン発行時と同じであるかを判断し、同じ場合は自動更新候補とする。認証システムが変わってもサービスプロバイダーと顧客間のアクセス関係が変わらない場合は、旧認可トークンが存在することで移譲先が同じであると判断する。また、アクセス関係が変わる場合は、図１１で旧認可トークンの発行有無だけではなく、許可された移譲先のサービスプロバイダーも記録しておき、新システムでの移譲先と比較してもよい。Ｓ１２０９により、旧認証システムで認可された移譲先以外で使用可能な認可トークンを自動更新しないかをチェックしている。
【００５０】
認可トークン自動更新判断部５０７が、Ｓ１２０６〜Ｓ１２０９のすべてで自動更新候補と判断した場合、Ｓ１２１０で認可トークン発行依頼部５０３は、ユーザー認証したユーザーの権限を使用して、新認証システムでの認可トークンを発行する。その際、図１０の認可画面を表示せず、図１４の認可トークン自動更新画面を表示させ、自動的に更新を行う。なお、本実施例における更新処理の１実施形態は、旧認可トークンをメモリ上から破棄し、新たな認可トークンを保存させる処理である。
【００５１】
一方、Ｓ１２０６〜Ｓ１２０９のいずれかで自動更新候補ではないと判断した場合、Ｓ１２１１で認可画面表示部５０２は図１０の認可画面を表示する。Ｓ１２１２でユーザーから認可操作が行われると、Ｓ１２１３で認可トークン発行依頼部５０３は顧客ユーザーの権限を使用して新認証システムでの認可トークンを発行する。このとき、認可画面表示部５０２は自動更新候補ではないと判断した条件から、過去に認可操作した時の認可画面と差異がある部分だけ認可画面に表示してもよい。
【００５２】
上記の手順により、認証システムが変わった場合にも旧認証システムで認可された権限の範囲であれば、ユーザーが認可画面を確認して認可操作する、という手間を軽減して新認証システムでの認可トークンを発行することができる。一方で、旧認証システムで認可された権限の範囲外であれば、認可画面を表示して、ユーザーに明示的に認可された権限で認可トークンを発行できる。Ｓ１２０６〜Ｓ１２０９の各手順で記載した状態を判断する方法は、上記に限定しないことは当業者には明白であろう。即ち、少なくとも１つの判断ステップをもって自動更新を行っても良いし、判断ステップの順番についても規定はない。例えば、Ｓ１２０６の判断ステップの前にＳ１２０７の判断を行っても良い。
【００５３】
また、アプリケーションサーバー１０１は、新認可トークンの有無判断Ｓ１２０５を持つ代わりに、新認証システムで認可トークンが発行された顧客は、認証サーバー１０３のサービス呼出管理部８０４から登録削除してもよい。これにより新認証システムで認可トークンを発行済の顧客は、ユーザー認証時に認可トークン自動更新判断部５０７の判断処理をしなくてよいため、ユーザー認証の性能が向上する。
【００５４】
＜その他の実施例＞
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００５５】
１０１  アプリケーションサーバー
１０２  外部アプリケーションサーバー
１０３  認証サーバー
１０４  クライアントＰＣ
１０５  画像形成装置
１０６  ネットワーク
【図１】
2016224684.tif 000003
【図２】
2016224684.tif 000004
【図３】
2016224684.tif 000005
【図４】
2016224684.tif 000006
【図５】
2016224684.tif 000007
【図６】
2016224684.tif 000008
【図７】
2016224684.tif 000009
【図８】
2016224684.tif 000010
【図９】
2016224684.tif 000011
【図１０】
2016224684.tif 000012
【図１１】
2016224684.tif 000013
【図１２】
2016224684.tif 000014
【図１３】
2016224684.tif 000015
【図１４】
2016224684.tif 000016