JP2016071478A - 他社認証を利用したセキュリティ強化のための認証システム、認証方法、及び認証プログラム - Google Patents

Abstract

【課題】大幅なコストをかけることなく、セキュリティ強化を図ることができる認証システムを提供する。【解決手段】認証システムは、顧客から自社の認証情報を受領し、自社にて認証判定を実施する。次に、自社の認証判定がＯＫの場合は、他社の認証を利用することが登録されているかどうかを確認する。他社の認証登録がある場合、他社の認証情報を入力させる画面を顧客に提示し、顧客から他社の認証情報を受領する。そして、受領した他社認証情報を他社にて認証判定させ、その認証判定がＯＫであれば、その顧客の認証をＯＫとする。他社の登録が複数ある場合は、ランダムに他社を選択するか、認証方式が自社と異なる他社を選択するか、評価点数が自社より高い認証方式を採用している他社を選択する。【選択図】図１

Description

本発明は、セキュリティを強化するための認証システムに関する。特に、多重認証によるセキュリティ強化のための認証システムに関する。

従来から、ネットワーク上のサービスへアクセスする際、利用者を認証するために、ＩＤとパスワードを用いる方法が広く用いられている。しかし、ＩＤとパスワードによる認証だけでは、そのＩＤとパスワードが第三者に知られてしまうと不正利用される危険性が高い。そのため、ＩＤとパスワードの認証だけでなく、さらにセキュリティを強化する認証方式が多数知られている（例えば、特許文献１、２等）。

特開２０１３−２５０９２４号公報 特開２０１３−２５７８５９号公報

しかしながら、セキュリティ強化のための認証方式の変更は、企業側のコスト負担（システム開発、顧客へのアナウンス、セキュリティ機器の配付等）が大きい。そのため、堅牢なセキュリティを構築しているのは、メガバンク等の一部の大企業や政府機関に留まっているのが現状である。

また、企業や組織ごとに異なる認証方式、あるいは同一企業間でも取引やサービスごとに異なる認証方式を採用していることが多いため、顧客側の負担も大きい。一方で、サービスの不正利用、機密情報の漏洩、個人情報の流出等が昨今相次いでいることから、セキュリティを強化したいという企業や団体側のニーズ、あるいはセキュリティを強化してほしいという顧客のニーズは確実に存在する。

したがって、本発明では、上記のような課題に鑑み、企業等が大幅なコストをかけることなく、セキュリティ強化を図ることができる認証システムを提供することを目的とする。

上記課題を解決するため、本発明の認証システムは、以下のような解決手段を提供する。

本発明の認証システムは、利用者の端末から前記利用者の認証情報を取得し、自社システムで認証を行う第１認証部と、前記自社システムでの認証が正常である場合に、登録された他社システムの認証情報入力画面を前記利用者の端末に表示し、前記認証情報入力画面から入力された他社認証情報を取得する他社認証情報取得部と、前記取得された他社認証情報を前記他社システムに送信し、前記他社システムでの認証を要求する他社システム連携部と、前記自社システム及び前記他社システムの認証の結果が共に正常である場合に、前記利用者を正規の利用者であると認証する第２認証部と、を備えたことを特徴とする。

また、上記認証システムにおいて、前記第１認証部は、前記自社システムでの認証が正常であって、かつ前記登録された他社が複数ある場合に、ランダムに他社を選択するようにしてもよい。

また、上記認証システムにおいて、前記第１認証部は、前記自社システムでの認証が正常であって、かつ前記登録された他社が複数ある場合に、認証方式が異なる他社を選択するようにしてもよい。

また、上記認証システムにおいて、前記第１認証部は、前記自社システムでの認証が正常であって、かつ前記登録された他社が複数ある場合に、認証方式に対して定められた点数が自社よりも高い他社を選択するようにしてもよい。

また、上記認証システムにおいて、前記他社認証情報取得部は、前記第１認証部が選択した他社が複数ある場合に、当該複数の他社の認証情報入力画面を１画面にして前記利用者の端末に表示し、それぞれの他社認証情報を一度に入力させるようにしてもよい。

