特許 7636456 サーバシステム及び不正ユーザ検知方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-02-17

(45)【発行日】2025-02-26

(54)【発明の名称】サーバシステム及び不正ユーザ検知方法

(51)【国際特許分類】

   G06F 21/33 20130101AFI20250218BHJP

【ＦＩ】

G06F21/33

【請求項の数】 7

(21)【出願番号】P 2023025451

(22)【出願日】2023-02-21

(65)【公開番号】P2024118884

(43)【公開日】2024-09-02

【審査請求日】2023-07-13

(73)【特許権者】

【識別番号】524132520

【氏名又は名称】日立ヴァンタラ株式会社

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】田畑 義之

【審査官】宮司 卓佳

(56)【参考文献】

【文献】特開２０１９－０４６０５９（ＪＰ，Ａ）

【文献】特開２０１９－０４６０６０（ＪＰ，Ａ）

【文献】特開２００５－１４９２３９（ＪＰ，Ａ）

【文献】特開２００１－１８６１２２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／３１－２１／４６

(57)【特許請求の範囲】

【請求項1】

ユーザからのアクセスを受け付けるクライアントと、
ＯＡｕｔｈ ２．０又はＯＩＤＣ Ｃｏｒｅ １．０に基づく仕様のフローに沿って、前記クライアントからの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとを備え、
前記サーバは、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納し、
前記クライアントは、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定するものであり、
前記クライアントは、前記レスポンスを受信するとともに取得した識別子と前記レスポンスに格納された識別子とが一致する場合に前記レスポンスの送信元が正しいユーザであると判定し、前記レスポンスを受信するとともに取得した識別子と前記レスポンスに格納された識別子とが不一致である場合、前記レスポンスの受信時に識別子が取得できなかった場合、前記レスポンスに格納された識別子が取得できなかった場合に、前記レスポンスの送信元が不正なユーザであると判定する
ことを特徴とするサーバシステム。

【請求項2】

請求項１に記載のサーバシステムであって、
前記サーバは、前記ユーザの認証及び認可を行い、
前記クライアントは、前記比較の結果が不一致である場合に、レスポンスの送信元からのアクセスを拒否することを特徴とするサーバシステム。

【請求項3】

請求項１に記載のサーバシステムであって、
前記ユーザを代表する識別子は、クライアント証明書であることを特徴とするサーバシステム。

【請求項4】

請求項１に記載のサーバシステムであって、
前記ユーザを代表する識別子は、ユーザの端末が所定の媒体から読み取った識別情報であることを特徴とするサーバシステム。

【請求項5】

請求項１に記載のサーバシステムであって、
前記サーバは、前記ユーザを代表する識別子を格納したレスポンスに電子署名し、
前記クライアントは、前記電子署名を検証した上で前記比較を行うことを特徴とするサーバシステム。

【請求項6】

請求項１に記載のサーバシステムであって、
前記ユーザに提供するリソースデータを保持するリソースサーバをさらに備え、
前記サーバは、前記リソースデータに対するアクセスの認可を行うことを特徴とするサーバシステム。

【請求項7】

ユーザからのアクセスを受け付けるクライアントと、
ＯＡｕｔｈ ２．０又はＯＩＤＣ Ｃｏｒｅ １．０に基づく仕様のフローに沿って、前記クライアントからの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとを備えるサーバシステムの不正ユーザ検知方法であって、
前記サーバが、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納するステップと、
前記クライアントが、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定する判定ステップとを含み、
前記判定ステップは、前記レスポンスを受信するとともに取得した識別子と前記レスポンスに格納された識別子とが一致する場合に前記レスポンスの送信元が正しいユーザであると判定し、前記レスポンスを受信するとともに取得した識別子と前記レスポンスに格納された識別子とが不一致である場合、前記レスポンスの受信時に識別子が取得できなかった場合、前記レスポンスに格納された識別子が取得できなかった場合に、前記レスポンスの送信元が不正なユーザであると判定する
ことを特徴とする不正ユーザ検知方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバシステム及び不正ユーザ検知方法に関する。

【背景技術】

【0002】

