JP2015228067A

JP2015228067A - 権限移譲システム、方法、認証サーバーシステム、およびそのプログラム

Info

Publication number: JP2015228067A
Application number: JP2014112626A
Authority: JP
Inventors: 存田村; Tamotsu Tamura
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2014-05-30
Filing date: 2014-05-30
Publication date: 2015-12-17
Anticipated expiration: 2034-05-30
Also published as: US20150350209A1; EP2978185A1; JP6157411B2; CN105323237A; EP2978185B1; US9967253B2; CN105323237B

Abstract

【課題】ワンユーザー・マルチデバイスにおける端末利用の利便性を向上させるための権限移譲システムを提供する。【解決手段】認可モジュール３０４は、クライアントモジュール３５１からアクセストークンの要求を受け付ける。クライアント識別子管理モジュール３０３は、受け付けたアクセストークンの要求に含まれるクライアント識別子とユーザー情報が紐付けられているか、クライアント識別子紐付けテーブルをもとに判断する。ユーザーに紐付けられたクライアント識別子の内、いずれかでアクセストークンを発行しているか判断する。ユーザーに紐付けられたいずれかのクライアント識別子でアクセストークンを発行していると判断された場合は、ユーザーに認可の確認を求めることなくアクセストークンを発行する。発行していないと判断された場合は要求に含まれるクライアント識別子とユーザー情報に紐付けてアクセストークンテーブルで記憶する。【選択図】図３

Description

ユーザーの権限をクライアントへ移譲することが可能な権限移譲システム、方法、認証サーバーシステム、およびそのプログラムに関する。

クラウドが一般化するに伴い、複数のサービスを連携させる機会はますます増加している。サービスとは、インターネット等のネットワークを介して接続されたサーバーが提供する機能、換言すれば、ウェブアプリケーションのことを指す。サービスを連携させることでサービス提供者は、ユーザーに通常のサービスに付加価値を加えた新たなサービスを提供することができる。その一方で、サービスが連携することにより、いくつかの課題が生まれる。

すなわち、ユーザーが望んだ以上の情報がサービス間でやりとりされる虞があり、ユーザーデータや個人情報に関する情報の流出という課題がある。たとえばインターネット上には複数のサービスが存在し、様々なサービス間でサービス連携が実現される可能性があるが、ユーザーが認識したサービス以外がユーザーデータや個人情報を操作できてはいけない。またサービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。

このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈによれば、たとえばある端末内のアプリケーションからクラウドサービスが管理するデータにアクセスする場合は、アプリケーションはユーザーの明示的な認可を得ることになっている。

ユーザーが認可すると、アプリケーションはアクセスを認められたことを証明するトークン（以下、アクセストークン）を受け取り、以降のアクセスはそのアクセストークンを用いて実現できる。以下では、アクセストークンの発行のための操作を認可操作と称する。たとえば特許文献１において、ＯＡｕｔｈを利用したアクセストークンを発行する技術が開示されている。

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

近年、スマートフォンの普及により、一人で複数の端末を所有するケースが増えている。ここでは、一人で複数の端末を所有する状態のことをワンユーザー・マルチデバイスと称する。このようなワンユーザー・マルチデバイスの時代においては、ユーザーが所有する複数の端末の内、どの端末を使っているかを意識せずにシームレスに端末を使用したいという要望が高まると予想される。

例えば、複数の端末の夫々において、クラウドサービスが管理するデータにアクセスするためのアプリケーションがインストールされていたとする。アプリケーションがユーザーの認証情報を用いずにデータにアクセスするためには、例えば、ＯＡｕｔｈで言うアクセストークンが必要であり、またアクセストークンの発行には認可操作が必要になる。

アクセストークンの発行処理に対して従来の発行処理を採用した場合、ユーザーが所有する端末ごとに個別に認可操作を行う必要が発生する。これは、どの端末では認可操作が済んでいて、どの端末では認可操作が済んでいないかをユーザーが意識することになり兼ねず、シームレスに端末が使用できるとは十分に言い切れない。その結果としてワンユーザー・マルチデバイスにおける端末利用の利便性が低下するという問題があった。

本発明は前述の課題をかんがみてなされたものであり、その目的の１つは、ワンユーザー・マルチデバイスにおける端末利用の利便性を向上させるための権限移譲システムの実現である。

本発明の一実施例に係る権限移譲システムは、クライアントから利用可能なサービスを備えるサーバーシステムと、第１のクライアントと、第２のクライアントと、認証サーバーシステムとを含む権限移譲システムであって、前記第１のクライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断する認証手段と、前記認証手段により正規のユーザーであると判断された前記ユーザーが前記第１のクライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記第１のクライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記第１のクライアントへ移譲されたことを示す権限情報を発行する発行手段と、前記第１のクライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記第１のクライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可手段と、前記認証手段により正規のユーザーであると判断された前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理する管理手段と、を有し、前記発行手段は、前記ユーザーの識別子と前記第２のクライアントの識別子とが紐付けられている場合、前記サービスにおける前記ユーザーの権限を前記第２のクライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記第２のクライアントへ移譲されたことを示す権限情報を発行することを特徴とする。

本発明の効果の１つは、ワンユーザー・マルチデバイスにおける端末利用の利便性を向上させるための権限移譲システムの実現である。

ネットワーク構成を示す図である。本発明の実施の形態に係るサーバーコンピューターの構成図である。本実施の形態に係るモジュール構成図である。本実施の形態に係るクライアント識別子発行のフローである。本実施の形態に係るクライアントの開始およびログインのフローである。本実施の形態に係るクライアント識別子紐付け確認のフローである。本実施の形態に係るリソースに対するアクセスフローのフローである。本実施の形態に係る画面の表示例である。本実施の第２の形態に係るモジュール構成図である。本実施の第２の形態に係るフローである。本実施の第３の形態に係るモジュール構成図である。本実施の第３の形態に係る紐付け確認の要否設定のフローである。本実施の第３の形態に係る紐付け確認の要否判断のフローである。本実施の第３の形態に係る画面の表示例である。本実施の第４の形態に係るモジュール構成図である。本実施の第４の形態に係るクライアントの開始およびログインのフローである。本実施の第４の形態に係る画面の表示例である。

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

本実施の形態に係る権限移譲システムは、図１に示すような構成のネットワーク上に実現される。１００は、ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄＷｉｄｅＷｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ（ＬＡＮ１０１）である。１０２はモバイル端末が接続するワイヤレスネットワークである。