また、本発明を認証方法の発明として捉えれば、利用者の端末から前記利用者の認証情報を取得し、自社システムで認証を行うステップと、前記自社システムでの認証が正常である場合に、登録された他社システムの認証情報入力画面を前記利用者の端末に表示し、前記認証情報入力画面から入力された他社認証情報を取得するステップと、前記取得された他社認証情報を前記他社システムに送信し、前記他社システムでの認証を要求するステップと、前記自社システム及び前記他社システムの認証の結果が共に正常である場合に、前記利用者を正規の利用者であると認証するステップと、を実行することを特徴とする。

また、本発明を認証プログラムの発明として捉えれば、利用者の端末から前記利用者の認証情報を取得し、自社システムで認証を行うステップと、前記自社システムでの認証が正常である場合に、登録された他社システムの認証情報入力画面を前記利用者の端末に表示し、前記認証情報入力画面から入力された他社認証情報を取得するステップと、前記取得された他社認証情報を前記他社システムに送信し、前記他社システムでの認証を要求するステップと、前記自社システム及び前記他社システムの認証の結果が共に正常である場合に、前記利用者を正規の利用者であると認証するステップと、をコンピュータに実行させることを特徴とする。

本発明によれば、企業等が大幅なコストをかけることなく、セキュリティ強化を図ることができる認証システムを提供することができる。

本発明の実施形態に係る認証システムの基本概念を示す図である。 本発明の実施形態に係る認証システムの機能構成を示す図である。 本発明の実施形態に係る顧客情報ＤＢ及び登録他社情報ＤＢのデータ構造の一例を示す図である。 本発明の実施形態に係る認証タイプ及びパスワードタイプの具体例を示す図である。 本発明の実施形態に係る自社システム２００における処理フローを示す図である。 本発明の実施形態に係る認証情報入力画面及び他社認証情報入力画面の具体例を示す図である。 本発明の実施形態に係る認証情報入力画面及び他社認証情報入力画面の別の具体例を示す図である。

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。また、機能構成の図において、機能ブロック間の矢印は、データの流れ方向、又は処理の流れ方向を表している。

（基本概念）
図１は、本発明の実施形態に係る認証システム（以下、本システムと呼ぶ）の基本概念を示す図である。図中の丸数字は、ステップ（処理）の順序を表している。顧客（利用者）は、自らの所持する端末、又はサービス提供者の店舗等に設置されている端末（以下、両者を合わせて顧客端末と呼ぶ）を使って、必要とするサービスのシステムにアクセスする。このとき、サービスを提供する企業やその他団体等の事業者のシステム（以下、自社システムと呼ぶ）は、自社の認証情報入力画面を顧客端末に表示し、顧客は、この認証画面からログインＩＤ（ユーザＩＤや顧客番号等、登録された利用者固有の識別子）とパスワードや暗証番号等の認証情報を入力する（ステップ１）。そして、自社システムの認証手段（認証部）は、顧客から入力された認証情報と、自社の顧客情報データベースに登録された認証情報と照合して認証判定を行う（ステップ２）。この認証判定が完了すると、顧客はサービスの提供を受けることができる。ここまでは一般的な認証判定の流れである。

本システムでは、上記の認証判定の後、サービスを提供する前に、さらに以下の処理を行う。すなわち、認証判定がＯＫでかつ、他社認証がある顧客には、その他社の認証情報入力画面を顧客端末に表示する（ステップ３）。ここで、他社認証がある顧客とは、他社（他の企業、団体）のサービスを利用しており、その他社のサービスを受けるためのＩＤを、自社システムに登録している顧客のことを言う。例えば、自社がＡ社であり、他社がＢ社であるとすると、Ａ社のログインＩＤはもちろん、Ｂ社の識別情報とＢ社におけるログインＩＤを、Ａ社のシステムに登録している顧客である。ここで登録するのはＢ社のログインＩＤだけで、Ｂ社のパスワードや暗証番号（以下、特にことわらない限り、両者を合わせて単にパスワード又はＰＷと呼ぶ）を登録する必要はない。

顧客は、表示された他社認証情報入力画面から、他社に登録している他社認証情報を入力する（ステップ４）。そして、自社システムの認証手段は、入力された他社認証情報を、自社の顧客情報（例えば、顧客ＩＤ若しくはログインＩＤ、又は顧客の氏名及び生年月日等の識別情報）と共に、当該他社のシステム（以下、他社システムと呼ぶ）の認証手段に送信する（ステップ５）。他社システムの認証手段は、送信された顧客情報に対応するログインＩＤを抽出し、送信された他社認証情報に基づいて、他社システム内において認証判定を行う（ステップ６）。そして、その認証判定の結果を自社システムに返信する（ステップ７）。