従来、認証や認可の技術として、ＯＡｕｔｈ ２．０（ＲＦＣ６７４９）、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ Ｃｏｒｅ １．０の認可コードフロー、ＳＡＭＬのＳＰ－ｉｎｉｔｉａｔｅｄなどが知られている。
また、複数の認可サーバが存在した際に、適切な認可サーバを選択する技術として、特開２０２０－５３１００号公報（特許文献１）に記載の技術がある。この公報には、「認可サーバーは、認可リクエストを受信したことに伴って、ユーザー情報が所在する第一の認可サーバーを特定し、第一の認可サーバーに対して認証要求を送信する第一の送信手段と、第一の認可サーバーはユーザーを認証し、ユーザー情報が所在する第一の認可サーバーを送信先として示す情報とともに認可レスポンスをクライアントに送信する第二の送信手段と、クライアントは認可レスポンスに基づいて、第二の特定手段により前記第一の認可サーバーを特定し、第一の認可サーバーに対して、リソースサーバーにアクセスするための認可トークンを要求するトークン要求を送信する第三の送信手段と、第一の認可サーバーはトークン要求に対して認可トークンを発行する発行手段と、を有する。」という記載がある。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０２０－５３１００号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

従来の技術では、不正なユーザがクライアントに正規のユーザとしてログインする事態を防ぐことができなかった。ＯＡｕｔｈを例に説明すると、認可サーバが認証し、認可（同意）を取得したユーザとは別のユーザ（不正なユーザ）がクライアントにログインできる問題が発生していた。このように、従来の技術では不正アクセスに対するセキュリティが不十分であった。

【0005】

そこで、本発明では、不正なユーザの検知を実現し、サーバシステムのセキュリティを向上することを目的とする。

【課題を解決するための手段】

【0006】

上記目的を達成するために、代表的な本発明のサーバシステムの一つは、ユーザからのアクセスを受け付けるクライアントと、前記クライアントからの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとを備え、前記サーバは、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納し、前記クライアントは、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定することを特徴とする。
また、代表的な本発明の不正ユーザ検知方法の一つは、ユーザからのアクセスを受け付けるクライアントと、前記クライアントからの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとを備えるサーバシステムの不正ユーザ検知方法であって、前記サーバが、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納するステップと、前記クライアントが、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザであるか否かを判定するステップとを含むことを特徴とする。

【発明の効果】

【0007】

本発明によれば、不正なユーザの検知を実現し、サーバシステムのセキュリティを向上できる。上記した以外の課題、構成及び効果は以下の実施の形態の説明により明らかにされる。

【図面の簡単な説明】

【0008】

【図1】認証及び認可の基本的な処理の説明図

【図2】実施例１のシステムによる認証及び認可の処理の説明図

【図3】不正なアクセスのブロックについての説明図

【図4】システム要素の説明図

【図5】システム全体の構成図

【図6】認可サーバの処理手順を示すフローチャート

【図7】クライアントの処理手順を示すフローチャート

【図8】システムが管理するデータの説明図

【図9】データの利用の説明図

【図10】データの管理の説明図

【発明を実施するための形態】

【0009】

以下、実施例を図面を用いて説明する。

【実施例1】

【0010】

図１は、認証及び認可の基本的な処理の説明図である。この図１は、ＯＡｕｔｈ ２．０やＯＩＤＣ Ｃｏｒｅ １．０の認可コードフローの具体例である。
ユーザは、ユーザ端末のブラウザ１１０を介して、クライアント１２０にアクセスする。ここでは、クライアント１２０は、リソースサーバ１４０に格納されたデータの提供を求めているものとする。

【0011】

クライアント１２０は、ユーザの認証及び認可を認可サーバ１３０に委譲する（１）。具体的には、クライアント１２０は、認可サーバ１３０を宛先としてブラウザ１１０にリダイレクトさせる。この結果、ブラウザ１１０は、認可サーバ１３０に認可リクエストを送ることになる。

【0012】

認可リクエストを受信した認可サーバ１３０は、認証及び認可処理を実行する（２）。具体的には、認可サーバ１３０は、ログイン情報の入力を受け付ける画面（ログイン画面）、確認入力を受け付ける画面（同意画面）をブラウザ１１０に送信する。ブラウザ１１０は、ログイン画面及び同意画面を表示し、ユーザによる入力を受け付ける。ブラウザ１１０は受け付けたデータを認可サーバ１３０に送信する。認可サーバ１３０は、ブラウザ１１０から受信したデータを用いてユーザの認証と認可を行う。