１５１はユーザーを認証およびアクセストークンの発行を行う認証・認可サーバー、１５２はリソースサーバーである。また１５３はデータベースサーバーである。また１９１および１９２はユーザーが操作するモバイル端末である。アクセストークンとは、クライアント、例えばアプリケーションが、ユーザーによりサービスの利用が許可されたことを証明する情報であり、ユーザーがアプリケーションに対してユーザーの権限を移譲することを許可する認可操作が行われることで発行される。例えば、クラウドサービスが管理するデータにアクセスするためのアクセストークンを用いると、アプリケーションは、ユーザーに許可された範囲でデータにアクセスできるようになる。なお、本実施例では英数字の羅列であるアクセストークンを例に説明するが、情報の表現は自由であるので、それらをまとめて権限情報と称する。

認証・認可サーバー１５１、リソースサーバー１５２、データベースサーバー１５３はそれぞれＷＡＮネットワーク１００およびＬＡＮ１０１を介して接続されている。また同様にモバイル端末１９２および１９２はＷＡＮネットワーク１００およびワイヤレスネットワーク１０２を介して接続されている。なお認証・認可サーバー１５１、リソースサーバー１５２、データベースサーバー１５３はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。またモバイル端末１９１および１９２の代わりに不図示のＰＣがＬＡＮ１０１を介してＷＡＮ１００に接続されていてもよい。更に、本実施例では何れのサーバーも１台として表現しているが複数台から構成されるサーバー群であっても良いので、サーバーシステムと称した場合は１台乃至は複数台から構成されるサーバーであるとする。例えば、認証サーバーシステムは、認証・認可サーバー１５１が１台乃至は複数台から構成される装置ということになる。

図２は本実施の形態に係る、認証・認可サーバー１５１のサーバーコンピューターの構成を示す図である。また、リソースサーバー１５２、およびデータベースサーバー１５３のサーバーコンピューターの構成やモバイル端末１９１、１９２の構成も同様である。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のサーバーコンピューターおよびモバイル端末には一般的な情報処理装置のハードウェア構成を適用できる。

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

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体はハードディスク（ＨＤ）２１１にインストールされたアプリケーションプログラムがＣＰＵ２０１により実行されたことで実現されるアプリケーションプログラムの機能ということになる。

図３は本実施の形態に係る、認証・認可サーバー１５１およびモバイル端末１９１、１９２のモジュール構成を示す図である。図３（Ａ）は認証・認可サーバー１５１、図３（Ｂ）および図３（Ｃ）はモバイル端末１９１および１９２のモジュール構成を、それぞれ示す。認証・認可サーバー１５１はクライアント識別子管理モジュール３０１、認証モジュール３０２、クライアント識別子紐付け管理モジュール３０３、認可モジュール３０４を持つ。またモバイル端末１９１および１９２はクライアントモジュール３５１、クライアント紐付け要求モジュール３５２を持つ。なお、図示していないがリソースサーバー１５１は、移譲されたユーザーの権限でサービスの利用が認可されたモバイル端末１９１、および／またはモバイル端末１９２が利用可能なサービスを備えている。サービスは、モバイル端末１９１、および／またはモバイル端末１９２から要求されたサービスの機能を実行することになる。

本明細書における権限移譲の流れは、図４（Ａ）および（Ｂ）におけるクライアント識別子の事前設定から始まる。そして、ユーザーはモバイル端末１９１または１９２の任意のモバイル端末を用いてリソースサーバー１５２へアクセスすることで図７（Ａ）の処理が始まり、図５（Ａ）および（Ｂ）のユーザーが認証画面を介して入力した認証情報が正規の情報であるか否かの検証が行われる。最後に、図６（Ａ）乃至（Ｃ）のユーザー識別子とクライアント識別子の紐付けが行われ、本発明の特徴の１つである図７（Ｂ）の処理が行われ、２台目以降のモバイル端末におけるユーザーの認可操作の負担を軽減することが可能になる。では、１つずつ説明していく。

図４（Ａ）は本実施の形態に係る、モバイル端末１９１もしくはモバイル端末１９２における、クライアント識別子発行要求フローである。本フローはユーザーがクライアントモジュール３５１を起動することで開始される。

ステップＳ４０１でクライアントモジュール３５１は、ユーザーの起動指示を受けて起動する。ステップＳ４０２でクライアントモジュール３５１は、認証・認可サーバー１５１にクライアント識別子発行を依頼する。ここでクライアント識別子発行の依頼には、事前にクライアントモジュール３５１に割り当てられたクライアント証明書が含まれる。ステップＳ４０３でクライアントモジュール３５１は、認証・認可サーバー１５１に発行されたクライアント識別子を受信し、フローを終了する。

図４（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１における、クライアント識別子発行フローである。本フローはクライアントモジュール３５１からのクライアント識別子発行依頼を受信することで開始される。

ステップＳ４１１でクライアント識別子管理モジュール３０１は、クライアントモジュール３５１からのクライアント識別子発行依頼を受信する。ステップＳ４１２でクライアント識別子管理モジュール３０１は、受信したクライアント識別子発行依頼に含まれるクライアント証明書を取り出す。ステップＳ４１３でクライアント識別子管理モジュール３０１は、ステップＳ４１２で取り出したクライアント証明書が妥当な証明書か判断する。ここでクライアント証明書が妥当と判断された場合はステップＳ４１４に遷移する。またクライアント証明書が妥当でないと判断された場合はステップＳ４５０に遷移する。

ステップＳ４１４でクライアント識別子管理モジュール３０１は、クライアントモジュール３５１からのクライアント識別子発行依頼に対し、クライアント識別子を発行する。なおここで発行されたクライアント識別子はクライアント識別子管理モジュール３０１が記憶する。表１はクライアント識別子テーブルであり、クライアント識別子管理モジュール３０１が記憶している発行済みクライアント識別子の様子を示す。ここではモバイル端末１９１のクライアントモジュール３５１に対しクライアント識別子ＡｐｐＡｍ００１が、モバイル端末１９２のクライアントモジュール３５１に対しクライアント識別子ＡｐｐＡｍ００２が、それぞれ発行されているとする。ここでそれぞれの端末におけるクライアントモジュール３５１に対して、それぞれ異なるクライアント識別子が発行される。