ここで、自社システムと他社システムの認証手段は、互いに連携しており、同じ顧客に対して、それぞれのＩＤが関連付けられ（対応付けられ）、顧客情報データベースに格納している。図１では、Ａ社ＩＤ（Ａ社のログインＩＤ）とＢ社ＩＤ（Ｂ社のログインＩＤ）が両社で共有され、顧客情報に格納されていることを示している。あるいは、顧客ＩＤ自体を両社で共有するようにしてもよい。ただし、パスワード（ＰＷ）は共有しないことが望ましい。

最後に、自社システムの認証手段は、他社システムから認証結果の返信を受けると、その認証結果を顧客端末に提示する（ステップ８）。このとき、自社システムの認証判定がＯＫであって、かつ他社システムの認証結果がＯＫであれば、自社システムのサービスへのアクセスが許可される。すなわち、自社システムと他社システムとで二重認証を行い、両者の認証が共にＯＫである場合に正規の顧客であると判定する。

顧客がＢ社のサービスを受ける場合も、上記のＡ社とＢ社が入れ替わるだけで、まったく同様である。このようにすることで、Ａ社とＢ社は、共に顧客認証におけるセキュリティを強化することができる。また、Ａ社、Ｂ社とも既存の認証手段を連携させるだけなので、大きなコスト負担が発生することはない。また、連携する情報は、顧客のＩＤ等の最小限のものなので、個人情報の流失等の危険性も少ない。

また、顧客にとっては、二重認証の負担は増えるものの、既に登録している会社のログイン画面が追加で表示されるだけなので、新たなＩＤやパスワードを覚える必要はない。また、顧客が多くの会社のＩＤやパスワードを所持している場合、それぞれのＩＤやパスワードのリマインド手段としても利用できる。

なお、登録する他社は１社である必要はなく複数であってもよい。その場合は、登録された他社のうちからランダムに、又は予め設定された方法により１社又は数社（２社程度が望ましい）を本システムが選択する。登録された複数の他社から１社又は数社を選択する方法については後述する。

（機能構成）
図２は、本システムの機能構成の詳細を示す図である。以下では、自社システムの機能構成について説明するが、他社システムの機能構成もまったく同様である。図示する自社システム２００は、顧客端末１００と、他社システム３００とに、インターネット等のネットワークを介して接続されている。

自社システム２００は、顧客情報を格納したデータベースである顧客情報ＤＢ２１０と登録他社の情報を格納したデータベースである登録他社情報ＤＢ２２０を備えている。また、自社システム２００は、処理部としては、主に、登録手段２３０と認証手段２４０で構成され、認証手段２４０は、さらに、自社認証情報取得部２４１、第１認証部２４２、他社システム連携部２４３、他社認証情報取得部２４４、第２認証部２４５に分けられる。以下、各機能ブロックについて順に説明する。

顧客情報ＤＢ２１０は、自社の顧客の情報を格納したデータベースであるが、本システムで扱う情報は、顧客ＩＤと、ログインＩＤ、パスワード等の認証情報だけである。顧客ＩＤは、自社内で顧客を唯一に識別する識別子であり、一般的には変更されることはない。一方、ログインＩＤは、顧客が自由に設定可能で、変更が可能である場合もある。

登録他社情報ＤＢ２２０は、認証手段を連携する契約を結んだ登録他社の情報を格納したデータベースである。登録他社情報ＤＢ２２０は、会社ごとに識別子（会社ＩＤと呼ぶ）が付与され、後述するような認証に関する情報が格納される。顧客は、登録他社の中から自らがサービスを利用している事業者を選択し、他社認証として使用することを同意しているものとする。

図３は、この顧客情報ＤＢ２１０及び登録他社情報ＤＢ２２０のデータ構造の一例を示す図である。顧客情報ＤＢ２１０には、顧客ＩＤごとに、自社（Ａ社とする）の認証情報（ログインＩＤ、パスワード等）と、他社認証サービスあり／なしの情報（他社認証サービスを希望するか否かの情報）と、他社認証サービスありの場合、その他社のログインＩＤと共に、他社の登録情報とが格納される。登録する他社は、顧客がいつでも追加、削除が可能とする。他社の登録情報は、図示するように、登録他社情報ＤＢ２２０にリンクするようにしてもよい。