【0013】

認可サーバ１３０は、認証及び認可の結果を認可レスポンスとしてクライアント１２０に返却する（３）。具体的には、認可サーバ１３０は、クライアント１２０を宛先としてブラウザ１１０にリダイレクトさせる。この結果、ブラウザ１１０は、クライアント１２０に認可レスポンスを送ることになる。

【0014】

クライアント１２０は、認可サーバ１３０にトークンリクエストを送信し、認可サーバ１３０からトークンレスポンスを受信する。その後、クライアント１２０は、リソースサーバ１４０にＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）リクエストを送信する。リソースサーバ１４０は、ＡＰＩレスポンスでクライアント１２０にデータを提供する。

【0015】

図１に示した基本的な処理では、認証及び認可処理（２）でログインしたユーザと、結果返却処理（３）で結果を返したユーザとが同一であることを確認できない。そこで、本実施例のシステムでは、ユーザを代表する識別子を取得して、認証及び認可処理（２）と結果返却処理（３）のユーザが同一であるかを判定している。

【0016】

図２は、実施例１のシステムによる認証及び認可の処理の説明図である。図２の認証及び認可処理（２）では、ブラウザ１１０は、ログイン画面と同意画面に対するユーザ入力データととともに、クライアント証明書を認可サーバ１３０に送信する。認可サーバ１３０は、認可レスポンスにクライアント証明書のハッシュ値を格納する。

【0017】

図２の結果返却処理（３）では、クライアント１２０は、認可レスポンスを受信するとともに、ブラウザ１１０からクライアント証明書のハッシュ値を取得する。クライアント１２０は、ブラウザ１１０から取得したクライアント証明書と、認可レスポンスに含まれていたクライアント証明書のハッシュ値とを比較する。比較の結果、同一であれば、クライアント１２０は正当なユーザからのアクセスであると判定し、リソースサーバ１４０のデータを提供する。

【0018】

このように、実施例１のシステムは、認証及び認可処理（２）と結果返却処理（３）でそれぞれクライアント証明書に関するデータを取得し、それらを比較する。クライアント証明書は、ユーザを代表する識別子の一例である。ユーザを代表する識別子は、クライアント証明書のように、ユーザクレデンシャルとして使用でき、かつフィッシング攻撃によって取得できないデータを用いる。例えばクライアント証明書であれば、フィッシング攻撃を受けて攻撃者の準備した偽サイトに誘導されたとしても、攻撃者はクライアントの秘密鍵までは奪うことができない。このため、攻撃者は、正規ユーザになりすましてクライアントや認可サーバにクライアント証明書を提示することはできない。ユーザを代表する識別子は、ＩＣカードの識別番号であってもよい。

【0019】

図３は、不正なアクセスのブロックについての説明図である。不正なユーザである攻撃者は、攻撃者のユーザ端末のブラウザを介して、クライアント１２０にアクセスする。クライアント１２０は、ユーザの認証及び認可を認可サーバ１３０に委譲する。具体的には、クライアント１２０は、認可サーバ１３０を宛先として攻撃者のブラウザにリダイレクトさせる。攻撃者は、この時点で処理を止め、認可リクエストを取得する。そして、認可リクエストをハイパーリンクにセットした電子メールを正当なユーザに送る。正当なユーザが電子メールを開き、ハイパーリンクをクリックすると、ブラウザ１１０は認可リクエストを認可サーバ１３０に送る。

【0020】

認可リクエストを受信した認可サーバ１３０は、認証及び認可処理を実行する。具体的には、認可サーバ１３０は、ログイン情報の入力を受け付ける画面（ログイン画面）、確認入力を受け付ける画面（同意画面）をブラウザ１１０に送信する。ブラウザ１１０は、ログイン画面及び同意画面を表示し、正当なユーザによる入力を受け付ける。ブラウザ１１０は受け付けたデータを認可サーバ１３０に送信する。認可サーバ１３０は、ブラウザ１１０から受信したデータを用いてユーザの認証と認可を行う。すなわち、この認証と認可は、正当なユーザによって行われる。

