(57)【要約】      （修正有）【課題】ユーザ群の認証情報を集中管理する方式と比べて、多数のユーザの認証情報が漏洩するリスクを低減する。【解決手段】ユーザが持つモバイル機器３００の認証アプリ３１０は、そのユーザの認証を行うユーザ認証部を有する。ＩＤプロバイダのユーザ情報ＤＢ２２２には、各ユーザのモバイル機器３００の認証アプリ３１０を特定するアクセス先情報が登録されている。ユーザからログイン要求を受けたサービスプロバイダは、ＩＤプロバイダ２００に認証代行を要求する。ＩＤプロバイダ２００は、ユーザから入力されたユーザＩＤに対応するアクセス先情報を用いてそのユーザのモバイル機器３００の認証アプリ３１０に認証を要求し、認証結果を受け取る。そして、その認証結果をサービスプロバイダに応答する。【選択図】図１
2018037025.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを、
各ユーザの個人認証装置を特定する情報を記憶する記憶手段、
サービス装置の利用を要求するユーザから入力された認証情報を含む認証要求を、前記記憶手段に記憶されている情報を用いてそのユーザの前記個人認証装置に送信し、この送信に応じて前記個人認証装置から返される認証結果に応じた認証応答を前記サービス装置に提供する提供手段、
として機能させるためのプログラム。
【請求項２】
前記コンピュータを、
前記ユーザから入力された前記認証情報に対して前記個人認証装置から認証成功を表す前記認証結果を受け取った場合に、その認証成功を表す認証結果をそのユーザに対応付けて保持する認証成功保持手段、
として更に機能させると共に、
前記提供手段は、前記サービス装置の利用を要求したユーザに対応する認証成功を表す認証結果が前記認証成功保持手段にある場合、そのユーザの前記個人認証装置に対して前記認証要求を送信せずに、前記サービス装置に認証成功を表す認証応答を提供する、
ことを特徴とする請求項１に記載のプログラム。
【請求項３】
前記認証成功保持手段は、前記ユーザから入力された前記認証情報に対して前記個人認証装置から認証成功を表す前記認証結果と共にその認証結果を適用するサービス装置のリストを受け取った場合に、その認証成功を表す認証結果とそのリストとをそのユーザに対応付けて保持し、
前記提供手段は、前記ユーザから第２のサービス装置の利用が要求された場合において、前記ユーザに対応する認証成功を表す認証結果が前記認証成功保持手段にあり、かつ前記ユーザに対応して前記認証成功保持手段に保持された前記リストに前記第２のサービス装置が含まれる場合、前記第２のサービス装置に認証成功を表す認証応答を提供する、
ことを特徴とする請求項２に記載のプログラム。
【請求項４】
前記提供手段は、前記サービス装置の利用を要求するユーザの前記個人認証装置と通信して前記認証結果を得ることができる場合は、その個人認証装置から前記認証結果を得て、その認証結果に応じた前記認証応答を前記サービス装置に提供し、前記サービス装置の利用を要求するユーザの前記個人認証装置と通信して前記認証結果を得ることができない場合は、前記認証成功保持手段にそのユーザに対応する認証成功を表す認証結果があれば、前記サービス装置に認証成功を表す認証応答を提供する、
ことを特徴とする請求項２に記載のプログラム。
【請求項５】
前記提供手段は、前記サービス装置の利用を要求するユーザの前記個人認証装置と通信して前記認証結果を得ることができず、かつ前記認証成功保持手段にそのユーザに対応する認証成功を表す認証結果がない場合に、前記個人認証装置の確認を促す通知が前記ユーザに対して伝達されるようにする処理を実行する、
ことを特徴とする請求項４に記載のプログラム。
【請求項６】
前記コンピュータを、
前記サービス装置から前記ユーザの属性情報を要求された場合に、前記記憶手段に記憶されている情報を用いてそのユーザの前記個人認証装置にその属性情報を要求し、その要求に応じて前記個人認証装置から提供された属性情報を前記サービス装置に応答する属性応答手段、
として更に機能させるための請求項１〜５のいずれか１項に記載のプログラム。
【請求項７】
前記属性応答手段は、前記個人認証装置から提供された前記ユーザの属性情報を予め定められた期間保持し、その期間内に前記サービス装置から再度前記ユーザの属性情報が要求された場合、そのユーザの前記個人認証装置と通信してその属性情報を得ることができる場合は、その個人認証装置から得たその属性情報を前記サービス装置に提供し、前記ユーザの前記個人認証装置と通信してその属性情報を得ることができない場合は、保持している前記ユーザの属性情報を前記サービス装置に提供する、
ことを特徴とする請求項６に記載のプログラム。
【請求項８】
各ユーザの個人認証装置を特定する情報を記憶する記憶手段と、
サービス装置の利用を要求するユーザから入力された認証情報を含む認証要求を、前記記憶手段に記憶されている情報を用いてそのユーザの前記個人認証装置に送信し、この送信に応じて前記個人認証装置から返される認証結果に応じた認証応答を前記サービス装置に提供する提供手段と、
を含む認証システム。
【請求項９】
認証システムと、各ユーザの個人認証装置と、を含み、
前記認証システムは、
各ユーザの個人認証装置を特定する情報を記憶する記憶手段と、
サービス装置の利用を要求するユーザから入力された認証情報を含む認証要求を、前記記憶手段に記憶されている情報を用いてそのユーザの前記個人認証装置に送信し、この送信に応じて前記個人認証装置から返される認証結果に応じた認証応答を前記サービス装置に提供する提供手段と、
を含み、
前記個人認証装置は、
前記認証システムから受信した前記認証情報が当該認証装置を持つユーザのものかどうかを認証し、認証結果を前記認証システムに返す認証手段、
を含む、ことを特徴とする認証連携システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム、認証システム及び認証連携システムに関する。
【背景技術】
【０００２】
シングルサインオンを実現するためにOpen ID等の認証連携の標準に準拠した認証サーバやＩＤプロバイダを利用する仕組みが普及しつつある。
【０００３】
また、アクセスしてきたユーザの認証を他のシステムに委託する技術として以下に示すものが知られている。
【０００４】
特許文献１に開示されたセンタサーバは、認証装置を選定する条件テーブルを有し、バックエンドＷｅｂシステム等を管理し、このシステム利用を要求するリクエストを受信する。クライアント端末がリクエストを送信すると、センタサーバはリクエストを受信し、リクエストに認証済みクッキー情報があるかを判断し、ない場合はリクエストに基づき条件テーブルを検索して認証処理を実行する認証装置を選定し、選定した認証装置に認証処理を依頼する。選定された認証装置は認証処理を行い認証結果をセンタサーバに返す。センタサーバは認証結果を受信し、認証成立の場合には認証済みクッキーを作成してクライアント端末に送信する。
【０００５】
特許文献２に開示されたシステムは、情報サーバとネットワーク回線を介して接続可能にされた第１端末装置と、情報サーバとネットワーク回線から独立した通信回線で接続可能にされた第２端末装置とを備え、情報サーバにて新規のパスワードを生成して通信回線を介して第２端末装置に送信すると共にネットワーク回線を介して認証サーバに送信し、第２端末装置では送信されて来たパスワードを受信して告知し、第１端末装置ではユーザからパスワードを受け入れ、そのパスワードを認証サーバにネットワーク回線を介して送信し、認証サーバでは第１端末装置から送信されたパスワードと情報サーバから送信されたパスワードとの一致に応じてユーザ認証を行う。
【０００６】
特許文献３に開示された方法では、本人認証のために認証に用いる認証データを照合する認証用端末毎に専用の電話番号（着側電話番号）を割り当て、利用者に携帯電話機から本人認証を受ける認証用端末に割り当てられた電話番号に電話をかけさせる。これを着信した認証センタサーバでは、着側電話番号（利用者が発信した発信先電話番号）から認証用端末を特定し、特定された認証用端末に認証データを送信することによって、利用者が本人認証を受ける認証用端末に、確実に認証に用いる認証データを送信することを可能にしている。この方法では、静脈データ等の利用者の認証データは、認証センタサーバで集中管理されており、この認証データが認証用端末に送られる。そして、認証用端末は、認証センタサーバから受け取った認証データと、ユーザの入力したデータ（例えば手のひら等をかざして読み取らせた静脈データ）とを照合して認証を行う。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１０−２０５１６６号公報
【特許文献２】特開２００２−０８２９１０号公報
【特許文献３】特開２０１１−２１５９４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
認証を行う端末が、認証情報を集中管理するサーバから対象ユーザの認証情報を取得し、これとユーザが入力したデータとから認証を行う方式では、ユーザが入力したデータは端末装置の外に出ないため、入力データについての漏洩リスクが少ない。しかし、サーバがハッキングされると、一度に多数のユーザの認証情報が漏洩するリスクがある。
【０００９】
本発明は、ユーザ群の認証情報を集中管理する方式と比べて、多数のユーザの認証情報が漏洩するリスクを低減することを目的とする。
【課題を解決するための手段】
【００１０】
請求項１に係る発明は、コンピュータを、各ユーザの個人認証装置を特定する情報を記憶する記憶手段、サービス装置の利用を要求するユーザから入力された認証情報を含む認証要求を、前記記憶手段に記憶されている情報を用いてそのユーザの前記個人認証装置に送信し、この送信に応じて前記個人認証装置から返される認証結果に応じた認証応答を前記サービス装置に提供する提供手段、として機能させるためのプログラムである。
【００１１】
請求項２に係る発明は、前記コンピュータを、前記ユーザから入力された前記認証情報に対して前記個人認証装置から認証成功を表す前記認証結果を受け取った場合に、その認証成功を表す認証結果をそのユーザに対応付けて保持する認証成功保持手段、として更に機能させると共に、前記提供手段は、前記サービス装置の利用を要求したユーザに対応する認証成功を表す認証結果が前記認証成功保持手段にある場合、そのユーザの前記個人認証装置に対して前記認証要求を送信せずに、前記サービス装置に認証成功を表す認証応答を提供する、ことを特徴とする請求項１に記載のプログラムである。
【００１２】
請求項３に係る発明は、前記認証成功保持手段は、前記ユーザから入力された前記認証情報に対して前記個人認証装置から認証成功を表す前記認証結果と共にその認証結果を適用するサービス装置のリストを受け取った場合に、その認証成功を表す認証結果とそのリストとをそのユーザに対応付けて保持し、前記提供手段は、前記ユーザから第２のサービス装置の利用が要求された場合において、前記ユーザに対応する認証成功を表す認証結果が前記認証成功保持手段にあり、かつ前記ユーザに対応して前記認証成功保持手段に保持された前記リストに前記第２のサービス装置が含まれる場合、前記第２のサービス装置に認証成功を表す認証応答を提供する、ことを特徴とする請求項２に記載のプログラムである。
【００１３】
請求項４に係る発明は、前記提供手段は、前記サービス装置の利用を要求するユーザの前記個人認証装置と通信して前記認証結果を得ることができる場合は、その個人認証装置から前記認証結果を得て、その認証結果に応じた前記認証応答を前記サービス装置に提供し、前記サービス装置の利用を要求するユーザの前記個人認証装置と通信して前記認証結果を得ることができない場合は、前記認証成功保持手段にそのユーザに対応する認証成功を表す認証結果があれば、前記サービス装置に認証成功を表す認証応答を提供する、ことを特徴とする請求項２に記載のプログラムである。
【００１４】
請求項５に係る発明は、前記提供手段は、前記サービス装置の利用を要求するユーザの前記個人認証装置と通信して前記認証結果を得ることができず、かつ前記認証成功保持手段にそのユーザに対応する認証成功を表す認証結果がない場合に、前記個人認証装置の確認を促す通知が前記ユーザに対して伝達されるようにする処理を実行する、ことを特徴とする請求項４に記載のプログラムである。
【００１５】
請求項６に係る発明は、前記コンピュータを、前記サービス装置から前記ユーザの属性情報を要求された場合に、前記記憶手段に記憶されている情報を用いてそのユーザの前記個人認証装置にその属性情報を要求し、その要求に応じて前記個人認証装置から提供された属性情報を前記サービス装置に応答する属性応答手段、として更に機能させるための請求項１〜５のいずれか１項に記載のプログラムである。
【００１６】
請求項７に係る発明は、前記属性応答手段は、前記個人認証装置から提供された前記ユーザの属性情報を予め定められた期間保持し、その期間内に前記サービス装置から再度前記ユーザの属性情報が要求された場合、そのユーザの前記個人認証装置と通信してその属性情報を得ることができる場合は、その個人認証装置から得たその属性情報を前記サービス装置に提供し、前記ユーザの前記個人認証装置と通信してその属性情報を得ることができない場合は、保持している前記ユーザの属性情報を前記サービス装置に提供する、ことを特徴とする請求項６に記載のプログラムである。
【００１７】
請求項８に係る発明は、各ユーザの個人認証装置を特定する情報を記憶する記憶手段と、サービス装置の利用を要求するユーザから入力された認証情報を含む認証要求を、前記記憶手段に記憶されている情報を用いてそのユーザの前記個人認証装置に送信し、この送信に応じて前記個人認証装置から返される認証結果に応じた認証応答を前記サービス装置に提供する提供手段と、を含む認証システムである。
【００１８】
請求項９に係る発明は、認証システムと、各ユーザの個人認証装置と、を含み、前記認証システムは、各ユーザの個人認証装置を特定する情報を記憶する記憶手段と、サービス装置の利用を要求するユーザから入力された認証情報を含む認証要求を、前記記憶手段に記憶されている情報を用いてそのユーザの前記個人認証装置に送信し、この送信に応じて前記個人認証装置から返される認証結果に応じた認証応答を前記サービス装置に提供する提供手段と、を含み、前記個人認証装置は、前記認証システムから受信した前記認証情報が当該認証装置を持つユーザのものかどうかを認証し、認証結果を前記認証システムに返す認証手段、を含む、ことを特徴とする認証連携システムである。
【発明の効果】
【００１９】
請求項１、８又は９に係る発明によれば、ユーザ群の認証情報を集中管理する方式と比べて、多数のユーザの認証情報が漏洩するリスクを低減することができる。
【００２０】
請求項２に係る発明によれば、ユーザの個人認証装置から認証結果を得られない場合でも、過去に取得した認証成功を表す認証結果が認証成功保持手段にあれば、サービス装置に対して認証応答を行うことができる。
【００２１】
請求項３に係る発明によれば、ユーザの個人認証装置から認証成功を表す認証結果を受けた後、その認証結果が適用される第２のサービス装置をユーザが利用しようとする場合に、個人認証装置にアクセスせずに認証を行うことができる。
【００２２】
請求項４に係る発明によれば、過去に取得した認証成功を表す認証結果が認証成功保持手段にあれば必ずその認証結果に基づきサービス装置に認証応答を行う場合と比べて、ユーザの個人認証装置の認証条件が変更された場合の対応の遅れを少なくすることができる。
【００２３】
請求項５に係る発明によれば、ユーザの個人認証装置から認証結果を得ることができずかつそのユーザに対応する認証成功を表す認証結果がない場合に、単にサービス装置に認証失敗を応答する方式と比べて、ユーザがサービス装置を利用できる可能性を高めることができる。
【００２４】
請求項６に係る発明によれば、ユーザ群の属性情報を集中管理する方式と比べて、多数のユーザの属性情報が漏洩するリスクを低減することができる。
【００２５】
請求項７に係る発明によれば、ユーザの個人認証装置からそのユーザの属性情報を得られない場合でも、過去に取得したそのユーザの属性情報があれば、サービス装置に対して属性情報を提供できる。
【図面の簡単な説明】
【００２６】
【図１】実施形態のシステム構成の例を示す図である。
【図２】実施形態のシステムにおけるユーザ認証の流れの一例を示す図である。
【図３】実施形態のシステムにおいて、あるサービスについてモバイル機器で行われたユーザ認証の結果を他のサービスからの認証要求に対応する認証処理に利用する流れの一例を示す図である。
【図４】実施形態のシステムにおいて、ユーザ属性を利用するサービスが要求された場合の処理の流れの一例を示す図である。
【図５】ＩＤプロバイダの機器認証要求部が実行する処理手順の一例を示す図である。
【発明を実施するための形態】
【００２７】
図１に、本実施形態のシステム構成の一例を示す。
【００２８】
このシステムは、サービスプロバイダ１００、ＩＤプロバイダ２００、ユーザが持つモバイル機器３００内の認証アプリ３１０を含む。
【００２９】
サービスプロバイダ１００は、ユーザに対して何らかの情報処理サービスを提供するシステムである。ユーザは、ユーザ側装置３５０を操作して、インターネット等のネットワークを経由してサービスプロバイダ１００にアクセスし、サービスの提供を要求する。ユーザ側装置３５０は、ネットワーク経由でサービスプロバイダ１００と通信可能な装置であればどのような装置でもよく、パーソナルコンピュータ、スマートフォン、タブレット端末、複合機、キオスク端末等がその例である。サービスプロバイダ１００は、サービスの提供のために提供先のユーザのＩＤ情報（ユーザを特定する識別情報。以下「ユーザＩＤ」と呼ぶ）を必要とするが、ユーザＩＤを特定するためのユーザ認証を自身では実行せずに、ＩＤプロバイダ２００にユーザ認証を依頼する。図にはサービスプロバイダ１００を１つ示しているが、インターネット等のネットワーク上には、ＩＤプロバイダ２００の認証代行サービスを受けるサービスプロバイダ１００が複数存在し得る。
【００３０】
ＩＤプロバイダ２００は、ネットワーク上に存在する様々なサービスプロバイダ１００に対して、認証代行サービスを提供するシステムである。ＩＤプロバイダ２００は、例えば、OpenID Connect、OpenID、SAML（Security Assertion Markup Language）等の連合アイデンティティ（Federated Identity）又は認証連携の標準に従って、連携先のサービスプロバイダ１００のためにユーザ認証処理を代行し、その結果得られるユーザＩＤを含む認証結果情報をそのサービスプロバイダ１００に提供する。提供するユーザＩＤは、例えばユーザがＩＤプロバイダ２００に登録したＩＤ情報であり、サービスプロバイダ１００はそのユーザＩＤでユーザを識別する。
【００３１】
本実施形態のＩＤプロバイダ２００は、ネットワーク上の複数のサービスプロバイダ１００からユーザ認証の要求を受け付けるものの、ユーザ認証それ自体は実行しない。ユーザの認証を実際に実行するのは、そのユーザが持つモバイル機器３００が実行する認証アプリ３１０である。このため、ＩＤプロバイダ２００は、ユーザを認証するのに必要な認証情報のうちユーザＩＤを知っていれば足り、認証情報のうちの残りの情報、すなわち認証対象のユーザがそのユーザＩＤに対応することを証明するパスワード等の情報は管理しない。ＩＤプロバイダ２００は、ユーザＩＤに対応付けて、パスワード等の証明用の情報の代わりに、当該ユーザの実際の認証のためのアクセス先（図示例ではモバイル機器３００の認証アプリ３１０）を特定する情報を保持していればよい。ＩＤプロバイダ２００は、サービスプロバイダ１００からの要求に応じてユーザの認証を行う場合、ユーザから入力された認証情報（例えばユーザＩＤとパスワードの組）を、そのアクセス先情報が示すモバイル機器３００に送って認証を要求する。そして、その要求に対するモバイル機器３００の認証アプリ３１０からの認証結果の応答に応じて、認証要求元のサービスプロバイダ１００に対して認証結果の情報を提供する。
【００３２】
モバイル機器３００は、ユーザが携帯する情報処理装置であり、スマートフォンやタブレット端末がその一例である。モバイル機器３００が内蔵するコンピュータには、認証アプリ３１０がインストールされている。認証アプリ３１０は、当該モバイル機器３００を持つユーザの認証に必要な情報を保持している。そして、この保持している情報を用いて、ＩＤプロバイダ２００からの認証要求についての認証を行い、認証結果をＩＤプロバイダ２００に返す。なお、ユーザがサービスプロバイダ１００からサービスを受けるのに用いるユーザ側装置３５０と、モバイル機器３００とが同一の装置であることもあり得る。
【００３３】
システムの各要素について更に詳しく説明する。
【００３４】
サービスプロバイダ１００は、ユーザ認証要求部１１０、サービストークン管理部１２０、ユーザ属性要求部１３０を有する。ユーザ認証要求部１１０は、ユーザ側装置３５０からユーザのサービスプロバイダ１００へのログイン要求を受け取ると、連携しているＩＤプロバイダ２００に対して認証要求を発する。サービストークン管理部１２０は、その認証要求に対してＩＤプロバイダ２００からサービスアクセストークンを受け取った場合、そのトークンを管理する。サービスアクセストークンは、そのトークンの発行先のユーザが、そのサービスプロバイダ１００のサービスの利用資格を有することを証する情報である。ユーザに対応する有効なサービスアクセストークンがサービストークン管理部１２０に管理されている場合、そのユーザはそのサービスプロバイダ１００のサービスを利用できる。ユーザ属性要求部１３０は、サービスプロバイダ１００がユーザに対してサービスを提供する際にそのユーザの属性情報（例えばユーザ名や所属部署等）が必要となった場合に、ＩＤプロバイダ２００に対して属性要求を発する。そして、その属性要求に対してＩＤプロバイダ２００から属性情報の応答を受けると、受け取った属性情報をサービスプロバイダ１００のそのサービスのための処理に対して渡す。
【００３５】
ＩＤプロバイダ２００は、機器認証要求部２１０、認証デバイス管理部２２０、ユーザトークン管理部２３０、及びユーザ属性取得部２４０を有する。
【００３６】
機器認証要求部２１０は、サービスプロバイダ１００のユーザ認証要求部１１０からユーザについての認証の要求を受けた場合に、その認証を実際に行うユーザ側の装置、この例ではモバイル機器３００の認証アプリ３１０、に対して認証要求を発する。このとき、機器認証要求部２１０は、その認証のためのアクセス先のデバイス（すなわちこの例ではモバイル機器３００の認証アプリ３１０）を特定するアクセス先情報を認証デバイス管理部２２０から取得し、そのアクセス先情報を用いてそのモバイル機器３００の認証アプリ３１０にアクセスし、認証要求を送る。その認証アプリ３１０でのユーザ認証が成功すると、認証アプリ３１０からモバイル機器アクセストークンが返される。
【００３７】
認証デバイス管理部２２０は、ユーザ情報ＤＢ（データベース）２２２を有する。ユーザ情報ＤＢ２２２には、図２に示すように、ユーザＩＤに対応付けて、そのユーザＩＤに対応するユーザを実際に認証する装置（モバイル機器３００又はその中の特に認証アプリ３１０）についてのアクセス先情報が登録されている。アクセス先情報は、各モバイル機器３００、又はこのモバイル機器３００にインストールされた認証アプリ３１０、を一意に識別する識別情報である。例えば、アクセス先情報としては、ＧＣＭ（Google Cloud Messaging）（Google、Google Cloud Messagingは商標）やＡＰＮＳ（Apple Push Notification Service）等のプッシュ通知サービスからモバイル機器３００又はこれにインストールされた認証アプリに付与された登録ＩＤやデバイストークン、を用いてもよい。また別の例として、モバイル機器３００の携帯電話番号と認証アプリ３１０のアプリ名との組み合わせをアクセス先情報として用いてもよい。ユーザ情報ＤＢ２２２には、各ユーザが、自分のモバイル機器３００の認証アプリ３１０を示すアクセス情報を設定する。
【００３８】
ユーザトークン管理部２３０には、トークン情報２３２が保持される。トークン情報２３２には、図２に示すように、機器認証要求部２１０がモバイル機器３００の認証アプリ３１０から受け取ったモバイル機器アクセストークンが含まれる。
【００３９】
ユーザ属性取得部２４０は、サービスプロバイダ１００のユーザ属性要求部１３０から属性要求に応じて、モバイル機器３００の認証アプリ３１０からその属性要求に係るユーザの属性情報を取得し、取得した属性情報をユーザ属性要求部１３０に提供する。
【００４０】
モバイル機器３００内のコンピュータは、インストールされている認証アプリ３１０を実行することで、ユーザ認証部３１２及びユーザ属性管理部３１６として機能する。ユーザ認証部３１２は、ＩＤプロバイダ２００の機器認証要求部２１０からの要求に応じてユーザ認証を実行する。ユーザ認証部３１２は、認証情報・対応サービスリスト３１４を管理している。認証情報・対応サービスリスト３１４は、ユーザの認証情報と、対応サービスリストとを含む。このうちの認証情報は、そのモバイル機器３００を持っているユーザの認証情報であり、例えばそのユーザのユーザＩＤとパスワードの組である。この認証情報は、そのユーザがＩＤプロバイダ２００に登録しているものであるが、ＩＤプロバイダ２００はその認証情報そのものは管理せず、その管理はそのユーザ自身のデバイス（モバイル機器３００）が担う。対応サービスリストは、その認証情報が対応しているサービスプロバイダ１００のリストである。すなわち、ユーザ認証部３１２は、対応サービスリストに含まれるサービスプロバイダ１００に対するユーザからの認証要求に対して、ユーザ認証を行う。
【００４１】
ユーザ属性管理部３１６は、モバイル機器３００を持つユーザの属性情報（ユーザ属性３１８）を管理する。ユーザ属性３１８には、例えば氏名、電子メールアドレス、電話番号、所属部署、役職等の項目が含まれる。ユーザ属性管理部３１６は、ＩＤプロバイダ２００のユーザ属性取得部２４０から要求に応じて、管理しているユーザ属性３１８中の、その要求の対象である項目の情報を提供する。
【００４２】
次に、図２を参照して、モバイル機器３００を持っているユーザが「サービスＸＹＺ」という識別名のサービスプロバイダ１００にログインする場合の、本システムの処理の流れを説明する。
【００４３】
（１）あるユーザＡＡＡは、ユーザ側装置３５０からサービスＸＹＺにアクセスし、ユーザＩＤ（「User-AAA」）とパスワード（ＰＷ）を含むログイン要求を送信する。この例では、ユーザＡＡＡは、直近のしばらくの間、ＩＤプロバイダ２００での認証を受けておらず、ＩＤプロバイダ２００にはユーザＡＡＡが認証済みであることを示す有効な情報（後述のモバイル機器アクセストークン）が保持されていないものとする。
【００４４】
（２）サービスＸＹＺのユーザ認証要求部１１０は、ユーザＡＡＡから受け取ったユーザＩＤとパスワードを含んだ認証要求を、ＩＤプロバイダ２００に送る。
【００４５】
なお、ユーザ認証要求部１１０は、ログインしていないユーザ（あるいは有効なサービスアクセストークンがサービストークン管理部１２０に保持されていないユーザ）からアクセスがあった際、そのアクセスを認証連携のプロトコルに従ってＩＤプロバイダ２００にリダイレクトしてもよい。この場合、ユーザは、ユーザＩＤとパスワードを含む認証要求をＩＤプロバイダ２００に直接入力することになり、サービスＸＹＺにはパスワードが知られない。
【００４６】
（３）ＩＤプロバイダ２００の機器認証要求部２１０は、ユーザＩＤとパスワードを含む認証要求を受け取ると、そのユーザＩＤに対応するアクセス先情報をユーザ情報ＤＢ２２２から求める。そして、そのアクセス先情報が示すモバイル機器３００の認証アプリ３１０に対して、そのユーザＩＤとパスワードを含む認証要求を送信する。なお、図示は省略したが、機器認証要求部２１０は、この認証要求の送信の前に、ユーザトークン管理部２３０内に、そのユーザＩＤに対応する有効なモバイル機器アクセストークン（後述）があるかを調べる。この例では、そのようなトークンがないので、認証アプリ３１０に認証要求を送信することになる。
【００４７】
（４）モバイル機器３００の認証アプリ３１０のユーザ認証部３１２は、ＩＤプロバイダ２００から受け取った認証要求に対してユーザ認証を行う。すなわち、その認証要求に含まれる認証情報、すなわちユーザＩＤとパスワードの組が、自身が保持している認証情報に合致しているかどうかを判定する。合致していると判定した場合はユーザ認証が成功（ＯＫ）であり、合致していないと判定した場合は、認証が失敗（ＮＧ）である。
【００４８】
なお、このときユーザ認証部３１２は、モバイル機器３００の出力装置（例えばディスプレイ）から、ユーザに対してサービスＸＹＺ（又はユーザ登録済のサービス）から認証が求められていることを通知し、認証を許可するかどうかをユーザに問い合わせてもよい。この場合、認証を許可しない旨の指示がユーザからあった場合には、ユーザ認証部３１２は仮にユーザの提示した認証情報が保持している認証情報に合致する場合でも、認証結果を失敗（ＮＧ）とする。ユーザから認証を許可する旨の指示があった場合には、ユーザ認証部３１２は、ユーザの提示した認証情報が保持している認証情報に合致するか否かに応じた認証結果を求める。
【００４９】
ユーザ認証が成功した場合、ユーザ認証部３１２は、当該モバイル機器３００についてのアクセストークン（図では「Token-Moble-AAA」と表記）を生成する。このアクセストークンをモバイル機器アクセストークンと呼ぶ。モバイル機器アクセストークンは、認証アプリ３１０がユーザを認証したことを証する情報である。ＩＤプロバイダ２００は、このモバイル機器アクセストークンを提示することで、認証アプリ３１０にアクセスすることができる（例えば、後述するユーザ属性取得の場合）。モバイル機器アクセストークンには有効期限の情報が含まれる。この有効期限は、例えば、そのトークンの生成の日時に対して、予め定められた時間を足した日時である。認証アプリ３１０は、ＩＤプロバイダ２００に提供したモバイル機器アクセストークンを（少なくともその有効期限までは）保管する。
【００５０】
またユーザ認証が成功した場合、ユーザ認証部３１２は、対応サービスリストから、そのユーザＩＤとパスワードの組に対応するサービスプロバイダ１００の識別情報（サービスＩＤと呼ぶ）を読み出す。対応サービスリストにその組に対応するサービスＩＤが複数含まれていれば、それら複数のサービスＩＤを読み出す。図示例では、対応サービスリストには、サービスＸＹＺ（サービスＩＤは「Service-XYZ」）とサービスＬＭＮ（同「Service-LMN」）が含まれているので、これら２つのサービスＩＤを読み出す。
【００５１】
そして、ユーザ認証部３１２は、読み出したサービスＩＤのリスト（「トークン発行許可サービス」）と、生成したモバイル機器アクセストークン「Token-Moble-AAA」と、を含んだ認証結果情報をＩＤプロバイダ２００に返す。
【００５２】
ユーザ認証が失敗した場合は、ユーザ認証部３１２は、その旨（認証ＮＧ）を示す認証結果情報をＩＤプロバイダ２００に返す。
【００５３】
（５）ＩＤプロバイダ２００の機器認証要求部２１０は、モバイル機器３００の認証アプリ３１０から認証結果情報を受け取ると、その認証結果情報に応じた認証結果をサービスＸＹＺのユーザ認証要求部１１０に返す。
【００５４】
すなわち、認証アプリ３１０からの認証結果が成功（ＯＫ）の場合（すなわちその認証結果にモバイル機器アクセストークンが含まれている場合）には、機器認証要求部２１０は、サービスアクセストークン（図では「Token-UserAAA」と表記）を生成する。サービスアクセストークンは、当該トークンの対象であるユーザが認証済みであることをＩＤプロバイダ２００が保証していることを示す情報である。また、サービスアクセストークンには有効期限（例えばその生成の日時に所定時間を足した日時）の情報が含まれる。機器認証要求部２１０は、そのサービスアクセストークンを含む認証結果をユーザ認証要求部１１０に返す。
【００５５】
また、認証アプリ３１０からの認証結果が失敗（ＮＧ）の場合、ユーザ認証要求部１１０には、サービスアクセストークンは返さず、単に認証失敗の旨を示す情報を返す。
【００５６】
また機器認証要求部２１０は、認証アプリ３１０からの認証結果にモバイル機器アクセストークンが含まれていた場合、ユーザ認証要求部１１０に対する認証結果の送信と並行して、ユーザトークン管理部２３０に対して、その認証結果に含まれるモバイル機器アクセストークンやトークン発行許可サービス等の情報を登録する。図示例では、ユーザトークン管理部２３０には、「ユーザＩＤ」、「サービス」、「モバイル機器アクセストークン」、及び「トークン発行許可サービス」の各項目が含まれる。「ユーザＩＤ」は、今回受け取ったモバイル機器アクセストークンの対象であるユーザ（すなわち認証対象のユーザ）のユーザＩＤ（図示例では「User-AAA」）である。「サービス」は、今回の認証要求を送ってきたサービスプロバイダ１００（図示例ではサービスＸＹＺ）の識別情報（図示例では「Service-XYZ」）である。「モバイル機器アクセストークン」は、認証アプリ３１０から応答されたモバイル機器アクセストークンのデータ（図示例では「Token-Mobile-AAA」）である。そして、「トークン発行許可サービス」は、そのモバイル機器アクセストークンと共に認証アプリ３１０から応答されたトークン発行許可サービスのリスト（図示例では「Service-XYZ」と「Service-LMN」である。また、図示は省略したが、ユーザトークン管理部２３０に登録したモバイル機器アクセストークンには有効期限の情報が含まれている。その有効期限が過ぎると、ＩＤプロバイダ２００は、例えば、そのエントリをユーザトークン管理部２３０から削除する。また図示は省略したが、ユーザトークン管理部２３０内の、ユーザＩＤに対応するモバイル機器アクセストークンのエントリには、そのトークンをもとに発行したサービスアクセストークンも記録される。
【００５７】
（６）サービスＸＹＺのユーザ認証要求部１１０は、ＩＤプロバイダ２００の機器認証要求部２１０からの認証結果が認証成功（ＯＫ）の場合は、その認証結果に含まれるサービスアクセストークンを、ログイン要求元のユーザのユーザＩＤと対応付けてサービストークン管理部１２０に登録する。このとき、そのサービスアクセストークンに対応付けて、そのサービスアクセストークンに設定された有効期限の情報も登録される。そして、ユーザ認証要求部１１０は、ログイン要求元のユーザＡＡＡ（ユーザ側装置３５０）のログインを許可する。以降サービスプロバイダ１００は、ユーザからの要求を受け付けて、その要求に応じたサービスを実行する。
【００５８】
またこのとき、ユーザ認証要求部１１０は、サービスアクセストークン又はこれに対応付けた情報、を含んだクッキー等のデータをユーザ側装置３５０に提供してもよい。ユーザ側装置３５０は、その後のサービスＸＹＺへのアクセスにはそのクッキー等のデータを提示することで、例えばサービスアクセストークンの有効期限が過ぎるまでは、再度のログイン処理等を行うことなく、サービスＸＹＺの利用許可を得る。
【００５９】
また、ユーザ認証要求部１１０は、ＩＤプロバイダ２００の機器認証要求部２１０からの認証結果が認証失敗（ＮＧ）の場合は、ユーザＡＡＡのログインを許可せず、ユーザ側装置３５０に対してログイン不可の旨の応答を返す。
【００６０】
図２は、認証が成功し、ユーザＡＡＡがサービスＸＹＺにログインした場合を示している。
【００６１】
なお、以上の例では、ユーザに対応する有効なサービスアクセストークンがサービスＸＹＺにあれば、ただちにそのユーザの再度のログインを認めたが、これは一例に過ぎない。別の例として、ログインを要求するユーザに対応する有効なサービスアクセストークンがサービスＸＹＺにある場合、サービスＸＹＺからＩＤプロバイダ２００にそのトークンの検証を求め、その検証の結果に応じてログインを許可するか否かを制御してもよい。すなわち、サービスＸＹＺは、ＩＤプロバイダ２００からサービスアクセストークンの検証が成功した旨の応答を受けた場合にはそのユーザのログインを許可し、そうでない場合はログインを拒絶する。
【００６２】
このようにサービスアクセストークンの有効性の検証をサービスＸＹＺで行うにせよＩＤプロバイダ２００で行うにせよ、サービスアクセストークンが有効であればユーザのモバイル機器３００（認証アプリ３１０）での認証を省略してもよい。このようにすれば、ＩＤプロバイダ２００等からモバイル機器３００にアクセスできない場合でも、ログインを認めるか否かの判定が可能になる。
【００６３】
次に、図３を参照して、ユーザＡＡＡのサービスＬＭＮへのログイン処理の流れを示す。この流れは、図２に示したユーザＡＡＡのサービスＸＹＺへのログイン成功の後、ＩＤプロバイダ２００に保持されたモバイル機器アクセストークン「Token-Mobile-AAA」の有効期限が過ぎる前に、ユーザＡＡＡがサービスＬＭＮにログインを要求した場合のものである。
【００６４】
（１）ユーザＡＡＡがサービスＬＭＮにログイン要求を行う。この時点では、サービスＬＭＮには、そのユーザＡＡＡに対応する有効なサービスアクセストークンが保持されていないとする。
【００６５】
（２）サービスＬＭＮのユーザ認証要求部１１０は、そのユーザＡＡＡの認証をＩＤプロバイダ２００に要求する。ユーザ認証要求部１１０が行う、ログイン要求の受け付け、及びＩＤプロバイダ２００への認証要求の処理は、図２のステップ（１）及び（２）と同様である。
【００６６】
（３）ＩＤプロバイダ２００の機器認証要求部２１０は、その認証要求内のユーザＩＤに対応する有効なモバイル機器アクセストークンがユーザトークン管理部２３０内にあるかどうかを調べる。図示例では、そのユーザＡＡＡに対応する有効なモバイル機器アクセストークン「Token-Mobile-AAA」が見つかる。機器認証要求部２１０は、ユーザトークン管理部２３０内の情報を参照して、見つけたモバイル機器アクセストークンに対応するトークン発行許可サービスに、認証要求の送信元であるサービスＬＭＮが含まれているかを判定する。図示例では、「Token-Mobile-AAA」のトークン発行許可サービスの中にサービスＬＭＮ（「Service-LMN」）が含まれている。また、機器認証要求部２１０は、見つけたモバイル機器アクセストークンの有効期限が過ぎていないことを確認する。図示例では、モバイル機器アクセストークン「Token-Mobile-AAA」の有効期限は過ぎていないとする。この場合、機器認証要求部２１０は、認証アプリ３１０に認証要求を送ることなく、サービスＬＭＮ向けのサービスアクセストークン（「Token-UserAAA’」）を生成する。
【００６７】
なお、認証要求に含まれるユーザＩＤに対応する有効なモバイル機器アクセストークンがユーザトークン管理部２３０から見つからなかった場合は、機器認証要求部２１０は、その認証要求をモバイル機器３００の認証アプリ３１０に転送し、認証を求める（上述の図２の例）。
【００６８】
（４）機器認証要求部２１０は、生成したサービスＬＭＮ向けのサービスアクセストークン「Token-UserAAA’」を含む認証結果をサービスＬＭＮのユーザ認証要求部１１０に応答する。
【００６９】
（５）この応答を受けたユーザ認証要求部１１０は、その認証結果に含まれるサービスアクセストークン「Token-UserAAA’」をサービストークン管理部１２０に登録すると共に、ログイン要求元のユーザＡＡＡ（ユーザ側装置３５０）のログインを許可する。
【００７０】
図３の例では、ＩＤプロバイダ２００は、モバイル機器３００から受け取ったモバイル機器アクセストークンが有効な間は、そのトークンに対応するトークン発行許可サービスからの認証要求に対し、そのトークンの権限でサービスアクセストークンを発行する。このため、モバイル機器アクセストークンが有効な間は、モバイル機器３００の認証アプリ３１０に対する認証要求が省略される。この点は、図２に示したログインの後サービスＸＹＺからログアウトしたユーザＡＡＡが、モバイル機器アクセストークン「Token-Mobile-AAA」が有効な間に再度サービスＸＹＺにログインする場合もの同様である。
【００７１】
以上の例では、モバイル機器アクセストークン「Token-Mobile-AAA」が有効な間は、ＩＤプロバイダ２００は、ユーザＡＡＡの認証アプリ３１０にアクセスせずに、サービスプロバイダ１００からの認証要求に応答した。別の例として、モバイル機器アクセストークン「Token-Mobile-AAA」が有効な間でも、ユーザＡＡＡの認証アプリ３１０にアクセスできる場合は、ＩＤプロバイダ２００はその認証アプリ３１０にアクセスして認証要求を行ってもよい。これにより、ユーザＡＡＡの認証アプリ３１０で設定変更が行われた場合でも、できるだけ最新の設定に沿った認証が行われることになる。例えば、ユーザＡＡＡが認証アプリ３１０に対して、いずれかのサービスプロバイダ１００を対応サービスリストから削除する場合があり、アクセス可能な限り認証アプリ３１０に認証を求めることで、そのような設定変更に迅速な対処がなされる。なお、このようにモバイル機器アクセストークンが有効な間に、そのトークンの発行元の認証アプリ３１０に再度認証を依頼してこれが成功した場合、新たなモバイル機器アクセストークンを含む認証結果がその発行元から提供される。この場合、ＩＤプロバイダ２００は、ユーザトークン管理部２３０内の元のモバイル機器アクセストークンを、新たに提供されたものに更新し、トークン発行許可サービスの情報も新たに提供されたものに更新する。
【００７２】
以上に説明した図２及び図３の処理では、サービスプロバイダ１００へのログインを要求するユーザに、最初にユーザＩＤとパスワードの両方を入力させたが、この代わりにユーザが最初に入力する情報をユーザＩＤのみとしてもよい。この場合、機器認証要求部２１０は、入力されたユーザＩＤに対応し、且つそのサービスプロバイダ１００を「トークン発行許可サービス」に含んだ、有効なモバイル機器アクセストークンがユーザトークン管理部２３０内にあるかどうかを判定する。もしあれば、機器認証要求部２１０は、ユーザにパスワードの入力を求めることなく、そのサービスプロバイダ１００に対して、そのモバイル機器アクセストークンに基づくサービスアクセストークンを提供する。また、そのような条件に合致するモバイル機器アクセストークンがユーザトークン管理部２３０にない場合には、機器認証要求部２１０は、直接またはサービスプロバイダ１００のユーザ認証要求部１１０経由で、ユーザにパスワードの入力を求め、そのパスワードとユーザＩＤをそのユーザのモバイル機器３００に送って認証を求める。
【００７３】
次に、図２に示したユーザＡＡＡのサービスＸＹＺへのログイン成功の後、ユーザＡＡＡがサービスＸＹＺに対して、そのユーザの属性情報を必要とするサービスを要求した場合の処理の流れを、図４を参照して説明する。この例では、サービスＸＹＺに保持されたユーザＡＡＡのサービスアクセストークン「Token-UserAAA」の有効期限は過ぎていないものとする。
【００７４】
（１）ユーザＡＡＡは、ログインしているサービスＸＹＺに対してある処理の実行を要求する。この処理が、ユーザＡＡＡのある属性（例えば電子メールアドレス）を必要とする処理であったとする。
【００７５】
（２）サービスＸＹＺのユーザ属性要求部１３０は、ユーザＡＡＡに対応する有効なサービスアクセストークン「Token-UserAAA」をサービストークン管理部１２０から取得し、このトークンを含んだユーザ属性要求をＩＤプロバイダ２００に送信する。このユーザ属性要求には、要求する属性項目（例えば電子メールアドレス）を特定する要求項目情報を含めてもよい。また、このユーザ属性要求には、要求元であるサービスＸＹＺのサービスＩＤ「Service-XYZ」を含めてもよい。
【００７６】
（３）ユーザ属性要求を受け取ったＩＤプロバイダ２００のユーザ属性取得部２４０は、その要求に含まれるサービスアクセストークン「Token-UserAAA」の有効性を検証する。この検証は、認証連携分野での一般的なトークンの検証と同様でよい。例えば、改ざんがないこと、ＩＤプロバイダ２００自身が発行したものであること、発行した記録があること、有効期限が過ぎていないこと等を確認する。検証の結果、有効でないことが分かった場合、ユーザ属性取得部２４０は、サービスＸＹＺに対して属性取得権限がない旨を示すエラー応答を返す。
【００７７】
検証の結果、ユーザ属性要求中のサービスアクセストークン「Token-UserAAA」が有効である場合、ユーザ属性取得部２４０は、そのトークン「Token-UserAAA」に対応するユーザの有効なモバイル機器アクセストークン「Token-Mobile-AAA」をユーザトークン管理部２３０から取得する。また、そのユーザのアクセス先情報をユーザ情報ＤＢ２２２から取得する。
【００７８】
そして、そのアクセス先情報を用いて、ユーザＡＡＡのモバイル機器３００の認証アプリ３１０に対して、そのモバイル機器アクセストークン「Token-Mobile-AAA」を含んだユーザ属性要求を送信する。この要求には、要求する属性項目を特定する要求項目情報や、その属性を要求しているサービスＸＹＺのサービスＩＤ「Service-XYZ」を含めてもよい。
【００７９】
（４）認証アプリ３１０のユーザ属性管理部３１６は、ＩＤプロバイダ２００からユーザ属性要求を受け取ると、その中に含まれるモバイル機器アクセストークンの有効性を検証する。この検証は、認証連携分野での一般的なトークンの検証と同様でよい。
【００８０】
検証の結果、そのトークンが有効でないことが分かった場合、ユーザ属性管理部３１６は、ＩＤプロバイダ２００に対して、属性提供ができない旨を示す応答を返す。
【００８１】
検証の結果、そのトークンが有効であることが分かった場合、ユーザ属性管理部３１６は、管理しているユーザ属性３１８をＩＤプロバイダ２００に送信する。１つの例では、ユーザ属性要求はユーザの全属性を要求するものであり、ユーザ属性管理部３１６は、その要求に対して、保持しているユーザ属性３１８の全部を送信する。別の例では、ユーザ属性要求には、サービスＸＹＺが要求する属性項目を特定する要求項目情報が含まれている場合、ユーザ属性３１８のうちその要求項目情報が示す属性項目の値のみをＩＤプロバイダ２００に送信する。また、ユーザが、ユーザ属性管理部３１６に対して、サービスプロバイダ１００ごとに、そのサービスプロバイダ１００に開示してよい属性項目を予め設定しておいてもよい。この場合、ユーザ属性管理部３１６は、ＩＤプロバイダ２００からのユーザ属性要求に対して、その要求の要求元のサービスプロバイダ１００に開示してよい属性項目のすべて、またはそのうちユーザ属性要求が要求する項目のみ、ＩＤプロバイダ２００に送信する。
【００８２】
（５）ＩＤプロバイダ２００のユーザ属性取得部２４０は、認証アプリ３１０から送信されたユーザ属性を、要求元のサービスＸＹＺに応答する。
【００８３】
（６）サービスＸＹＺのユーザ属性要求部１３０は、ＩＤプロバイダ２００から受け取ったユーザ属性の情報を用いて、ユーザＡＡＡが要求した処理を実行する。
【００８４】
なお、ＩＤプロバイダ２００のユーザ属性取得部２４０は、認証アプリ３１０から取得したユーザ属性３１８の情報を予め定めた期間だけ保存（キャッシュ）してもよい。この場合、ユーザ属性取得部２４０は、その期間にサービスＸＹＺからのユーザ属性要求を受けた場合、認証アプリ３１０に要求を行わず、保存している情報を用いてその要求に応答してもよい。また、サービスＸＹＺからのユーザ属性要求に対して、ユーザ属性取得部２４０が保存（キャッシュ）しているユーザ属性を用いて応答するのを、当該ユーザのモバイル機器３００からユーザ属性が取得できない場合（例えば通信ができない場合）に限定してもよい。モバイル機器３００からユーザ属性が取得できる場合は、モバイル機器３００から最新のユーザ属性を取得し、取得したユーザ属性をサービスＸＹＺに提供する。
【００８５】
このシステムでは、ユーザの属性情報は、そのユーザのモバイル機器３００で一括管理する。ＩＤプロバイダ２００は、そのユーザの属性情報を一時的にキャッシュすることはあるかも知れないが、属性情報のオリジナルはあくまでモバイル機器３００内のものである。したがって、ユーザが利用するＩＤプロバイダ２００が複数あるような状況でも、そのユーザは、自分の属性情報を自分のモバイル機器３００に登録し、正しく保守しておけば足りる。様々なサービスがそれらいずれのＩＤプロバイダ２００にユーザの属性を要求したとしても、それらＩＤプロバイダ２００はそのユーザのモバイル機器３００からその属性を取得してそのサービスに提供するからである。個々のＩＤプロバイダ２００にユーザの属性情報を登録する方式では、ユーザ属性に変更が生じた場合、ユーザはそれらすべてのＩＤプロバイダ２００に登録した自分の属性情報に必要な変更を行う必要がある。これに対し、このシステムでは、ユーザはモバイル機器３００内に登録したユーザ属性情報を変更するだけでよい。
【００８６】
以上では、ユーザの認証を実際に担当する認証装置がモバイル機器３００であるとしたが、これは一例に過ぎない。その認証装置は、例えば携帯型ではないユーザのパーソナルコンピュータであってもよい。
【００８７】
次に、図５を参照して、ＩＤプロバイダ２００の機器認証要求部２１０の処理手順の一例を説明する。この手順は、図２及び図３を用いて例示した処理の流れの１つのバリエーションである。
【００８８】
機器認証要求部２１０は、サービスプロバイダ１００からユーザ認証の要求を受け、認証対象のユーザが入力したユーザＩＤ及びパスワードを取得する（Ｓ１０）。次に機器認証要求部２１０は、取得したユーザＩＤに対応するアクセス先情報をユーザ情報ＤＢ２２２から求め、そのアクセス先情報を用いて、そのユーザのモバイル機器３００の認証アプリ３１０にアクセスを試みる（Ｓ１２）。このアクセスが成功した場合（Ｓ１４の判定結果がＹｅｓ）、アクセス先の認証アプリ３１０にユーザＩＤ及びパスワードを渡して認証を要求し（Ｓ１６）、この要求に対する認証結果情報を認証アプリ３１０から取得する（Ｓ１８）。そして、その認証結果情報の内容（ＯＫ／ＮＧ）に応じた認証結果をサービスプロバイダ１００に返す（Ｓ２０）と共に、認証結果情報にモバイル機器アクセストークン等の情報が含まれる場合、その情報をユーザトークン管理部２３０に登録する。
【００８９】
Ｓ１２でアクセス先の認証アプリ３１０にアクセスできなかった場合（Ｓ１４の判定結果がＮｏ）、機器認証要求部２１０は、そのユーザＩＤに対応する有効期限が過ぎていないモバイル機器アクセストークンがユーザトークン管理部２３０内にあるかどうかを調べる（Ｓ２２）。もしあれば（Ｓ２２の判定結果がＹｅｓ）、機器認証要求部２１０は、そのモバイル機器アクセストークンの「トークン発行許可サービス」（例えば図２参照）にそのサービスプロバイダ１００が含まれているかどうかを調べる。そして、含まれていれば認証成功とし、サービスアクセストークンを含む認証成功（ＯＫ）の認証結果をそのサービスプロバイダ１００に返す（Ｓ２４）。また、「トークン発行許可サービス」にそのサービスプロバイダ１００が含まれていない場合は、認証失敗（ＮＧ）を示す認証結果をそのサービスプロバイダ１００に返す（Ｓ２４）。
【００９０】
Ｓ２２で、認証対象のユーザＩＤに対応するモバイル機器アクセストークンがユーザトークン管理部２３０にない場合、機器認証要求部２１０は、ユーザが登録した認証用デバイス（モバイル機器３００）にアクセスできないためユーザ認証ができないこと、そのデバイスの状態を確認の上再度ログインを行うこと、等を表すメッセージ（例えばそのメッセージを含むウェブページ）をユーザ（図２等のユーザ側装置３５０）に通知する。この通知は、サービスプロバイダ１００経由で行ってもよいし（ユーザＩＤ、パスワードをサービスプロバイダ１００から取得した場合）、ＩＤプロバイダ２００から直接行ってもよい（サービスプロバイダ１００からのリダイレクトによりＩＤプロバイダ２００が直接ユーザからユーザＩＤ、パスワードの入力を受けた場合）。ユーザのモバイル機器３００の電源がオフされている等の理由で認証ができなかった場合、このメッセージに応じてユーザがモバイル機器３００を起動した上で、ユーザ側装置３５０からサービスプロバイダ１００に再度ログインを要求すれば、今度はそのモバイル機器３００で認証がなされることとなる。
【００９１】
以上、図５を参照してＩＤプロバイダ２００の機器認証要求部２１０の処理手順を例示したが、ＩＤプロバイダ２００のユーザ属性取得部２４０も、同様の枠組みで処理を行えばよい。すなわち、サービスプロバイダ１００からユーザの属性情報を要求された場合、ユーザ属性取得部２４０は、そのユーザのモバイル機器３００にアクセスできるならば、仮に過去に取得したそのユーザの属性情報が持っていたとしても、モバイル機器３００から最新の属性情報を取得してサービスプロバイダ１００に提供する。そして、モバイル機器３００にアクセスできない場合には、過去に取得したそのユーザの属性情報が持っていれば、その属性情報を用いてサービスプロバイダ１００に応答する。
【００９２】
以上説明したように、本実施形態では、ＩＤプロバイダ２００は、ネットワーク上の多くのサービスプロバイダ１００に対して、ユーザ認証の要求やユーザ属性の取得要求を受け付ける窓口として機能する。実際のユーザ認証やユーザ属性の提供は、ＩＤプロバイダ２００に登録された個々のユーザの認証アプリ３１０が行う。このため、仮にＩＤプロバイダ２００がハッキングされたとしても、漏洩するのは各ユーザのアクセス先情報だけであり、多くのユーザのユーザＩＤ、パスワード、ユーザ属性等がまとめて漏洩することはない。また、ユーザが、自分のモバイル機器３００の認証アプリ３１０に登録したパスワードやユーザ属性を変更すれば、その変更が連携するすべてのサービスプロバイダ１００に適用されることとなる。
【００９３】
以上、本発明の実施形態を説明した。以上に例示したＩＤプロバイダ２００は、コンピュータにＩＤプロバイダ２００の上述の機能を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、フラッシュメモリやＳＳＤ（ソリッドステートドライブ）、ＨＤＤ（ハードディスクドライブ）や等の固定記憶装置を制御するコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバス等を介して接続された回路構成を有する。それら各機能の処理内容が記述されたプログラムがネットワーク等の経由でフラッシュメモリ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
【符号の説明】
【００９４】
１００  サービスプロバイダ、１１０  ユーザ認証要求部、１２０  サービストークン管理部、１３０  ユーザ属性要求部、２００  ＩＤプロバイダ、２１０  機器認証要求部、２２０  認証デバイス管理部、２３０  ユーザトークン管理部、２３２  トークン情報、２４０  ユーザ属性取得部、３００  モバイル機器、３１０  認証アプリ、３１２  ユーザ認証部、３１４  認証情報・対応サービスリスト、３１６  ユーザ属性管理部、３１８  ユーザ属性、３５０  ユーザ側装置。
【図１】
2018037025.tif 000003
【図２】
2018037025.tif 000004
【図３】
2018037025.tif 000005
【図４】
2018037025.tif 000006
【図５】
2018037025.tif 000007