この登録他社情報ＤＢ２２０を図３下段に示す。登録他社情報ＤＢ２２０には、他社の識別子である会社ＩＤ（事業者ＩＤ）ごとに、その会社の認証サイトのＵＲＬが格納され、その会社の認証方式、堅牢性ランクが格納される。サービス毎に認証方式を変更している場合は、サービスごとに、認証方式、堅牢性ランクが格納される。ここでいう認証方式とは、認証タイプとパスワードのタイプの組合せのことであり、詳しくは図４で後述する。また、堅牢性ランクとは、その認証方式の堅牢性を示すための数値であり、堅牢性の高い認証方式には高いランクが付与される。

図４は、この認証タイプ及びパスワードタイプの具体例を示す図である。認証タイプとは、そのような情報の組合せを認証情報として採用しているかを、タイプとして表したものである。例えば、タイプ１は、ＩＤとパスワードのみを用いているもの、タイプ２は、第１のＩＤとパスワードに加え、第２のＩＤとしてお客様番号や契約番号等を用いているもの、タイプ３は、ＩＤとパスワードに加え、スパイウェア対策として、図形を画面上で所定の位置にドラッグすることを用いているもの、タイプ４は、パスワードを複数要求するものであり、例えば、主パスワード以外にも、補助パスワードとして、乱数表を用いているもの、合言葉（秘密の言葉）等を用いているもの等がある。

パスワードタイプとは、パスワードとして使用される形式のルール（パスワードポリシー）であり、大きくは固定パスワード、ワンタイムパスワードに分かれるが、パスワードに使われる文字種の組合せ、最小文字数（桁数）等によってもタイプが分けられる。また、ソウトウェアキーボードの使用あり／なし等を考慮してもよい。

図３の登録他社情報ＤＢ２２０の堅牢性ランクは、認証方式の評価点数に基づいて、自動的に計算することができる。すなわち、上記の認証タイプとパスワードタイプに対して、それぞれ評価点数を定義しておくことで、例えば、図４右側のように点数を定めた場合、認証タイプがタイプ１（ＩＤとパスワードのみ）で、パスワードが数字又はアルファベットのみ、かつ最小文字数（桁数）が６の場合は、認証方式の点数は、１点＋１点＋０．２点×６＝３．２点となる。また、認証タイプがタイプ４（複数のパスワード）で、かつパスワードタイプがワンタイムパスワードの場合は、認証方式の点数は、１０点＋１０点＝２０点となる。そして、堅牢性ランクとして、０〜５点未満をランク１とし、５点以上１０点未満をランク２とし、１０点以上１５点未満をランク３とし、１５点以上２０点未満をランク４とし、２０点以上はランク５とする等としてもよい。

図２に戻り、その他の機能ブロックの説明を続ける。登録手段２３０は、顧客端末１００を介して、顧客の登録情報を受け付け、顧客情報ＤＢ２１０に格納する。新規顧客の場合は、必要な登録情報を入力させる。ここで登録する情報は、一般的には、顧客の個人情報（住所、氏名、電話番号、メールアドレス等の他、性別、年齢、職業等のプロフィール情報が加わることもある）と、顧客が選択したログインＩＤやパスワード等の認証情報である。

また、登録手段２３０は、登録他社の情報を登録他社情報ＤＢ２２０に格納する手段としても機能させてよい。この場合、自社のシステム管理者が他社の情報を入力して登録するものとするが、他社の登録情報に変更が生じた場合には、他社システム３００からその情報を取得するようにしてもよい。また、顧客からデータベースに登録されていない事業者の登録要求を受け付ける手段として機能させてもよい。

認証手段２４０は、図示するような機能ブロックにさらに分けられる。ただし、このような機能構成に限定されるものではない。

自社認証情報取得部２４１は、自社のシステムにアクセスしてきた登録顧客（登録ユーザ）に対して、自社の認証情報入力画面を顧客端末１００に表示させ、顧客が入力した自社の認証情報を取得する。