【0021】

認可サーバ１３０は、認証及び認可の結果を認可レスポンスとしてクライアント１２０に返却する。具体的には、認可サーバ１３０は、クライアント１２０を宛先としてブラウザ１１０にリダイレクトさせる。この結果、ブラウザ１１０は、クライアント１２０に認可レスポンスを送る。ここで、不正なユーザである攻撃者が中間者（Ｍａｎ Ｉｎ ｔｈｅ Ｍｉｄｄｌｅ）として介在して処理を止め、認可レスポンスを不正に取得する。

【0022】

攻撃者は、不正に取得した認可レスポンスをクライアント１２０に送信することで、不正なアクセスを試みる。
図１に示した基本的な処理であれば、クライアント１２０はユーザが入れ替わったことを検知できず、攻撃者によるアクセスが成功する。
しかし、図３においては、認可サーバ１３０は、ブラウザ１１０から取得したクライアント証明書のハッシュ値を認可レスポンスにデータとして格納している。そして、クライアント１２０は、ブラウザが認可レスポンスを送るときにＴＣＰレイヤでクライアント証明書を取得し、認可レスポンスにデータとして含まれたクライアント証明書のハッシュ値と、認可レスポンスを送るときにＴＣＰレイヤで送られたクライアント証明書とを比較する。攻撃者が認可レスポンスを送信していれば、クライアント証明書が取得できない、もしくはクライアント証明書が不一致となる。このため、クライアント１２０は、不正なユーザからのアクセスであると判定し、アクセスをブロックできる。

【0023】

図４は、システム要素の説明図である。この図４は、ＯＡｕｔｈ ２．０やＯＩＤＣ Ｃｏｒｅ １．０を例とした説明図を示している。
ブラウザは、ユーザが使用するブラウザである。ユーザは、ブラウザを介してクライアントや認可サーバにアクセスする。
クライアントは、ユーザにサービスを提供する。クライアントは、認可サーバにユーザの認証を委譲する。また、クライアントは、認可サーバが発行したトークンを用いてユーザを認証する。場合によってはリソースサーバからユーザのリソース(情報)を取得するために、トークンを用いてＡＰＩコールする。
認可サーバは、ユーザを認証し、必要に応じてユーザから同意を取得し、クライアントにトークンを発行する。
リソースサーバは、ユーザのリソース(情報)を保持している。当該情報をリソースサーバはＡＰＩで公開する。また、リソースサーバは、認可サーバが発行したトークンを用いてアクセス制御する。なお、リソースサーバは、本システムに必須ではない。

【0024】

さらに、本実施例のシステムでは、認可サーバは、ユーザを代表する識別子を取得して、認可レスポンスに格納する機能を有する。また、クライアントは、ユーザを代表する識別子を取得し、認可レスポンスに格納された識別子と比較して、正当なユーザであるか否かを判定する機能を有する。

【0025】

図５は、システム全体の構成図である。
ブラウザ１１０は、ユーザの端末で動作している。
クライアント１２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１２１、メモリ１２２、ストレージ１２３及び通信インタフェース１２４を有するコンピュータである。具体的には、ＣＰＵ１２１は、ストレージ１２３から所定のプログラムを読み出してメモリ１２２に展開し、順次実行することで、クライアント１２０としての各種機能を実現する。また、通信インタフェース１２４は、ブラウザ１１０や認可サーバ１３０との通信を行う。
認可サーバ１３０は、ＣＰＵ１３１、メモリ１３２、ストレージ１３３及び通信インタフェース１３４を有するコンピュータである。具体的には、ＣＰＵ１３１は、ストレージ１３３から所定のプログラムを読み出してメモリ１３２に展開し、順次実行することで、認可サーバ１３０としての各種機能を実現する。また、通信インタフェース１３４は、ブラウザ１１０やクライアント１２０との通信を行う。

【0026】