ステップＳ４１５でクライアント識別子管理モジュール３０１は、ステップＳ４１４で発行したクライアント識別子をクライアントモジュール３５１に返し、フローを終了する。ステップＳ４５０でクライアント識別子管理モジュール３０１は、クライアント識別子を発行できない旨をクライアントモジュール３５１に返し、フローを終了する。

図５（Ａ）は本実施の形態に係る、モバイル端末１９１もしくはモバイル端末１９２における、クライアントの開始フローである。本フローはユーザーがクライアントモジュール３５１を操作することで開始される。

ステップＳ５０１でクライアントモジュール３５１は、ステップＳ１１０３の応答として認証・認可サーバー１５１からログインを要求されたか判断する。ここでログインが要求されたと判断された場合はステップＳ５０２に遷移する。またログインが要求されなかったと判断された場合はステップＳ５０３に遷移する。

ステップＳ５０２でクライアントモジュール３５１は、認証・認可サーバー１５１からの要求に従い図８（Ａ）に示されるようなログイン画面１４０１を表示し、ユーザーに認証情報の入力を促す。またクライアントモジュール３５１は、ユーザーに入力された認証情報を認証・認可サーバー１５１に送信してログインする。ステップＳ５０３でクライアント紐付け要求モジュール３５２は、クライアント識別子紐付け確認を行う。なおクライアント識別子紐付け確認の詳細は後述する。

図５（Ｂ）は本実施の形態に係る、認証・認可サーバーにおけるログインフローである。本フローは認証・認可サーバー１５１がクライアントモジュール３５１からリソースへのアクセス要求を受信することで開始される。ステップＳ６０１で認証モジュール３０２は、クライアントモジュール３５１から、リソースサーバー１５２のリソースへのアクセス要求を受け付ける。ステップＳ６０２で認証モジュール３０２は、ステップＳ６０１に係るユーザーがログイン済みであるか判断する。ここでユーザーがログイン済みであると判断された場合はフローを終了する。またログイン済みでないと判断された場合はステップＳ６０３に遷移する。

ステップＳ６０３で認証モジュール３０２は、クライアントモジュール３５１に指示し、図８（Ａ）に示されるようなログイン画面１４０１を表示させる。ステップＳ６０４で認証モジュール３０２は、ログイン画面１４０１で入力された認証情報を受け付ける。ステップＳ６０５で認証モジュール３０２は、ステップＳ６０４で受け付けた認証情報が妥当か判断する。ここで認証情報が妥当であり、ユーザーが正規のユーザーであると判断された場合はステップＳ６０６に遷移する。また認証情報が妥当でないと判断された場合はステップＳ６５０に遷移する。ステップＳ６０６で認証モジュール３０２は、ユーザーのログインを許可し、フローを終了する。ステップＳ６５０で認証モジュール３０２は、ユーザーのログインを拒否し、フローを終了する。

図６（Ａ）は本実施の形態に係る、モバイル端末１９１もしくはモバイル端末１９２における、クライアント識別子紐付け確認のフローである。図５（Ａ）のステップＳ５０６の詳細フローである。

ステップＳ７０１でクライアント紐付け要求モジュール３５２は、認証・認可サーバー１５１にアクセスする。ここで認証・認可サーバー１５１へのアクセスには、モバイル端末を操作するユーザーの情報およびステップＳ４０３で受信したクライアント識別子を含む。ステップＳ７０２でクライアント紐付け要求モジュール３５２は、ステップＳ７０１の応答として、クライアント識別子の紐付けの確認を行うことを要求されたか判断する。ここで確認を要求されたと判断された場合はステップＳ７０３に遷移する。また確認を要求されなかったと判断された場合はクライアント識別子の紐付け要求を行わずにフローを終了する。

ステップＳ７０３でクライアント紐付け要求モジュール３５２は、認証・認可サーバー１５１の指示に従い、図８（Ｂ）に示されるようなクライアント紐付け確認画面を表示し、ユーザーにクライアント識別子を紐付けるかの確認を行う。ユーザーにクライアント識別子を紐づけるか否かを確認する処理を、クライアント識別子紐付けの確認処理と称する。ステップＳ７０４でクライアント紐付け要求モジュール３５２は、ステップＳ７０３の確認に対応して、ユーザーにクライアント識別子の紐付けをする指示があったかを判断する。ここで指示があったと判断された場合はステップＳ７０５に遷移する。また指示がなかったと判断された場合はクライアント識別子の紐付け要求を行わずにフローを終了する。

ステップＳ７０５でクライアント紐付け要求モジュール３５２は、認証・認可サーバー１５１にクライアント識別子紐付け要求を行う。ここでクライアント識別子紐付け要求は、モバイル端末を操作するユーザーの情報およびステップＳ４０３で受信したクライアント識別子を含む。クライアント識別子紐付け要求が完了するとフローを終了する。

図６（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１における、クライアント識別子紐付け要否判断のフローである。本フローは認証・認可サーバー１５１がクライアントモジュール３５１からのアクセスを受信することで開始される。Ｓ７０２における判断ステップは図６（Ｂ）の結果に基づくものである。ステップＳ８０１でクライアント識別子紐付け管理モジュール３０３は、クライアントモジュール３５１からのアクセスを受け付ける。ここで受け付けたアクセスには、ユーザーの情報およびクライアント識別子を含む。

ステップＳ８０２でクライアント識別子紐付け管理モジュール３０３は、ステップＳ８０１で受け付けたアクセスに含まれるユーザーの情報およびクライアント識別子から、クライアント識別子がユーザーに紐付け済みかを判断する。ここで紐付け済みと判断された場合はステップＳ８０３に遷移する。また紐付け済みでないと判断された場合はステップＳ８１０に遷移する。表２はクライアント識別子紐付けテーブルであり、クライアント識別子紐付け管理モジュール３０３が記憶しているユーザーとクライアント識別子の紐付けの様子を示す。ここではユーザーＵｓｅｒＸに対し、クライアント識別子ＡｐｐＡｍ００１およびＡｐｐＡｍ００２が紐付けられているとする。ここで、ステップＳ８０１で受け付けたユーザー情報およびクライアント識別子が、それぞれＵｓｅｒＸおよびＡｐｐＡｍ００１であった場合、ステップＳ８０２ではクライアント識別子がユーザーに紐付け済みであると判断される。

ステップＳ８０３でクライアント識別子紐付け管理モジュール３０３は、クライアント識別子がユーザーに紐付け済みであり、クライアント識別子の紐付け確認は不要である旨をクライアントモジュール３５１に返してフローを終了する。ステップＳ８１０でクライアント識別子紐付け管理モジュール３０３は、クライアントモジュール３５１に対してクライアント識別子紐付け確認を要求し、図８（Ｂ）に示すようなクライアント紐付け確認画面１４０２を表示させる。またクライアント識別子紐付け確認の要求が完了するとフローを終了する。