第１認証部２４２は、自社認証情報取得部２４１が取得した認証情報を顧客情報ＤＢ２１０に登録された認証情報と照合し、自社内の認証判定を行う。そして、自社の認証がＯＫであり、かつ顧客が他社認証のサービスを受けることを登録している場合は、その他社を特定する。他社が複数登録されている場合は、システムの設定により、他社を１以上（１〜２社程度が望ましい）選択する。登録された複数の他社から１社又は数社を選択する方法については後述する。なお、顧客が他社認証を希望しない場合、又は希望しているにも関わらず他社を登録していない場合は、自社の認証判定のみで認証がなされる。

他社システム連携部２４３は、第１認証部２４２によって他社認証として特定された他社がある場合に、登録他社情報ＤＢ２２０を読出し、その他社のシステムと連携させる。具体的には、自社のログインＩＤと、自社のログインＩＤに関連付けられた他社のログインＩＤを他社システム３００に送信し、他社システム３００での認証情報入力画面の送信を要求する。ただし、認証情報入力画面の送信を要求するタイミングは、その都度行ってもよいし、認証情報入力画面の変更があったことを通知し合い、変更があった場合にのみ自社システムで保存している他社の認証情報入力画面を更新するようにしてもよい。また、ＩＤとパスワードだけのような単純な認証情報の場合には、認証情報入力画面を他社から取得せずとも自社システム内で同様な画面を構成するようにしてもよい。

他社認証情報取得部２４４は、他社システム連携部２４３を介して、他社の認証情報入力画面を取得し、顧客端末１００に表示させる。そして、顧客に他社の認証情報を入力させ、取得した他社の認証情報を、他社システム連携部２４３を介して、他社システム３００に送信する。

また、他社認証情報取得部２４４は、第１認証部２４２が選択した他社が複数ある場合には、当該複数の他社の認証情報入力画面をマージして１画面として顧客端末１００に表示し、それぞれの他社認証情報を顧客に一度に入力させるようにしてもよい。そして、入力された複数の他社認証情報は、他社システム連携部２４３を介して、並行して該当する他社システム３００に送信され、それぞれの認証判定結果も並行して受信できるようにする。他社認証情報入力画面が複数あると、そのたびに認証情報の入力とその認証結果の提示を繰り返すことになり、煩わしいからである。

第２認証部２４５は、他社システム連携部２４３を介して、他社システム３００から認証結果を取得し、顧客端末１００に表示させる。自社認証及び他社認証が共にＯＫであった場合には、正規顧客と認定する。自社認証がＯＫであっても、他社認証がＮＧである場合には、再度、他社認証情報取得部２４４に制御を渡す。ただし、所定の回数、他社認証がＮＧの場合には、認証エラーとし処理を打ち切る。なお、第２認証部２４５と他社システム連携部２４３は、１つの機能部として構成してもよい。以上が、本システムの多重認証を実現するために典型的な構成である。なお、他社システム３００からの認証判定結果は、すべての登録他社情報ＤＢ２２０に記録しておいてもよい。認証先の他社として相応しいか判断することにも役立つ。

上記の本システムの機能構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）又はハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。

図５は、本発明の実施形態に係る自社システム２００の認証手段２４０における処理フローを示す図である。なお、以下の処理フロー図（フローチャート）においては、各処理ステップは、必ずしも図示した順序で行う必要はなく、各ステップのインプットとアウトプットの関係を損なわない限り、処理順序を入れ替えてもよい。

認証手段２４０は、まず、ステップＳ１０において、自社認証情報入力画面を顧客端末１００に表示させる。そして、顧客がその画面から入力して自社認証情報を取得する（ステップＳ１１）。

認証手段２４０は、次に、ステップＳ１２において、自社認証の結果を判定し、認証がＯＫの場合はステップＳ１３に進むが、認証がＮＧの場合は、ステップＳ２０に飛び、認証エラー時の所定の処理を行う。

自社認証の結果がＯＫであれば、ステップＳ１３において、登録他社があるかどうかを判定する。登録他社がなければ、ステップＳ１９に飛び、認証が正常に完了した場合の所定の処理を行う。登録他社がある場合には、ステップＳ１４に移る。