図６は、認可サーバの処理手順を示すフローチャートである。認可サーバ１３０は、次のステップＳ２０１～Ｓ２０６の処理を順次実行する。
ステップＳ２０１：認可サーバ１３０は、ユーザ認証時、またはユーザの同意取得時に受け取ったリクエストからユーザを代表する識別子ＩＤ１を取得する。その後、ステップＳ２０２に進む。
ステップＳ２０２：認可サーバ１３０は、ユーザを代表する識別子ＩＤ１を取得できたか否かを判定する。取得できたならば、ステップＳ２０３に進む。取得できなかったならば、ステップＳ２０６に進む。

【0027】

ステップＳ２０３：認可サーバ１３０は、認可レスポンスにユーザを代表する識別子ＩＤ１を格納する。その後、ステップＳ２０４に進む。
ステップＳ２０４：認可サーバ１３０は、認可レスポンスに署名する。その後、ステップＳ２０５に進む。
ステップＳ２０５：認可サーバ１３０は、認可レスポンスをリダイレクトでクライアント１２０に送信し、処理を終了する。
ステップＳ２０６：認可サーバ１３０は、エラーレスポンスをリダイレクトでクライアント１２０に送信し、処理を終了する。

【0028】

図７は、クライアント１２０の処理手順を示すフローチャートである。クライアント１２０は、次のステップＳ３０１～Ｓ３０８の処理を順次実行する。
ステップＳ３０１：クライアント１２０は、認可レスポンス受信時に受け取ったリクエストからユーザを代表する識別子ＩＤ２を取得する。その後、ステップＳ３０２に進む。
ステップＳ３０２：クライアント１２０は、ユーザを代表する識別子ＩＤ２を取得できたか否かを判定する。取得できたならば、ステップＳ３０３に進む。取得できなかったならば、ステップＳ３０８に進む。

【0029】

ステップＳ３０３：クライアント１２０は、認可レスポンスに格納されたユーザを代表する識別子ＩＤ１を取得する。
ステップＳ３０４：クライアント１２０は、ユーザを代表する識別子ＩＤ１を取得できたか否かを判定する。取得できたならば、ステップＳ３０５に進む。取得できなかったならば、ステップＳ３０８に進む。

【0030】

ステップＳ３０５：クライアント１２０は、識別子ＩＤ１と識別子ＩＤ２を比較し、等しいことを確認する処理を行う。その後、ステップＳ３０６に進む。
ステップＳ３０６：クライアント１２０は、クライアント１２０は、識別子ＩＤ１と識別子ＩＤ２が等しいか否かを判定する。等しければ、ステップＳ３０７に進む。取得できなかったならば、ステップＳ３０８に進む。

【0031】

ステップＳ３０７：クライアント１２０は、ユーザを代表する識別子チェック成功とみなし、処理を終了する。言い換えれば、クライアント１２０は、認可レスポンスの送信元が正しいユーザであると判定して、処理を終了する。
ステップＳ３０８：クライアント１２０は、ユーザを代表する識別子チェック失敗とみなし、処理を終了する。言い換えれば、クライアント１２０は、認可レスポンスの送信元が不正なユーザであると判定して、処理を終了する。

【0032】

図８は、システムが管理するデータの説明図である。
クライアント１２０は、次のデータを管理する。
１．クライアントが認可サーバに認証認可を委譲する際にアクセスする認可サーバのエンドポイント
２．クライアントを識別するための識別子
３．認証認可結果の署名を検証するための署名検証鍵

【0033】

認可サーバ１３０は、次のデータを管理する。
１０．認可サーバがクライアントに認証認可の結果を送付する際にアクセスするクライアントのエンドポイント
１１．クライアントを識別するための識別子
１２．ユーザのユーザクレデンシャル
１３．認証認可結果に署名するための署名鍵
１４．ログイン画面
１５．同意画面

【0034】

ユーザまたはブラウザ１１０は、次のデータを管理する。
２０．認可サーバで認証するためのユーザクレデンシャル(例：ユーザ名とパスワード)
２１．ユーザを代表する識別子
２２．クライアントへアクセスするためのエンドポイント

【0035】