図６（Ｃ）は本実施の形態に係る、認証・認可サーバー１５１における、クライアント識別子の紐付けフローである。本フローは認証・認可サーバー１５１がクライアントモジュール３５１からクライアント識別子紐付け要求を受信したことで開始される。なお、本フローはＳ７０６の紐付け要求に応じて実行されるフローである。

ステップＳ９０１でクライアント識別子紐付け管理モジュール３０３は、クライアントモジュール３５１からクライアント識別子紐付け要求を受け付ける。ここで受け付けたクライアント識別子紐付け要求は、ユーザーの情報およびクライアント識別子を含む。ステップＳ９０２でクライアント識別子紐付け管理モジュール３０３は、ステップＳ９０１で受け付けた要求に含まれるクライアント識別子をユーザーに紐付けて、クライアント識別子紐付けテーブルに記憶する。紐付けの記憶が完了するとフローを終了する。以上が、ユーザーがモバイル端末１９１もしくはモバイル端末１９２の何れか１つを用いてリソースサーバー１５２に最初にアクセスする
図７（Ａ）は本実施の形態に係る、モバイル端末１９１もしくはモバイル端末１９２における、リソースサーバー１５２のリソースに対するアクセスフローである。本フローはクライアントモジュール３５１がユーザーから、リソースサーバー１５２のリソースに対するアクセス指示を受信することで開始される。

ステップＳ１００１でクライアントモジュール３５１は、ユーザーからリソースサーバー１５２のリソースに対するアクセス指示を受け付ける。ステップＳ１００２でクライアントモジュール３５１は、リソースサーバーへのアクセスに必要なアクセストークンを保持しているか判断する。ここでアクセストークンを保持していると判断された場合はステップＳ１００５に遷移する。またアクセストークンを保持していないと判断された場合はステップＳ１００３に遷移する。

ステップＳ１００３でクライアントモジュール３５１は、認証・認可サーバー１５１に対し、アクセストークンを要求する。ここでアクセストークンの要求は、モバイル端末を操作するユーザーの情報およびステップＳ４０３で受信したクライアント識別子を含む。ステップＳ１００４でクライアントモジュール３５１は、ステップＳ１００３の応答としてアクセストークンが発行されたか判断する。ここでアクセストークンが発行されたと判断された場合はステップＳ１００５に遷移する。またアクセストークンが発行されなかったと判断された場合はステップＳ１０５０に遷移する。

ステップＳ１００５でクライアントモジュール３５１は、ステップＳ１００３の応答として得られたアクセストークンを保持するとともに、そのアクセストークンを用いてリソースサーバー１５２のリソースにアクセスを行い、フローを終了する。ステップＳ１０５０でクライアントモジュール３５１は、アクセストークンが得られなかったためリソースサーバー１５２にアクセスできない旨をユーザーに通知し、フローを終了する。

図７（Ｂ）は本実施の形態に係る、認証・認可サーバー１５１における、アクセストークンの発行フローである。本フローは認証・認可サーバー１５１の認可モジュール３０４がクライアントモジュール３５１から、Ｓ１００３におけるアクセストークンの要求を受信することで開始される。

ステップＳ１１０１で認可モジュール３０４は、クライアントモジュール３５１からアクセストークンの要求を受け付ける。ここで受け付けたアクセストークンの要求は、ユーザーの情報およびクライアント識別子を含む。ステップＳ１１０２で認可モジュール３０４は、クライアントモジュール３５１を操作しているユーザーがログイン済みか判断する。ここでユーザーがログイン済みと判断された場合はステップＳ１１０５に遷移する。またログイン済みでないと判断された場合はステップＳ１１０３に遷移する。

ステップＳ１１０３で認証モジュール３０２は、クライアントモジュール３５１に指示し、図８（Ａ）に示されるようなログイン画面１４０１を表示させることでユーザーにログインを促す。なおログインフローの詳細は図５（Ｂ）で示したものと同様である。ステップＳ１１０４で認証モジュール３０２は、ステップＳ１１０３に対応してユーザーがログインしたか判断する。ここでユーザーがログインしたと判断されればステップＳ１１０５に遷移する。またユーザーがログインしなかったと判断された場合はステップＳ１１５０に遷移する。

ステップＳ１１０５でクライアント識別子管理モジュール３０３は、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるクライアント識別子とユーザー情報が紐付けられているか、表２のクライアント識別子紐付けテーブルをもとに判断する。ここで紐付けられていると判断された場合はステップＳ１１０６に遷移する。また紐付けられていないと判断された場合はステップＳ１１１０に遷移する。たとえばここで、ユーザーがＵｓｅｒＸでありクライアント識別子がＡｐｐＡｍ００２だったとすると、両者は紐付けられているため、ステップＳ１１０６に遷移する。

ステップＳ１１０６で認可モジュール３０４は、ユーザーに紐付けられたクライアント識別子の内、いずれかでアクセストークンを発行しているか判断する。ここで、ユーザーに紐付けられたいずれかのクライアント識別子でアクセストークンを発行していると判断された場合は、ユーザーに認可の確認を求めることなくステップＳ１１０７に遷移しアクセストークンを発行する。換言すれば、ユーザーはリソースサーバー１５２が備えたサービスにおけるユーザーの権限を、クライアント識別子が示すクライアントに対し移譲することを許可する指示を行うことなくアクセストークンが発行されるということである。

またアクセストークンを発行していないと判断された場合はステップＳ１１１０に遷移する。表３はアクセストークンテーブルであり、ユーザーＵｓｅｒＸがクライアント識別子ＡｐｐＡｍ００１のクライアントモジュールに対して認可を行った結果、アクセストークン１１１１１１１１が発行されている様子を示す。たとえばここでユーザーがＵｓｅｒＸでありクライアント識別子がＡｐｐＡｍ００２だったとする。このときＡｐｐＡｍ００２に対してはアクセストークンが発行されていない。しかしＵｓｅｒＸに紐付けられたＡｐｐＡｍ００１に対しては既にアクセストークンが発行されている。そのためユーザーに紐付けられたいずれかのクライアント識別子でアクセストークンを発行していると判断され、ステップＳ１１０７に遷移する。