ステップＳ１４では、登録他社が複数あるかが判定される。顧客は、多くの場合、複数の事業者のサービスに登録しているので、本システムの他社認証先にも登録していることが多いと考えられる。ステップＳ１４において、登録他社が一つしかない場合はステップＳ１６に飛ぶが、登録他社が複数あると判定された場合は、ステップＳ１５に移る。

ステップＳ１５では、予めシステムに設定された方法に従い、登録された複数の他社から、他社認証として採用する他社を１〜２社程度を選択する。ここで他社を選択する方法には、（１）システムがランダムに選択する方法、（２）登録他社の一覧を表示して顧客に選択させる方法、（３）既に説明した認証タイプやパスワードタイプ等の認証方式が自社とは異なる他社を選択する方法、（４）自社よりも認証方式の点数又は堅牢性ランクの高い他社を順に選択、又はランダムに選択する方法、等がある。（３）において、認証方式が異なる他社が複数ある場合は、その中からランダムで選んでもよいし、（４）と組み合わせてもよい。また、（４）において、自社よりも認証方式の点数又は堅牢性ランクが高い他社がない場合は、同ランク以下であってもその他社を複数選択するようにしてもよい。

他社システムの選択が終わると、ステップＳ１６において、選択された他社システムの送信先を特定し、特定された他社システムから、他社の認証情報入力画面を取得し、顧客端末に表示する。そして、顧客がこの画面から入力した他社認証情報を取得し、他社システムに認証要求を送信する（ステップＳ１７）。

送信した他社認証情報は、他社システムによって認証判定が行われる。ステップＳ１８では、その他社認証結果を受信し、他社認証の結果がＯＫであれば、正常認証時の処理を行い（ステップＳ１９）、他社認証の結果がＮＧであれば、認証エラー時の処理を行う（ステップＳ２０）。認証エラー時には、エラーメッセージを表示して、所定回数までは、認証情報の再入力を求める等の処理を行う。以上のステップにより認証手段２４０の処理が終了する。

なお、図示は省略するが、他社システムにおいては、自社システムからの認証要求を受けた場合は、他社内での認証判定を行ない、自社システムに返信する処理が行われる。また、自社システムの認証手段に用いられる認証プログラムと、他社システムの認証手段に用いられる認証プログラムは、同一であってもよいが（要求元と要求先の処理が対称となる）、さらに利便性とセキュリティを強化のトレードオフを考慮し、認証プログラムを各社でカスタマイズするようにしてもよい（要求元と要求先の処理が非対称となる）。

図６は、本発明の実施形態に係る認証情報入力画面及び他社認証情報入力画面の具体例を示す図である。図６上段は、自社認証情報入力画面４００を示し、図６下段は、他社認証情報入力画面５００を示している。

この画面例では、自社（Ａ社）は、ログインＩＤとパスワードのみで認証を行っている企業であり、他社は、メガバンク等の金融機関であるとしている。図６の自社認証情報入力画面４００では、他社認証を行うか否かを顧客が選択できるようにしているが、登録他社がある場合には、常に他社認証を行うようにしてもよい。

顧客は、自身がインターネット取引のあるメガバンク等を他社認証として登録することで、仮にＡ社が見知らぬサイトであっても、アクセスする際の安心感を高めることができる。また、Ａ社にとっても、自社の認証方式を変更することなく、セキュリティを強化することができる。

図７は、本発明の実施形態に係る認証情報入力画面及び他社認証情報入力画面の別の具体例を示す図である。図７の他社認証情報入力画面５１０には、Ｂ社の認証情報入力画面５１１と、Ｃ社の認証情報入力画面５１２が１画面で表示されている。顧客は、それぞれの画面上で、認証情報を入力し、ログインボタンを押すことで、Ｂ社、Ｃ社の他社認証を同時に並行して実行させることができる。もちろん、Ｂ社、Ｃ社の認証結果もこの画面に表示される。

このようにすることで、他社認証の画面が複数であっても、比較的簡単な処理で認証を行うことができる。なお、Ａ社の顧客が、Ｂ社とＣ社を他社認証先として固定している場合は、Ａ社の自社認証情報入力画面４００と、他社認証情報入力画面５１０とを１画面で表示することが可能なので、３社同時に認証を行うこともできる。さらに、このような場合は、３社のサービスに同時にアクセスできるようにしてもよい。