図９は、図８に示したデータの利用の説明図である。
ブラウザ１１０は、エンドポイント２２を宛先とすることで、クライアント１２０にアクセスする。
クライアント１２０は、識別子２を付与し、エンドポイント１を宛先とすることで、認可サーバ１３０にリダイレクトする。
認可サーバ１３０は、識別子２と識別子１１でクライアントを識別して、ログイン画面１４や同意画面１５をブラウザ１１０に送付する。
ユーザは、ユーザクレデンシャル２０を入力し、ブラウザ１１０はユーザクレデンシャル２０と識別子２１を認可サーバ１３０に送付する。

【0036】

認可サーバ１３０は、ユーザクレデンシャル２０とユーザクレデンシャル１２でユーザを認証する。そして、識別子２１を認証認可結果（認可レスポンス）に格納し、署名鍵１３で認証認可結果に署名して、エンドポイント１０（クライアント１２０）にリダイレクトする。
ブラウザ１１０は、認証認可結果をクライアント１２０にリダイレクトする際に、識別子２１を送付する。
クライアント１２０は、署名検証鍵３で認証認可結果の署名を検証する。そして、送付された識別子２１と認証認可結果内の識別子２１が同一であることを検証する。

【0037】

図１０は、データの管理の説明図である。
ユーザを代表する識別子２１は、ブラウザ１１０に管理される。
認証認可の結果を送付する際にアクセスするクライアントのエンドポイント１、クライアントを識別するための識別子２、署名検証鍵３は、クライアント１２０のメモリ１２２に格納される。
認証認可の結果を送付する際にアクセスするクライアントのエンドポイント１０、クライアントを識別するための識別子１１、ユーザクレデンシャル１２、署名鍵１３、ログイン画面１４、同意画面１５は、認可サーバ１３０のメモリ１３２に格納される。

【0038】

上述してきたように、開示のサーバシステムは、ユーザからのアクセスを受け付けるクライアント１２０と、前記クライアント１２０からの委譲を受け、前記ユーザの認証及び／又は認可のリクエストを処理するサーバとしての認可サーバ１３０とを備え、前記サーバは、前記リクエストを受信するとともに、前記ユーザを代表する識別子を取得し、前記リクエストに対するレスポンスに格納し、前記クライアント１２０は、前記ユーザから前記レスポンスを受信するとともに、前記ユーザを代表する識別子を取得し、該取得した識別子と前記レスポンスに格納された識別子とを比較して、前記レスポンスの送信元が正しいユーザのブラウザであるか否かを判定する。
このため、不正なユーザを検知し、サーバシステムのセキュリティを向上できる。

【0039】

また、前記サーバは、前記ユーザの認証及び認可を行い、前記クライアントは、前記比較の結果が不一致である場合に、レスポンスの送信元からのアクセスを拒否する。
このため、不正なユーザが、正当なユーザによる認証及び認可の結果を悪用して行うアクセスをブロックできる。

【0040】

前記ユーザを代表する識別子には、クライアント証明書を用いることができる。
また、前記ユーザを代表する識別子には、ユーザの端末が所定の媒体から読み取った識別情報を用いることができる。
ユーザを代表する識別子は、クライアント証明書のように、ユーザクレデンシャルとして使用でき、かつフィッシング攻撃によって取得できないデータを用いる。例えばクライアント証明書であれば、フィッシング攻撃を受けて攻撃者の準備した偽サイトに誘導されたとしても、攻撃者はクライアントの秘密鍵までは奪うことができない。このため、攻撃者は、正規ユーザになりすましてクライアントや認可サーバにクライアント証明書を提示することはできない。

【0041】

また、前記サーバは、前記ユーザを代表する識別子を格納したレスポンスに電子署名し、前記クライアントは、前記電子署名を検証した上で前記比較を行う。
このため、レスポンスに格納された識別子が書き換えられていないことを確認でき、セキュリティが向上する。

【0042】

また、開示の前記ユーザに提供するリソースデータを保持するリソースサーバ１４０をさらに備え、前記サーバは、前記リソースデータに対するアクセスの認可を行う。
このためリソースデータに対する不正なアクセスを防止できる。

【0043】

なお、本発明は上記の実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、かかる構成の削除に限らず、構成の置き換えや追加も可能である。
例えば、認証や認可の委譲が多段階で行われる構成であっても、本発明は適用可能である。

【符号の説明】

【0044】

１１０：ブラウザ、１２０：クライアント、１３０：認可サーバ、１４０：リソースサーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】