ステップＳ１１０７で認可モジュール３０４は、アクセストークンを発行し、ステップＳ１１０１で受け付けたアクセストークンの要求に含まれるクライアント識別子とユーザー情報に紐付けて表３のアクセストークンテーブルで記憶する。また発行したアクセストークンをクライアントモジュール３５１に返し、フローを終了する。

ステップＳ１１１０で認可モジュール３０４は、クライアントモジュール３５１に指示し、図８（Ｃ）に示すような認可確認画面１４０３を表示させ、ユーザーの確認を求める。ステップＳ１１１１で認可モジュール３０４は、ステップＳ１１１０に対応してユーザーの認可を得られたか判断する。ここで認可を得られたと判断された場合はステップＳ１１０７に遷移する。また認可を得られなかったと判断された場合はステップＳ１１５０に遷移する。ユーザーが認可を行うために図８（Ｃ）にて許可を選択し、サービスにおけるユーザーの権限をクライアントへ移譲することを許可する指示を行う操作を認可操作と称し、ユーザーにより認可操作が行われたことでアクセストークンの発行が行われる。ステップＳ１１５０で認可モジュール３０４は、アクセストークンを発行できない旨をクライアントモジュール３５１に通知し、フローを終了する。

図８は本実施の形態に係る、画面の表示例である。図８（Ａ）はユーザーがログインするときに操作するログイン画面１４０１の例である。また図８（Ｂ）はユーザーがクライアントモジュールをユーザー自身に紐付ける際の確認を行うクライアント紐付け確認画面１４０２の例である。また図８（Ｃ）はユーザーがクライアントモジュールを認可しアクセストークンの発行を許可する認可確認画面１４０３の例である。

本実施の形態によれば、ユーザーに紐付けられたクライアント識別子が示すクライアントのいずれかでアクセストークンが発行されていれば、アクセストークンを発行していないクライアントに対して認可操作を省略してアクセストークンを発行できる。結果としてユーザーは自身が所有する端末を紐付けし、１台目の端末でアクセストークンを発行させれば２台目以降の紐付けられた端末では認可操作を省略してアクセストークンが発行されるので利便性が向上する。

これは特に、アクセストークンの有効期限が切れて再度認可操作が必要になった場合に効果的である。アクセストークンの有効期限が切れた場合、認可確認画面１４０３を操作することで、クライアント識別子に対して新しいアクセストークンを発行する必要がある。ここで本実施の形態を適用しない場合、ユーザーが所有するそれぞれの端末で認可操作が必要になる。一方、本実施の形態によれば、アクセストークンの初回発行時にはクライアント紐付け確認画面１４０２を操作する必要があるものの、アクセストークンの再発行時、２台目以降の紐付けられた端末では、クライアント紐付け確認画面１４０２を操作することなく、認可確認画面１４０３の操作を省略できる。結果として、２台目以降の紐付けられた端末で、認可確認画面１４０３の操作を省略できる分、ユーザーの利便性が向上する。

次に、本発明を実施するための第２の形態について図面を用いて説明する。なお第１の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。第１の実施の形態においては、ユーザーにクライアント識別子を紐付ける操作が必要であったが、この操作を省略する方式について説明する。

図９は本実施の第２の形態に係る、認証・認可サーバー１５１のモジュール構成図である。認証・認可サーバー１５１は認証モジュール３０２、認可モジュール３０４を持つ。さらに認証・認可サーバー１５１は第２のクライアント識別子管理モジュール３１１、第２のクライアント識別子紐付け管理モジュール３１２を持つ。

図１０（Ａ）は本実施の第２の形態に係る、認証・認可サーバー１５１における、クライアント識別子発行フローである。本フローはクライアントモジュール３５１からのクライアント識別子発行依頼を受信することで開始される。

ステップＳ２００１で第２のクライアント識別子管理モジュール３１１は、ステップＳ４０２で取り出した証明書から、クライアントモジュールの種別を判断する。表４はクライアント種別テーブルであり、証明書情報とクライアント種別が対応付けて管理されている。たとえばステップＳ４０２で取り出した証明書がＣｅｒｔＣであれば、クライアント種別はＡｐｐ−Ａ−ｍｏｂｉｌｅであると判断される。

ステップＳ２００２で第２のクライアント識別子管理モジュール３１１は、クライアント識別子を発行し、ステップＳ２００１で判断されたクライアント種別を紐付けて記憶する。表５は第２のクライアント識別子テーブルであり、クライアント識別子ＡｐｐＡｍ００１およびＡｐｐＡｍ００２がともに、クライアント種別Ａｐｐ−Ａ−ｍｏｂｉｌｅである様子を示している。

図１０（Ｂ）は本実施の第２の形態に係る、認証・認可サーバー１５１における、クライアント識別子紐付け要否判断のフローである。本フローは認証・認可サーバー１５１がクライアントモジュール３５１からのアクセスを受信することで開始される。ステップＳ２１０１で第２のクライアント識別子紐付け管理モジュール３１２は、クライアントモジュール３５１からのアクセスを受け付ける。ここで受け付けたアクセスには、ユーザーの情報およびクライアント識別子を含む。

ステップＳ２１０２で第２のクライアント識別子紐付け管理モジュール３１２は、ステップＳ２１０１で受け付けたユーザーに紐付くクライアント識別子が１つ以上存在するか判断する。ここで１つ以上存在すると判断された場合はステップＳ２１０３に遷移する。また存在しないと判断された場合はステップＳ２１２０に遷移し、紐付け確認することなくクライアント識別子をユーザーに紐付ける。表６は第２のクライアント識別子紐付けテーブルであり、第２のクライアント識別子紐付け管理モジュール３１２が記憶しているユーザーとクライアント識別子の紐付け、およびクライアント種別との対応の様子を示す。ここではユーザーＵｓｅｒＸに対し、クライアント識別子ＡｐｐＡｍ００１およびＡｐｐＡｍ００２が紐付けられている様子を示す。さらにクライアント識別子ＡｐｐＡｍ００１およびＡｐｐＡｍ００２はともにクライアント種別がＡｐｐ−Ａ−ｍｏｂｉｌｅであることを示す。ここで、ステップＳ２１０１で受け付けたユーザー情報がＵｓｅｒＸであった場合、ステップＳ２１０２ではユーザーに紐付けられたクライアント識別子が１つ以上存在すると判断される。