（実施形態の効果）
以上、本システムでは、自社認証に加え、他社の認証も利用することにより、認証システムに大幅なコストをかけることなくセキュリティを強化することができる。

また、認証に利用する他社を複数登録しておけば、システムが他社をランダムに選択したり、自社と認証方式が異なる他社を選択したり、自社よりも堅牢性の高いシステムを採用している他社を選択したりしてくれるので、さらにセキュリティの強化に繋がる。

なお、上記の実施形態では、ネット上でサービスを提供する企業等がそのサービスを利用する顧客（利用者）を認証するための認証システムについて説明したが、サービスの提供を機密情報へのアクセス権の付与と置き換えれば、顧客サービス以外の事業を展開している企業、政府機関、地方公共団体等のセキュリティシステムにも適用が可能である。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記の実施形態では、本発明を物の発明として捉え、認証システムについて説明したが、本発明は、認証方法又はコンピュータ・プログラムの発明（認証プログラム）としても捉えることもできる。

１００ 顧客端末
２００ 自社システム
２１０ 顧客情報ＤＢ（顧客情報データベース）
２２０ 登録他社情報ＤＢ（登録他社情報データベース）
２３０ 登録手段
２４０ 認証手段
２４１ 自社認証情報取得部
２４２ 第１認証部
２４３ 他社システム連携部
２４４ 他社認証情報取得部
２４５ 第２認証部
３００ 他社システム
４００ 自社認証情報入力画面
５００，５１０，５１１，５１２ 他社認証情報入力画面

Claims (7)

1. 利用者の端末から前記利用者の認証情報を取得し、自社システムで認証を行う第１認証部と、
   前記自社システムでの認証が正常である場合に、登録された他社システムの認証情報入力画面を前記利用者の端末に表示し、前記認証情報入力画面から入力された他社認証情報を取得する他社認証情報取得部と、
   前記取得された他社認証情報を前記他社システムに送信し、前記他社システムでの認証を要求する他社システム連携部と、
   前記自社システム及び前記他社システムの認証の結果が共に正常である場合に、前記利用者を正規の利用者であると認証する第２認証部と、
   を備えたことを特徴とする認証システム。
2. 前記第１認証部は、前記自社システムでの認証が正常であって、かつ前記登録された他社が複数ある場合に、ランダムに他社を選択することを特徴とする請求項１に記載の認証システム。
3. 前記第１認証部は、前記自社システムでの認証が正常であって、かつ前記登録された他社が複数ある場合に、認証方式が異なる他社を選択することを特徴とする請求項１に記載の認証システム。
4. 前記第１認証部は、前記自社システムでの認証が正常であって、かつ前記登録された他社が複数ある場合に、認証方式に対して定められた点数が自社よりも高い他社を選択することを特徴とする請求項１に記載の認証システム。
5. 前記他社認証情報取得部は、前記第１認証部が選択した他社が複数ある場合に、当該複数の他社の認証情報入力画面を１画面にして前記利用者の端末に表示し、それぞれの他社認証情報を一度に入力させることを特徴とする請求項２乃至４のいずれか一項に記載の認証システム。
6. 利用者の端末から前記利用者の認証情報を取得し、自社システムで認証を行うステップと、
   前記自社システムでの認証が正常である場合に、登録された他社システムの認証情報入力画面を前記利用者の端末に表示し、前記認証情報入力画面から入力された他社認証情報を取得するステップと、
   前記取得された他社認証情報を前記他社システムに送信し、前記他社システムでの認証を要求するステップと、
   前記自社システム及び前記他社システムの認証の結果が共に正常である場合に、前記利用者を正規の利用者であると認証するステップと、
   を実行することを特徴とする認証方法。
7. 利用者の端末から前記利用者の認証情報を取得し、自社システムで認証を行うステップと、
   前記自社システムでの認証が正常である場合に、登録された他社システムの認証情報入力画面を前記利用者の端末に表示し、前記認証情報入力画面から入力された他社認証情報を取得するステップと、
   前記取得された他社認証情報を前記他社システムに送信し、前記他社システムでの認証を要求するステップと、
   前記自社システム及び前記他社システムの認証の結果が共に正常である場合に、前記利用者を正規の利用者であると認証するステップと、
   をコンピュータに実行させることを特徴とする認証プログラム。