ステップＳ２１０３で第２のクライアント識別子紐付け管理モジュール３１２は、ステップＳ２１０１で受け付けたアクセスに含まれるユーザーの情報およびクライアント識別子から、クライアント識別子がユーザーに紐付け済みかを判断する。ここで紐付け済みと判断された場合はステップＳ２１０４に遷移する。また紐付け済みでないと判断された場合はステップＳ２１１０に遷移する。

ステップＳ２１０４で第２のクライアント識別子紐付け管理モジュール３１２は、クライアント識別子がユーザーに紐付け済みであり、クライアント識別子の紐付け確認は不要である旨をクライアントモジュール３５１に返してフローを終了する。ステップＳ２１１０で第２のクライアント識別子紐付け管理モジュール３１２は、表５のクライアント識別子テーブルを参照し、ステップＳ２１０１で受け付けたクライアント識別子のクライアント種別を判断する。たとえばここでクライアント識別子がＡｐｐＡｍ００１であった場合、クライアント種別はＡｐｐ−Ａ−ｍｏｂｉｌｅとなる。

ステップＳ２１１１で第２のクライアント識別子紐付け管理モジュール３１２は、ステップＳ２１１０で判断されたクライアント種別と同種のクライアントがユーザーに紐付けられているか判断する。ここで同種のクライアントが紐付けられていると判断された場合はステップＳ２１２０に遷移し、紐付け確認することなくクライアント識別子をユーザーに紐付ける。即ち、ユーザーは、ユーザーの識別子と第２のクライアント識別子とを紐付けるか否かを問い合わせる紐付け確認画面を介し、紐付ける指示を行う必要がなくなる。また、同種のクライアントが紐付けられていないと判断された場合はステップＳ２１１２に遷移する。

ステップＳ２１１２で第２のクライアント識別子紐付け管理モジュール３１２は、クライアントモジュール３５１に対してクライアント識別子紐付け確認を要求し、図８（Ｂ）に示すようなクライアント紐付け確認画面１４０２を表示させる。またクライアント識別子紐付け確認の要求が完了するとフローを終了する。

ステップＳ２１２０で第２のクライアント識別子紐付け管理モジュール３１２は、クライアント識別子紐付けの確認を省略するために図８（Ｂ）に示すクライアント紐付け確認画面１４０２をモバイル端末１９１に提供せずに、クライアント識別子をユーザーに紐づける。

本発明の実施例２によれば、同種のクライアント種別のクライアント識別子がユーザーに紐付いている場合は、ユーザーは紐付け確認操作を省略できるため、さらに利便性が向上する。また初めてユーザーにクライアント識別子を紐付ける場合も紐付け確認操作を省略でき、同様に利便性が向上する。

次に、本発明の実施例３について図面を用いて説明する。なお第１の実施例もしくは第２の実施例と共通の部分については説明を省略し、以下では差異部分のみ説明する。第３の実施例においては、認証・認可サーバー１５１上で事前に特定の設定を行うことで、クライアント識別子の紐付け操作を省略する方式について説明する。

図１１は本実施の第３の形態に係る、認証・認可サーバー１５１のモジュール構成図である。認証・認可サーバー１５１は認証モジュール３０２、認可モジュール３０４、第２のクライアント識別子管理モジュール３１１を持つ。さらに認証・認可サーバー１５１は、第３のクライアント識別子紐付け管理モジュール３２１、紐付け確認要否管理モジュール３２２を持つ。

図１２は実施例３における認証・認可サーバー１５１において、クライアント識別子紐付け確認の要否設定のフローである。本フローは認証・認可サーバー１５１がクライアント識別子紐付け確認要否設定画面３４０１へのアクセスを受信することで開始される。

ステップＳ３００１で紐付け確認要否管理モジュール３２２は、クライアント識別子紐付け確認要否設定画面へのアクセスを受け付ける。ここで表示する画面は図１４に示すようなクライアント識別子紐付け確認要否設定画面３４０１である。

ステップＳ３００２で紐付け確認要否管理モジュール３２２は、クライアント識別子紐付け確認要否設定指示を受け付け、紐付け確認要否テーブルで記憶してフローを終了する。表７は紐付け確認要否テーブルであり、ユーザーごとのクライアント識別子紐付け確認要否設定を記憶する。たとえばここではＵｓｅｒＸは紐付け確認を省略する設定が為されていることを示す。

図１３は実施例３における認証・認可サーバー１５１において、クライアント識別子紐付け要否判断を行うフローである。本フローは認証・認可サーバー１５１がクライアントモジュール３５１からのアクセスを受信することで開始される。

ステップＳ３１０１で紐付け確認要否管理モジュール３２２は、表７の紐付け確認要否テーブルから、ユーザーの紐付け確認要否設定を取得する。ステップＳ３１０２で第３のクライアント識別子紐付け管理モジュール３２１は、ステップＳ３１０１で取得したユーザーの紐付け確認要否設定が、確認を必ず省略する設定か判断する。確認を必ず省略する設定だった場合はステップＳ２１２０に遷移する。また確認を必ず省略する設定でなかった場合はステップＳ３１０３に遷移する。

ステップＳ３１０２で第３のクライアント識別子紐付け管理モジュール３２１は、ステップＳ３１０１で取得したユーザーの紐付け確認要否設定が、確認を必ず実施する設定か判断する。確認を必ず実施する設定だった場合はステップＳ２１１２に遷移する。また確認を必ず実施する設定でなかった場合はステップＳ２１１０に遷移する。図１４は実施例３に係る、クライアント識別子紐付け確認要否設定画面３４０１の表示例である。本実施の第３の形態によれば、認証・認可サーバー１５１上で事前に設定を行うことで、ユーザーはクライアント種別に関わらず紐付け確認操作を省略できるため、さらに利便性が向上する。

次に、本発明を実施するための第４の形態について図面を用いて説明する。なお第１の実施の形態、第２の実施の形態、もしくは第３の実施の形態と共通の部分については説明を省略し、以下では差異部分のみ説明する。第４の実施の形態においては、ユーザーにクライアント識別子を紐付けるか否かに関して、ユーザーがログイン画面の操作時に指定する方式について説明する。

図１５は本実施の第４の形態に係る、認証・認可サーバー１５１およびモバイル端末１９１、１９２のモジュール構成を示す図である。図１５（Ａ）は認証・認可サーバー１５１、図１５（Ｂ）および図１５（Ｃ）はモバイル端末１９１および１９２のモジュール構成を、それぞれ示す。認証・認可サーバー１５１はクライアント識別子管理モジュール３０１、第２の認証モジュール３３１、第４のクライアント識別子紐付け管理モジュール３３２、認可モジュール３０４を持つ。またモバイル端末１９１および１９２はクライアントモジュール３５１、第２のクライアント紐付け要求モジュール３６１を持つ。

図１６（Ａ）は本実施の第４の形態に係る、モバイル端末１９１もしくはモバイル端末１９２における、クライアントの開始フローである。本フローはユーザーがクライアントモジュール３５１を操作することで開始される。ステップＳ４００１で第２のクライアント紐付け要求モジュール３６１は、認証・認可サーバー１５１からの要求に従い図１７に示されるような第２のログイン画面４４０１を表示し、ユーザーに認証情報の入力を促す。また第２のクライアント紐付け要求モジュール３６１は、ユーザーに入力された認証情報を認証・認可サーバー１５１に送信してログインするとともに、ユーザーに指定されたクライアントの紐付け確認を送信する。

図１６（Ｂ）は本実施の第４の形態に係る、認証・認可サーバーにおけるログインフローである。本フローは認証・認可サーバー１５１がクライアントモジュール３５１からリソースへのアクセス要求を受信することで開始される。ステップＳ４１０１で第２の認証モジュール３３１は、クライアントモジュール３５１から、リソースサーバー１５２のリソースへのアクセス要求を受け付ける。ステップＳ４１０２で第２の認証モジュール３３１は、ステップＳ４１０１に係るユーザーがログイン済みであるか判断する。ここでユーザーがログイン済みであると判断された場合はフローを終了する。またログイン済みでないと判断された場合はステップＳ４１０３に遷移する。

ステップＳ４１０３で第２の認証モジュール３３１は、クライアントモジュール３５１に指示し、図１７に示されるような第２のログイン画面４４０１を表示させる。第２のログイン画面４４０１では、ログインが許可された際に、クライアント識別子をユーザーに紐付けるか指定できる。なおここで、ユーザーの操作を減らす観点では、第２のログイン画面４４０１の初期状態として、クライアント識別子をユーザーに紐付ける指定になっていることが好ましいが、紐付けない初期状態であってもよい。

ステップＳ４１０４で第２の認証モジュール３３１は、第２のログイン画面４４０１で入力された認証情報とクライアント識別子、およびクライアント識別子をユーザーに紐付けるか否かの指示を受け付ける。ステップＳ４１０５で第２の認証モジュール３３１は、ステップＳ４１０４で受け付けた認証情報が妥当か判断する。ここで認証情報が妥当と判断された場合はステップＳ４１０６に遷移する。また認証情報が妥当でないと判断された場合はステップＳ４１５０に遷移する。

ステップＳ４１０６で第２の認証モジュール３３１は、ユーザーのログインを許可する。ステップＳ４１０７で第４のクライアント識別子紐付け管理モジュール３３２は、ステップＳ４１０４で、クライアント識別子をユーザーに紐付ける指示を受け付けたか判断する。ここで指示を受け付けたと判断された場合はステップＳ４１０８に遷移する。また指示を受け付けなかったと判断された場合はフローを終了する。ステップＳ４１０８で第４のクライアント識別子紐付け管理モジュール３３２は、ステップＳ４１０４で受け付けたクライアント識別子をユーザーに紐付けてフローを終了する。ステップＳ４１５０で第２の認証モジュール３３１は、ユーザーのログインを拒否し、フローを終了する。図１７は本実施の第４の形態に係る、第２のログイン画面４４０１の画面例である。

本実施の第４の実施例によれば、ユーザーはログイン操作時にクライアント識別子の紐付けを指定できるため、別途クライアント識別子の紐付け確認操作をする必要がなくなり、さらに利便性が向上する。

特に第２のログイン画面４４０１の初期状態として、クライアント識別子をユーザーに紐付ける指定にした場合を考える。このときユーザーは、クライアント識別子をユーザーに紐付けるか否かを指定するチェックボックスをクリックする操作を増やさず、また図８（Ｂ）に示すようなクライアント紐付け確認画面１４０２の操作も省略して、クライアント識別子の紐付けを実現できるようになり、利便性が向上する。なおこのとき、クライアント識別子の紐付けを望まないユーザーは、第２のログイン画面４４０１のチェックボックスをクリックしチェックボックスをオフにすることで、クライアント識別子をユーザーに紐付けない設定としてログイン操作を進めることができる。

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

１５１認証・認可サーバー
１９１モバイル端末
１９２モバイル端末
３０１クライアント識別子管理モジュール
３０２認証モジュール
３０３クライアント識別子紐付け管理モジュール
３０４認可モジュール
３５１クライアントモジュール
３５２クライアント紐付け要求モジュール

Claims

クライアントから利用可能なサービスを備えるサーバーシステムと、第１のクライアントと、第２のクライアントと、認証サーバーシステムとを含む権限移譲システムであって、
前記第１のクライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断する認証手段と、
前記認証手段により正規のユーザーであると判断された前記ユーザーが前記第１のクライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記第１のクライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記第１のクライアントへ移譲されたことを示す権限情報を発行する発行手段と、
前記第１のクライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記第１のクライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可手段と、
前記認証手段により正規のユーザーであると判断された前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理する管理手段と、を有し、
前記発行手段は、前記ユーザーの識別子と前記第２のクライアントの識別子とが紐付けられている場合、前記サービスにおける前記ユーザーの権限を前記第２のクライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記第２のクライアントへ移譲されたことを示す権限情報を発行することを特徴とする権限移譲システム。
前記管理手段は、前記ユーザーが前記認証手段により正規のユーザーであると判断された後、前記ユーザーが操作する前記第２のクライアントが前記ユーザーの識別子と紐付いていないことを確認した場合、前記サービスにおける前記ユーザーの権限を前記第２のクライアントへ移譲することを許可する指示の操作を省略させるため、前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けるか否か、を問い合わせる紐付け確認画面を提供し、前記紐付け確認画面を介し前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けることが指示されたことに応じて、前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理することを特徴とする請求項１に記載の権限移譲システム。
前記管理手段は、前記ユーザーの識別子と前記第１のクライアントの識別子と前記クライアントの種別とを紐付けて管理しており、前記ユーザーの識別子と前記第２のクライアントの識別子とを紐づける際、前記第２のクライアントの種別が前記第１のクライアントの識別子に紐付く種別と同一である場合は、前記紐付け確認画面を介して前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付ける指示を受け付けることなく、前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理することを特徴とする請求項２に記載の権限移譲システム。
前記管理手段は、前記紐付け確認画面を介し、前記ユーザーによって行われる前記ユーザーの識別子と任意のクライアントの識別子とを紐付ける指示を省略することが事前に設定されている場合は、前記ユーザーの識別子と前記第１のクライアントの識別子とを紐づける際も、前記紐付け確認画面を介して前記ユーザーの識別子と前記第１のクライアントの識別子とを紐付ける指示を受け付けることなく、前記ユーザーの識別子と前記第１のクライアントの識別子とを紐付けて管理することを特徴とする請求項３に記載の権限移譲システム。
前記認可手段は、前記発行手段により権限情報が発行されなかった場合は、前記第１のクライアント、および／または前記第２のクライアントが前記ユーザーの権限で前記サービスを利用することを認可しないように制御することを特徴とする請求項１乃至４の何れか１項に記載の権限移譲システム。
前記発行手段は、前記ユーザーの識別子と任意のクライアントの識別子とが紐付けられている場合、前記クライアントに対して前記認可確認画面を提供しないように制御することを特徴とする請求項１乃至５の何れか１項に記載の権限移譲システム。
クライアントから利用可能なサービスを備えるサーバーシステムと、第１のクライアントと、第２のクライアントと、認証サーバーシステムとを含む権限移譲システムにより実行される方法であって、
認証手段は、前記第１のクライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断し、
発行手段は、前記認証手段により正規のユーザーであると判断された前記ユーザーが前記第１のクライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記第１のクライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記第１のクライアントへ移譲されたことを示す権限情報を発行し、
認可手段は、前記第１のクライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記第１のクライアントが前記ユーザーの権限で前記サービスを利用することを認可し、
管理手段は、前記認証手段により正規のユーザーであると判断された前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理し、
更に、前記発行手段は、前記ユーザーの識別子と前記第２のクライアントの識別子とが紐付けられている場合、前記サービスにおける前記ユーザーの権限を前記第２のクライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記第２のクライアントへ移譲されたことを示す権限情報を発行することを特徴とする方法。
前記管理手段は、前記ユーザーが前記認証手段により正規のユーザーであると判断された後、前記ユーザーが操作する前記第２のクライアントが前記ユーザーの識別子と紐付いていないことを確認した場合、前記サービスにおける前記ユーザーの権限を前記第２のクライアントへ移譲することを許可する指示の操作を省略させるため、前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けるか否か、を問い合わせる紐付け確認画面を提供し、前記紐付け確認画面を介し前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けることが指示されたことに応じて、前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理することを特徴とする請求項７に記載の方法。
前記管理手段は、前記ユーザーの識別子と前記第１のクライアントの識別子と前記クライアントの種別とを紐付けて管理しており、前記ユーザーの識別子と前記第２のクライアントの識別子とを紐づける際、前記第２のクライアントの種別が前記第１のクライアントの識別子に紐付く種別と同一である場合は、前記紐付け確認画面を介して前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付ける指示を受け付けることなく、前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理することを特徴とする請求項８に記載の方法。
前記管理手段は、前記紐付け確認画面を介し、前記ユーザーによって行われる前記ユーザーの識別子と任意のクライアントの識別子とを紐付ける指示を省略することが事前に設定されている場合は、前記ユーザーの識別子と前記第１のクライアントの識別子とを紐づける際も、前記紐付け確認画面を介して前記ユーザーの識別子と前記第１のクライアントの識別子とを紐付ける指示を受け付けることなく、前記ユーザーの識別子と前記第１のクライアントの識別子とを紐付けて管理することを特徴とする請求項９に記載の方法。
前記認可手段は、前記発行手段により権限情報が発行されなかった場合は、前記第１のクライアント、および／または前記第２のクライアントが前記ユーザーの権限で前記サービスを利用することを認可しないように制御することを特徴とする請求項７乃至１０の何れか１項に記載の方法。
前記発行手段は、前記ユーザーの識別子と任意のクライアントの識別子とが紐付けられている場合、前記クライアントに対して前記認可確認画面を提供しないように制御することを特徴とする請求項７乃至１１の何れか１項に記載の方法。
クライアントから利用可能なサービスを備えるサーバーシステムと、第１のクライアントと、第２のクライアントと通信することが可能な認証サーバーシステムであって、
前記第１のクライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断する認証手段と、
前記認証手段により正規のユーザーであると判断された前記ユーザーが前記第１のクライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記第１のクライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記第１のクライアントへ移譲されたことを示す権限情報を発行する発行手段と、
前記第１のクライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記第１のクライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可手段と、
前記認証手段により正規のユーザーであると判断された前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理する管理手段と、を有し、
前記発行手段は、前記ユーザーの識別子と前記第２のクライアントの識別子とが紐付けられている場合、前記サービスにおける前記ユーザーの権限を前記第２のクライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記第２のクライアントへ移譲されたことを示す権限情報を発行することを特徴とする認証サーバーシステム。
クライアントから利用可能なサービスを備えるサーバーシステムと、第１のクライアントと、第２のクライアントと通信することが可能な認証サーバーシステムにて実行されるプログラムであって、
前記第１のクライアントにて表示される認証画面を介しユーザーから入力された認証情報を基に、前記ユーザーが正規のユーザーであるか否かを判断する認証ステップと、
前記認証ステップにて正規のユーザーであると判断された前記ユーザーが前記第１のクライアントにて表示される認可確認画面を介し、前記サービスにおける前記ユーザーの権限を前記第１のクライアントへ移譲することを許可する指示をした場合に、前記ユーザーの権限が前記第１のクライアントへ移譲されたことを示す権限情報を発行する発行ステップと、
前記第１のクライアントが前記サービスの利用を要求した際に送信する前記権限情報を基に、前記第１のクライアントが前記ユーザーの権限で前記サービスを利用することを認可する認可ステップと、
前記認証ステップにて正規のユーザーであると判断された前記ユーザーの識別子と前記第２のクライアントの識別子とを紐付けて管理する管理ステップと、を含み
前記発行ステップにおいては、前記ユーザーの識別子と前記第２のクライアントの識別子とが紐付けられている場合、前記サービスにおける前記ユーザーの権限を前記第２のクライアントへ移譲することを許可する指示を受け付けることなく、前記ユーザーの権限が前記第２のクライアントへ移譲されたことを示す権限情報を発行することを特徴とするプログラム。