JP6311214B2

JP6311214B2 - アプリケーション認証プログラム、認証サーバ、端末およびアプリケーション認証方法

Info

Publication number: JP6311214B2
Application number: JP2013016251A
Authority: JP
Inventors: 直樹三好; 暁生下野; 護吉無田; 翔平水野
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2013-01-30
Filing date: 2013-01-30
Publication date: 2018-04-18
Anticipated expiration: 2033-01-30
Also published as: US20140215565A1; JP2014149561A; CN103971047B; CN103971047A; US10044694B2

Description

本発明は、アプリケーション認証プログラムなどに関する。

近年提供されているインターネット上のサービスでは、ウェブブラウザ等の汎用化されたアプリケーション経由ではなく、サービス専用のアプリケーションを経由したサービス提供が行われている。かかるサービス提供では、サービス提供側は、ユーザのアプリケーションを用いてのサービスへの接続許可に対する認証（ユーザ認証）のほかにアプリケーションのアクセス許可に対する認証（アプリ認証）を行う。

アプリケーションのアクセス許可に対する認証では、ユーザが使用するアプリケーションの認証情報を、例えばアプリケーションの提供者または作成者が事前にサービス提供側に登録し、サービス提供側は、アプリケーションの識別ＩＤおよびパスワードを発行する。そして、サービス提供側は、アプリケーションからサービスへの接続の際に、アプリケーションの識別ＩＤおよびパスワードを利用した認証を行う。認証が完了すると、サービス提供側は、トークンを発行し、アプリケーションはトークンを用いて、ユーザからの操作に応じて、サービスへのアクセスを行う。このアプリケーションの認証手法として、ＯＡｕｔｈ２が知られている（例えば、特許文献１）。

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

ところで、サービス提供側のサービスの提供が複数のサイトにわたり、複数のサイト間でアプリケーションの認証情報の共有がなされない場合がある。かかる場合、例えばアプリケーションの提供者は使用するアプリケーションの認証情報を、利用するサイト毎に登録することとなり、アプリ認証が煩雑になるという問題がある。

ここで、アプリ認証が煩雑になるという問題について、図１１および図１２を参照して説明する。図１１は、ＯＡｕｔｈ２を利用したサービスを示す図である。図１２は、アプリ認証が煩雑になるという問題を示す図である。

図１１に示すように、ＯＡｕｔｈ２を利用したサービスでは、アプリＡ，Ｂ，Ｃ，Ｄの認証情報として例えばアプリリストを、サービス提供側の例えばアプリケーションの提供者が認証サーバに登録する。そして、認証サーバは、ＯＡｕｔｈ２を利用してアプリＡ，Ｂ，Ｃ，Ｄの各アプリケーションのアプリ認証を行うことができる。

図１２に示すように、サービス提供側では、サービスの提供が複数のサイトにわたることがある。ここで、複数のサイトの認証サーバ間で認証情報の共有がなされない場合、サービス提供側の例えばアプリケーションの提供者は、使用するアプリケーションを認証サーバ分登録することが必要となり、アプリ認証が煩雑になる。

アプリ認証が煩雑になることを回避するために、アプリケーションの認証情報をサービス提供側が持たない場合、ユーザは、利用しているアプリケーションが正当な通信を行っていないことを検知できないという問題がある。例えば、ユーザは不当なアプリケーションに騙られてしまうことがある。ここで、不当なアプリケーションに騙られた場合の一例を、図１３を参照して説明する。図１３は、不当なアプリケーションに騙られた場合の一例を示す図である。

図１３左図で示される画面は、正当なアプリケーションによって表示された画面である。図１３右図で示される画面は、正当なアプリケーションを装った不当なアプリケーション（例えば、フィッシングアプリ）によって表示された画面である。ここでは、ＵＲＬが異なるだけで表示内容が同じであるので、ユーザは、気づかないでパスワードを入力してしまうことがある。すなわち、ユーザは、アプリケーションが正当な通信を行っていないことを検知できない。

１つの側面では、アプリケーションの正当性を判定することを目的とする。

本願の開示するアプリケーション認証プログラムは、コンピュータに、端末上で動作するアプリケーションから、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を受付け、前記リダイレクト情報が正当であると判断したとき、前記アクセス要求に対する応答であって、前記アプリケーション関連情報に対応するアプリケーション特定情報を含むアクセス応答を、前記リダイレクト情報に対応するリダイレクト先に送信する処理を実行させる。

本願の開示するアプリケーション認証プログラムの１つの態様によれば、アプリケーションの正当性を判定することができる。

図１は、実施例に係るデータ参照システムの全体構成を示すブロック図である。図２は、アプリ識別情報の内容の一例を示す図である。図３は、実施例に係る通信端末側での処理のフローチャートを示す図である。図４は、実施例に係るデータサーバ側での処理のフローチャートを示す図である。図５は、実施例に係るアプリケーションサーバ側での処理のフローチャートを示す図である。図６は、実施例に係るアプリケーション認証処理のシーケンスを示す図である。図７は、実施例に係るアプリケーション認証処理の変形例のシーケンスを示す図である。図８Ａは、不正なアプリケーションが認証要求をする例を示す図（１）である。図８Ｂは、不正なアプリケーションが認証要求をする例を示す図（２）である。図８Ｃは、不正なアプリケーションが認証要求をする例を示す図（３）である。図９は、サーバのハードウェア構成の一例を示す図である。図１０は、通信端末のハードウェア構成の一例を示す図である。図１１は、ＯＡｕｔｈ２を利用したサービスを示す図である。図１２は、アプリ認証が煩雑になるという問題を示す図である。図１３は、不当なアプリケーションに騙られた場合の一例を示す図である。

以下に、本願の開示するアプリケーション認証プログラム、認証サーバ、端末およびアプリケーション認証方法の実施例を図面に基づいて詳細に説明する。なお、実施例によりこの発明が限定されるものではない。

［データ参照システムの構成］
図１は、実施例に係るデータ参照システムの全体構成を示す図である。図１に示すように、データ参照システム９は、通信端末１と、複数のアプリケーションサーバ２と、複数のデータサーバ３とを有する。通信端末１は、複数のアプリケーションサーバ２および複数のデータサーバ３とそれぞれインターネット網を示すネットワーク４で接続されている。

通信端末１は、アプリケーションを用いてサービスの提供を受ける。アプリケーションサーバ２は、アプリケーションによってサービスを提供する。データサーバ３は、サービスに伴い生成されるデータを管理する。すなわち、データ参照システム９は、複数のアプリケーションサーバ２それぞれで提供されるアプリケーションを通信端末１に利用させながらも、通信端末１のユーザが指定したデータサーバ３にアクセスしてユーザ個人のデータを当該データサーバ３で一括して管理する。このように、データ参照システム９は、アプリケーションサーバ２とデータサーバ３とを分離する構成を採用することにより、通信端末１のユーザが自身のコントロール配下でデータを一元管理することを可能とする。

通信端末１には、アプリケーション１０およびブラウザ１１が記憶される。通信端末１は、例えば、スマートフォンであったり、ＰＨＳ（Personal Handyphone System）であったり、ＰＤＡ（Personal Digital Assistants）であったり、ＰＣ（Personal Computer）であっても良く、通信可能な通信端末であれば良い。

アプリケーション１０は、通信端末１がアプリケーションサーバ２によって提供されるサービスを受けるためのソフトウェアである。通信端末１は、ユーザが提供を受けたいサービスに対応するアプリケーションを、当該サービスを提供するアプリケーションサーバ２から取得し、例えば、ＲＡＭ（Random Access Memory）やＨＤＤ（Hard Disk Drive）に格納する。

アプリケーション１０は、ユーザのデータサーバ３に対して、自身の認証要求を送信する。例えば、アプリケーション１０は、アプリケーション関連情報およびリダイレクト情報を指定した認証要求を、ユーザのデータサーバ３に送信する。ここで、アプリケーション関連情報とは、アプリケーション１０に対応するアプリケーションサーバ２のＵＲＬであり、リダイレクト情報とは、アプリケーションサーバ２上のトークン取り出しページのＵＲＬ（リダイレクトＵＲＬ）である。なお、アプリケーションサーバ２のＵＲＬやアプリケーションサーバ２上のトークン取り出しページのＵＲＬは、アプリケーション１０の所定の領域に埋め込まれている。

また、アプリケーション１０は、認証要求に対する応答として後述するブラウザ１１からトークンを取得する。これにより、アプリケーション１０は、トークンを用いて、ユーザのデータサーバ３へアクセスできる。

ブラウザ１１は、所定の情報をダウンロードし、レイアウトを解析して表示するソフトウェアである。例えば、ブラウザ１１は、認証要求が送信されたデータサーバ３から、当該認証要求をユーザに問い合わせる画面を取得し、取得した画面を表示する。さらに、ブラウザ１１は、アプリケーションサーバ２のＵＲＬから、アプリケーション１０の識別情報（後述するアプリ識別情報）を取得し、取得したアプリ識別情報を、認証要求を問い合わせる画面上に表示する。これにより、ブラウザ１１は、アプリケーション１０のアプリ識別情報を表示することで、ユーザにアプリケーション１０の正当性を委ねることができる。すなわち、ユーザは、ブラウザ１１によって表示されたアプリ識別情報を視認することで、アプリケーション１０の正当性を判別できる。また、ブラウザ１１は、認証要求に対する応答をデータサーバ３から取得し、取得した応答に含まれるアプリケーションサーバ２上のトークン取り出しページのＵＲＬから、トークン取り出しページ２１２をダウンロードする。そして、ブラウザ１１は、ダウンロードしたトークン取り出しページを実行し、トークンが取り出せるかどうかを確認する。そして、ブラウザ１１は、トークンが取り出せる場合、取り出したトークンを認証要求に対する応答としてアプリケーション１０に戻す。

アプリケーションサーバ２は、サービス毎、言い換えると、サービスを実施するアプリケーション毎に区分される。さらに、アプリケーションサーバ２は、記憶部２１と、提示部２２とを有する。

記憶部２１は、例えばフラッシュメモリ（Flash Memory）やＦＲＡＭ（登録商標）（Ferroelectric Random Access Memory）等の不揮発性の半導体メモリ素子等や、ハードディスク（ＨＤＤ）等の記憶装置に対応する。そして、記憶部２１は、アプリケーション２１０とアプリ識別情報２１１とトークン取り出しページ２１２を有する。アプリケーション２１０は、サービスを提供するソフトウェアであり、通信端末１からの要求により当該通信端末１に配信される。トークン取り出しページ２１２は、通信端末１側でトークンを取り出す際に用いられるスクリプトである。

アプリ識別情報２１１は、アプリケーション２１０の識別に用いられる情報である。ここで、アプリ識別情報２１１の内容を、図２を参照して説明する。図２は、アプリ識別情報の内容の一例を示す図である。図２に示すように、アプリ識別情報には、ロゴａ１、アプリ名ａ２および説明ａ３が対応付けて設定される。ロゴａ１は、アプリケーション２１０のロゴを示す。ロゴａ１には、例えば、アプリケーション２１０を作成した会社名またはアプリケーション２１０によって提供されるサービスのサービス名が含まれても良い。アプリ名ａ２は、アプリケーション２１０の名称を示す。アプリ名ａ２は、バージョン情報を含んでも良い。説明ａ３には、アプリケーション２１０の機能などの説明が設定される。

図１に戻って、提示部２２は、ブラウザ１１から、自身のアプリケーションサーバ２に対応するアプリ識別情報２１１の取得要求を受信すると、記憶部２１に記憶されたアプリ識別情報２１１をブラウザ１１に提示する。これにより、ブラウザ１１は、認証要求があったアプリケーション１０のアプリ識別情報２１１を表示できるので、ユーザにアプリケーション１０の正当性を判断させることができる。

データサーバ３は、通信端末１のユーザ単位毎に区分される。さらに、データサーバ３は、記憶部３１と、認証部３２と、制御部３３とを有する。

記憶部３１は、例えばフラッシュメモリ（Flash Memory）やＦＲＡＭ（登録商標）（Ferroelectric Random Access Memory）等の不揮発性の半導体メモリ素子等や、ハードディスク等の記憶装置に対応する。記憶部３１は、サービスに対応するデータ領域を有する。ここでいうサービスとは、アプリケーションサーバ２によって提供されるサービスであり、アプリケーション１０によって実施されるサービスを意味する。例えば、ユーザ１００の通信端末１が、サービスＡのアプリケーション１０によってサービスの提供を受けるとする。すると、ユーザ１００の通信端末１は、サービスＡのアプリケーション１０の認証に成功すれば、ユーザ１００に対応するデータサーバ３の記憶領域のうち、サービスＡに対応するデータ領域にアクセスできる。

認証部３２は、通信端末１上で動作するアプリケーション１０から、アプリケーション関連情報およびリダイレクト情報を指定した認証要求を受信すると、アプリケーション１０の認証を開始する。ここで、アプリケーション関連情報とは、アプリケーション１０に対応するアプリケーションサーバ２のＵＲＬであり、リダイレクト情報とは、アプリケーションサーバ２上のトークン取り出しページのＵＲＬである。例えば、認証部３２は、アプリケーション１０からの認証要求に対する応答として、当該認証要求をユーザに問い合わせる画面を通信端末１に送信する。

また、認証部３２は、リダイレクト情報が正当であるか否かを判定する。例えば、認証部３２は、認証要求をユーザに問い合わせた結果、通信端末１からデータサーバ３に対するログインがなされると、リダイレクト情報がアプリケーション関連情報の配下であるかを判定する。すなわち、認証部３２は、アプリケーションサーバ２上のトークン取り出しページのＵＲＬ内部分文字列が、アプリケーション１０に対応するアプリケーションサーバ２のＵＲＬ内文字列に含まれるか否かを判定する。一例として、部分文字列がドメインの文字列である場合、認証部３２は、トークン取り出しページのＵＲＬ内ドメインの文字列がアプリケーションサーバ２のＵＲＬ内文字列に含まれるか否かを判定する。そして、認証部３２は、リダイレクト情報がアプリケーション関連情報の配下であると判定した場合、リダイレクト情報が正当であると判断する。一方、認証部３２は、リダイレクト情報がアプリケーション関連情報の配下でないと判定した場合、リダイレクト情報が不当であると判断する。これにより、認証部３２は、不当なアプリケーション１０からの認証要求であることを検証することができる。

また、認証部３２は、リダイレクト情報が正当である場合、トークンを払い出し、払い出したトークンをリダイレクト情報に付与し、認証要求に対する応答としてブラウザ１１に返す。例えば、認証部３２は、アプリケーションサーバ２上のトークン取り出しページのＵＲＬに、払い出したトークンをフラグメントで付与する。そして、認証部３２は、付与して得られた情報をロケーションヘッダに指定してブラウザ１１に返す。ここで、ロケーションヘッダに指定された情報の一例について説明する。アプリケーションサーバ２上のトークン取り出しページのＵＲＬが「https://hoge.example.com/{token_parse_script}」であるとする。すると、トークンをフラグメントで付与した情報は、「https://hoge.example.com/{token_parse_script}#{token}」となる。さらに、指定されたロケーションヘッダは、「Location :https://hoge.example.com/{token_parse_script}#{token}」となる。これにより、通信端末１側では、このロケーションヘッダを受け取ると、自動的にリダイレクトされる。そして、通信端末１は、トークンを取り出せば、取り出したトークンにより、アプリケーション１０によって実施されるサービスに対応するデータのアクセス先へアクセスすることが可能となる。

制御部３３は、通信端末１から受信したトークンに基づいて、通信端末１のアプリケーション１０によるデータへのアクセスを制御する。

［通信端末側での処理手順］
次に、通信端末１側での処理手順について、図３を参照して説明する。図３は、実施例に係る通信端末側での処理のフローチャートを示す図である。なお、通信端末１では、サービスＡを実施するアプリケーション１０の認証を行うものとする。

まず、通信端末１は、ユーザ入力により指定されたアプリケーション１０を起動する（ステップＳ１１）。すると、アプリケーション１０が、ユーザのデータサーバ３に対して、自身の認証要求を送信する（ステップＳ１２）。例えば、アプリケーション１０は、アプリケーション１０に対応するアプリケーションサーバ２のＵＲＬおよびアプリケーションサーバ２上のトークン取り出しページのＵＲＬ（リダイレクトＵＲＬ）を、ユーザのデータサーバ３に送信する。なお、アプリケーションサーバ２のＵＲＬやリダイレクトＵＲＬは、アプリケーション１０の所定の領域に埋め込まれている。

続いて、ブラウザ１１は、データサーバ３からの応答により認証要求を問い合わせる画面を表示する（ステップＳ１３）。そして、ブラウザ１１は、アプリケーション１０に対応するアプリ識別情報２１１の取得要求をアプリケーションサーバ２のＵＲＬに送信する（ステップＳ１４）。

その後、ブラウザ１１は、アプリケーションサーバ２からアプリケーション１０に対応するアプリ識別情報２１１を受信したか否かを判定する（ステップＳ１５）。アプリケーション１０に対応するアプリ識別情報２１１を受信しなかったと判定した場合（ステップＳ１５；Ｎｏ）、ブラウザ１１は、アプリ認証が失敗したことを示す認証結果を出力させるべく、ステップＳ２２に移行する。

一方、アプリケーション１０に対応するアプリ識別情報２１１を受信したと判定した場合（ステップＳ１５；Ｙｅｓ）、ブラウザ１１は、受信したアプリ識別情報２１１を、認証要求を問い合わせる画面上に表示する（ステップＳ１６）。これにより、ブラウザ１１は、アプリケーション１０のアプリ識別情報を表示することで、ユーザにアプリケーション１０の正当性を委ねることができる。すなわち、ユーザは、ブラウザ１１によって表示されたアプリ識別情報を視認することで、アプリケーション１０の正当性を判別できる。

続いて、ブラウザ１１は、ユーザ入力によりユーザ名、パスワードを取得したか否かを判定する（ステップＳ１７）。すなわち、ブラウザ１１は、ユーザからデータサーバ３に対するログインがあったか否かを判定する。ユーザ名、パスワードを取得しなかったと判定した場合（ステップＳ１７；Ｎｏ）、ブラウザ１１は、アプリ認証が失敗したことを示す認証結果を出力させるべく、ステップＳ２２に移行する。

一方、ユーザ名、パスワードを取得したと判定した場合（ステップＳ１７；Ｙｅｓ）、ブラウザ１１は、ユーザ名、パスワードを、ユーザのデータサーバ３に送信する（ステップＳ１８）。

その後、ブラウザ１１は、データサーバ３から認証要求に対する応答を受信したか否かを判定する（ステップＳ１９）。認証要求に対する応答を受信しなかったと判定した場合（ステップＳ１９；Ｎｏ）、ブラウザ１１は、アプリ認証が失敗したことを示す認証結果を出力させるべく、ステップＳ２２に移行する。

一方、認証要求に対する応答を受信したと判定した場合（ステップＳ１９；Ｙｅｓ）、ブラウザ１１は、応答に含まれるアプリケーションサーバ２上のトークン取り出しページのＵＲＬから、トークン取り出しページをダウンロードする（ステップＳ２０）。認証要求に対する応答は、例えばロケーションヘッダに指定される。一例として、ロケーションヘッダに指定された応答が、「Location :https://hoge.example.com/{token_parse_script}#{token}」であるとする。すると、ブラウザ１１は、「https://hoge.example.com/{token_parse_script}」から、トークン取り出しページをダウンロードする。

そして、ブラウザ１１は、ダウンロードしたトークン取り出しページを実行し、トークンが取り出せるかどうかを確認する（ステップＳ２１）。

具体的には、ブラウザ１１が、応答に含まれるトークン取り出しページを実行する際に、アプリケーションのＵＲＬとトークン取出しページのＵＲＬの管理者が一致するか否かを判定する。管理者が一致するか否かの判定手法としては、例えば、応答として渡されたトークン取り出しページのＵＲＬと、アプリケーションのＵＲＬとが、同一、あるいは配下の階層に位置する関係であるかを、ＵＲＬの文字列を解析することにより判定する。あるいは、ブラウザ１１の機能により、アプリケーションのＵＲＬに対応するページ表示から、トークン取り出しページのＵＲＬに対応するページ表示に含まれるスクリプトが実行可能かを見ることにより、ドメインが一致するかの判定を行っても良い。認証要求のリダイレクトＵＲＬに対応するトークン取り出しページのＵＲＬと、アプリケーションのＵＲＬの管理者が一致したと判定された場合（ステップＳ２１；Ｙｅｓ）、ブラウザ１１はトークンをトークン取り出しページより取得することができる。これにより、アプリケーション１０の認証が完了したこととなるので、ブラウザ１１はアプリケーション１０にトークンを渡す（ステップＳ２３）。アプリケーション１０は、アプリ認証が成功したことを示す認証結果を、例えばモニタに出力しても良い。そして、通信端末１側の処理が終了する。

一方、応答に含まれるトークン取り出しページのＵＲＬとアプリケーションのＵＲＬの管理者が一致しないと判定された場合（ステップＳ２１；Ｎｏ）、ブラウザ１１はアプリケーション１０にトークンを渡さない。これに対応して、アプリケーション１０は、アプリ認証が失敗したことを示す認証結果を出力させるべく、ステップＳ２２に移行する。例えば、一定時間経過後もアプリケーション１０がトークンを受け取れない場合や、ブラウザ１１より認証失敗の通知をアプリケーション１０が受けた場合に、ステップＳ２２に移行する。ステップＳ２２では、通信端末１は、アプリ認証が失敗したことを示す認証結果を、例えばモニタに出力する（ステップＳ２２）。そして、通信端末１側の処理が終了する。

［データサーバ側での処理手順］
次に、データサーバ３側での処理手順について、図４を参照して説明する。図４は、実施例に係るデータサーバ側での処理のフローチャートを示す図である。なお、サービスＡを実施するアプリケーション１０の認証要求が通信端末１から送信されるものとする。

まず、認証部３２は、アプリケーションから認証要求を受信したか否かを判定する（ステップＳ３１）。認証要求には、アプリケーションに対応するアプリケーションサーバ２のＵＲＬおよびアプリケーションサーバ２上のトークン取り出しページのＵＲＬ（リダイレクトＵＲＬ）が含まれる。アプリケーションから認証要求を受信しなかったと判定した場合（ステップＳ３１；Ｎｏ）、認証部３２は、認証要求を受信するまで、判定処理を繰り返す。

一方、アプリケーションから認証要求を受信したと判定した場合（ステップＳ３１；Ｙｅｓ）、認証部３２は、認証要求を問い合わせる画面を通信端末１に送信する（ステップＳ３２）。ここでは、認証部３２は、アプリケーション１０から認証要求を受信したとする。

その後、認証部３２は、通信端末１からユーザ名、パスワードを受信したか否かを判定する（ステップＳ３３）。通信端末１からユーザ名、パスワードを受信しなかったと判定した場合（ステップＳ３３；Ｎｏ）、認証部３２は、アプリ認証が失敗したことを示す認証結果を送信させるべく、ステップＳ３９に移行する。

一方、通信端末１からユーザ名、パスワードを受信したと判定した場合（ステップＳ３３；Ｙｅｓ）、認証部３２は、ユーザ名、パスワードを用いて、自身のデータサーバ３に対するログインを試みる（ステップＳ３４）。認証部３２は、ログインに成功したか否かを判定する（ステップＳ３５）。ログインに失敗したと判定した場合（ステップＳ３５；Ｎｏ）、認証部３２は、アプリ認証が失敗したことを示す認証結果を送信させるべく、ステップＳ３９に移行する。

一方、ログインに成功したと判定した場合（ステップＳ３５；Ｙｅｓ）、認証部３２は、リダイレクトＵＲＬがアプリケーションサーバ２のＵＲＬの配下であるか否かを判定する（ステップＳ３６）。例えば、認証部３２は、リダイレクトＵＲＬの文字列内の部分文字列が、アプリケーションサーバ２のＵＲＬの文字列に含まれるか否かを判定する。リダイレクトＵＲＬがアプリケーションサーバ２のＵＲＬの配下でないと判定した場合（ステップＳ３６；Ｎｏ）、認証部３２は、アプリ認証が失敗したことを示す認証結果を送信させるべく、ステップＳ３９に移行する。これにより、認証部３２は、不当なアプリケーション１０からの認証要求であることを検証することができる。

ステップＳ３９では、認証部３２は、アプリ認証が失敗したことを示す認証結果を認証要求のあった通信端末１に送信する（ステップＳ３９）。そして、データサーバ側の処理が終了する。

一方、リダイレクトＵＲＬがアプリケーションサーバ２のＵＲＬの配下であると判定した場合（ステップＳ３６；Ｙｅｓ）、認証部３２は、トークンを払い出す（ステップＳ３７）。そして、認証部３２は、リダイレクトＵＲＬに、払い出したトークンをフラグメントで付与する。そして、認証部３２は、付与して得られた情報をロケーションヘッダに指定してブラウザ１１に戻す（ステップＳ３８）。そして、データサーバ側の処理が終了する。

［アプリケーションサーバ側での処理手順］
次に、アプリケーションサーバ２側での処理手順について、図５を参照して説明する。図５は、実施例に係るアプリケーションサーバ側での処理のフローチャートを示す図である。なお、通信端末１が、サービスＡを実施するアプリケーション１０の認証要求を行ったものとする。

まず、提示部２２は、通信端末１からアプリ識別情報２１１の取得要求を受信したか否かを判定する（ステップＳ４１）。通信端末１からアプリ識別情報２１１の取得要求を受信しなかったと判定した場合（ステップＳ４１；Ｎｏ）、提示部２２は、アプリ識別情報２１１の取得要求を受信するまで、判定処理を繰り返す。

一方、通信端末１からアプリ識別情報２１１の取得要求を受信したと判定した場合（ステップＳ４１；Ｙｅｓ）、提示部２２は、アプリ識別情報２１１を通信端末１に送信する（ステップＳ４２）。すなわち、認証要求で指定されたアプリケーションサーバ２のＵＲＬに対応するアプリケーションサーバ２の提示部２２が、自身の記憶部２１に記憶されたアプリ識別情報２１１を通信端末１に送信する、これにより、提示部２２は、通信端末１にアプリ識別情報２１１を提示できるので、通信端末１のユーザにアプリケーション１０の正当性を判断させることができる。そして、アプリケーションサーバ２側の処理が終了する。

［アプリケーション認証処理のシーケンス］
次に、アプリケーション認証処理のシーケンスを、図６を参照しながら説明する。図６は、実施例に係るアプリケーション認証処理のシーケンスを示す図である。なお、図６では、ユーザＵの通信端末１がアプリケーションＡの認証要求を行うこととする。アプリケーションＡは、サービスＡを提供する。

ユーザＵが通信端末１のアプリケーションＡを起動すると（ステップＳ９１）、起動後のアプリケーションＡが、認証要求をユーザＵのデータサーバ３に送信する（ステップＳ９２）。認証要求には、アプリケーションサーバ２のＵＲＬおよびアプリケーションサーバ２上のトークン取り出しページのＵＲＬ（リダイレクトＵＲＬ）が指定される。

ユーザＵのデータサーバ３側では、認証要求を受信した認証部３２が、認証要求を問い合わせる画面を通信端末１に送信する（ステップＳ９３）。この結果、通信端末１側では、ブラウザ１１が、認証要求を問い合わせる画面を表示する。そして、ブラウザ１１は、認証要求で指定されたアプリケーションサーバ２のＵＲＬに対して、アプリ識別情報２１１の取得要求を送信する（ステップＳ９４）。ここでは、アプリケーションサーバ２のＵＲＬは、サービスＡに対応するアプリケーションサーバ２であるとする。

サービスＡに対応するアプリケーションサーバ２側では、アプリ識別情報２１１の取得要求を受信した提示部２２が、自身の記憶部２１に記憶されたアプリ識別情報２１１を取得要求元の通信端末１に送信する（ステップＳ９５）。この結果、通信端末１側では、ブラウザ１１が、認証要求を問い合わせる画面上にアプリ識別情報２１１を表示する。ここでは、ブラウザ１１には、認証要求を問い合わせる画面上に、アプリケーションＡのアプリ識別情報２１１が表示されている。すなわち、アプリケーションＡのロゴ、アプリケーションＡの名称およびアプリケーションＡの説明が表示されている。

ここで、ユーザＵは、表示されたアプリ識別情報２１１がアプリケーションＡに対応する正当な情報であると判断すれば、ブラウザ１１にユーザの認証情報を入力してデータサーバ３に対してログインする。ここでは、ユーザＵは、表示されたアプリ識別情報２１１がアプリケーションＡに対応する正当な情報であると判断し、ユーザの認証情報としてユーザ名とパスワードを入力したとする。すると、ブラウザ１１は、入力されたユーザ名、パスワードを、ユーザＵのデータサーバ３に送信する（ステップＳ９７）。

ユーザＵのデータサーバ３側では、ユーザ名、パスワードを受信した認証部３２が、ユーザ名、パスワードを用いてログインする。そして、認証部３２は、ログインが成功し、且つ、リダイレクトＵＲＬがアプリケーションサーバ２のＵＲＬの配下であれば、トークンを払い出す。そして、認証部３２は、リダイレクトＵＲＬであるアプリケーションサーバ２上のトークン取り出しページのＵＲＬに、払い出したトークンをフラグメントで付与する。そして、認証部３２は、付与して得られた情報をロケーションヘッダに指定して、認証要求に対する応答として通信端末１のブラウザ１１に返す（ステップＳ９８）。

通信端末１のブラウザ１１は、応答に含まれるアプリケーションサーバ２上のトークン取り出しページのＵＲＬから、トークン取り出しページ２１２をダウンロードする（ステップＳ９９）。そして、ブラウザ１１は、ダウンロードしたトークン取り出しページを実行し、トークンが取り出せるかどうかを確認する。そして、ブラウザ１１は、トークンが取り出せる場合、取り出したトークンを認証要求に対する応答としてアプリケーションＡに戻す（ステップＳ１００）。

通信端末１のアプリケーションＡは、ブラウザ１１から認証要求に対する応答としてトークンを受信すると、トークンを用いて、ユーザＵのデータサーバ３へアクセスできる。

ところで、実施例では、ブラウザ１１が、認証要求で指定されたアプリケーションサーバ２のＵＲＬから、当該アプリケーションサーバ２のＵＲＬに対応するアプリ識別情報２１１を取得するようにした。しかしながら、実施例では、これに限定されず、データサーバ３が、認証要求で指定されたアプリケーションサーバ２のＵＲＬから、当該アプリケーションサーバ２のＵＲＬに対応するアプリ識別情報２１１を取得する場合であっても良い。かかる場合、データサーバ３は、取得したアプリ識別情報２１１と、認証要求をユーザに問い合わせる画面とを通信端末１のブラウザ１１に送信すれば良い。

そこで、アプリケーション認証処理の変形例として、データサーバ３が、認証要求で指定されたアプリケーションサーバ２のＵＲＬから、当該アプリケーションサーバ２のＵＲＬに対応するアプリ識別情報２１１を取得する場合について説明する。

［アプリケーション認証処理の変形例のシーケンス］
図７は、実施例に係るアプリケーション認証処理の変形例のシーケンスを示す図である。なお、図７では、図６に示すアプリケーション認証処理のシーケンスと同一の動作については同一符号を付すことで、その重複する動作の説明については簡単に説明する。図７も、図６と同様に、ユーザＵの通信端末１がアプリケーションＡの認証要求を行うこととする。アプリケーションＡは、サービスＡを提供する。

ユーザＵが通信端末１のアプリケーションＡを起動し（ステップＳ９１）、起動後のアプリケーションＡが、認証要求をユーザＵのデータサーバ３に送信する（ステップＳ９２）。認証要求には、アプリケーションサーバ２のＵＲＬおよびアプリケーションサーバ２上のトークン取り出しページのＵＲＬ（リダイレクトＵＲＬ）が指定される。

ユーザＵのデータサーバ３側では、認証要求を受信した認証部３２が、認証要求で指定されたアプリケーションサーバ２のＵＲＬに対して、アプリ識別情報２１１の取得要求を送信する（ステップＳ９３Ａ）。ここでは、アプリケーションサーバ２のＵＲＬは、サービスＡに対応するアプリケーションサーバ２であるとする。

サービスＡに対応するアプリケーションサーバ２側では、アプリ識別情報２１１の取得要求を受信した提示部２２が、自身の記憶部２１に記憶されたアプリ識別情報２１１を取得要求元のユーザＵのデータサーバ３に送信する（ステップＳ９３Ｂ）。ユーザＵのデータサーバ３側では、アプリ識別情報２１１を取得した認証部３２が、アプリ識別情報２１１と認証要求を問い合わせる画面とを通信端末１に送信する（ステップＳ９３Ｃ）。

この結果、通信端末１側では、ブラウザ１１が、認証要求を問い合わせる画面上にアプリ識別情報２１を表示する。ここでは、ブラウザ１１には、認証要求を問い合わせる画面上に、アプリケーションＡのアプリ識別情報２１１が表示されている。すなわち、アプリケーションＡのロゴ、アプリケーションＡの名称およびアプリケーションＡの説明が表示されている。

ここで、ユーザＵは、表示されたアプリ識別情報２１１がアプリケーションＡに対応する正当な情報であると判断し、ユーザの認証情報としてユーザ名とパスワードを入力したとする。すると、ブラウザ１１は、入力されたユーザ名、パスワードを、ユーザＵのデータサーバ３に送信する（ステップＳ９７）。

［アプリ認証処理］
次に、不正なアプリケーションが認証要求をする場合について、図８Ａ〜図８Ｃを参照して説明する。図８Ａ〜図８Ｃは、不正なアプリケーションが認証要求をする例を示す図である。なお、図８Ａ〜図８Ｃでは、アプリケーションを「アプリ」、アプリケーションサーバを「アプリサーバ」と略記する。また、アプリＢが不正なアプリケーションであり、正当なアプリＡになりすましてアプリＡに対応するサービスＡの記憶領域にアクセスしようとしているものとする。

図８Ａに示すように、アプリＢは、認証要求をユーザＵのデータサーバ３に送信する。認証要求には、アプリＢによって実施されるサービスＢに対応するアプリサーバ（以降、アプリサーバＢという）のＵＲＬおよびアプリサーバＢ上のトークン取り出しページのＵＲＬ（リダイレクトＵＲＬ）が指定されている。

かかる場合、ユーザＵのデータサーバ３は、認証要求を問い合わせる画面を通信端末１に送信し、ブラウザ１１が、認証要求を問い合わせる画面を表示する。そして、ブラウザ１１が、認証要求で指定されたアプリサーバＢのＵＲＬからアプリ識別情報２１１を取得し、取得したアプリ識別情報２１１を表示する。ここでは、アプリ識別情報２１１は、アプリＢの識別情報である。すなわち、ブラウザ１１は、アプリＢの識別情報を表示する。これにより、ユーザＵは、表示されたアプリＢの識別情報を視認することで、不正なアプリＢが動作していることを判定できる。この結果、アプリケーション認証処理は、アプリＢによる、アプリＡに対応するサービスＡの記憶領域のアクセスを回避できる。

図８Ｂに示すように、アプリＢは、認証要求をユーザＵのデータサーバ３に送信する。認証要求には、アプリＡによって実施されるサービスＡに対応するアプリサーバ（以降、アプリサーバＡという）のＵＲＬおよびアプリサーバＢ上のトークン取り出しページのＵＲＬ（リダイレクトＵＲＬ）が指定されている。

かかる場合、ユーザＵのデータサーバ３は、リダイレクトＵＲＬがアプリサーバＡのＵＲＬの配下であれば、トークンを払い出し、リダイレクトＵＲＬに、払い出したトークンをフラグメントで付与した情報をブラウザ１１に戻す。ところが、リダイレクトＵＲＬは、アプリサーバＢ上のトークン取り出しページのＵＲＬであるので、リダイレクトＵＲＬはアプリサーバＡのＵＲＬの配下でない。これにより、データサーバ３は、ブラウザ１１に応答を戻せないので、その後のアプリＢによる、アプリＡに対応するサービスＡの記憶領域のアクセスを回避できる。

図８Ｃに示すように、アプリＢは、認証要求をユーザＵのデータサーバ３に送信する。認証要求には、アプリＡによって実施されるサービスＡに対応するアプリサーバＡのＵＲＬおよびアプリサーバＡ上のトークン取り出しページのＵＲＬ（リダイレクトＵＲＬ）が指定されている。

かかる場合、ユーザＵのデータサーバ３は、認証要求を問い合わせる画面を通信端末１に送信し、ブラウザ１１が、認証要求を問い合わせる画面を表示する。そして、ブラウザ１１が、認証要求で指定されたアプリサーバＡのＵＲＬからアプリ識別情報２１１を取得し、取得したアプリ識別情報２１１を表示する。ここでは、アプリ識別情報２１１は、アプリＡの識別情報である。すなわち、ブラウザ１１は、アプリＡの識別情報を表示する。

そして、ユーザＵは、表示されたアプリＡの識別情報を視認し、ユーザＵのデータサーバ３にログインしたとする。ユーザＵのデータサーバ３は、リダイレクトＵＲＬがアプリサーバＡのＵＲＬの配下であるので、トークンを払い出す。そして、データサーバ３は、リダイレクトＵＲＬであるアプリサーバＡ上のトークン取り出しページのＵＲＬに、払い出したトークンをフラグメントで付与する。そして、データサーバ３は、認証要求に対する応答として、付与して得られた情報をロケーションヘッダに指定してブラウザ１１に戻す。

ブラウザ１１では、応答に含まれるアプリサーバＡ上のトークン取り出しページのＵＲＬから、トークン取り出しページ２１２をダウンロードする。そして、ブラウザ１１は、ダウンロードしたトークン取り出しページを実行し、トークンが取り出せるかどうかを確認する。例えば、ブラウザ１１は、応答として渡されたトークン取り出しページのＵＲＬと、アプリケーションのＵＲＬとが、同一、あるいは配下の階層に位置する関係であるかを、ＵＲＬの文字列を解析することにより判定する。ここでは、アプリサーバＡのＵＲＬとアプリサーバＡ上のトークン取り出しページのＵＲＬとが同一、あるいは配下の階層に位置する関係であるので、トークンを取り出せると確認される。ところが、ブラウザ１１は、トークンを取り出しても、取り出したトークンを認証要求に対する応答としてアプリＡに渡すことになる。これにより、認証要求に対する応答の渡し先がアプリＢとならないので、アプリＢは、アプリＡに対応するサービスＡの記憶領域のアクセスをすることができない。すなわち、アプリケーション認証処理は、アプリＢによる、アプリＡに対応するサービスＡの記憶領域のアクセスを回避できる。

このようにして、図８Ａ〜図８Ｃのいずれのケースであっても、アプリケーション認証処理は、不正なアプリＢによる、アプリＡに対応するサービスＡの記憶領域のアクセスを回避できる。

なお、認証部３２は、リダイレクト情報がアプリケーション関連情報の配下であるかを判定する。上記実施例では、認証部３２は、アプリケーションサーバ２上のトークン取り出しページのＵＲＬ内部分文字列が、アプリケーション１０に対応するアプリケーションサーバ２のＵＲＬ内文字列に含まれるか否かを判定すると説明した。しかしながら、認証部３２は、これに限定されず、別サーバに、リダイレクト情報がアプリケーション関連情報の配下であるか否かを問い合わせるようにしても良い。かかる場合、認証部３２は、アプリケーションサーバ２上のトークン取り出しページのＵＲＬとアプリケーション１０に対応するアプリケーションサーバ２のＵＲＬとを別サーバに引き渡す。そして、別サーバは、アプリケーションサーバ２上のトークン取り出しページのＵＲＬがアプリケーション１０に対応するアプリケーションサーバ２のＵＲＬの配下であるか否かを判定し、判定結果を認証部３２に返却するようにすれば良い。これにより、認証部３２は、認証要求で指定された、リダイレクト情報とアプリケーション関連情報との関係で、不当なトークン取り出しページのＵＲＬを検知できる。

また、認証部３２は、通信端末１からデータサーバ３に対するログインがなされると、リダイレクト情報がアプリケーション関連情報の配下であるかを判定すると説明した。しかしながら、認証部３２は、これに限定されず、通信端末１上で動作するアプリケーション１０から、リダイレクト情報とアプリケーション関連情報が指定された認証要求を受信する。そして、認証部３２は、認証要求に指定されたリダイレクト情報が認証要求に指定されたアプリケーション関連情報の配下であるかを判定するようにしても良い。これにより、認証部３２は、リダイレクト情報とアプリケーション関連情報との関係で、不当なリダイレクト情報を早期に検知できる。

［実施例の効果］
上記実施例によれば、認証部３２は、通信端末１上で動作するアプリケーション１０から、アプリケーション１０に対応するアプリケーションサーバ２のＵＲＬおよびアプリケーションサーバ２上のトークン取り出しページのＵＲＬを含む認証要求を受け付ける。そして、認証部３２は、トークン取り出しページのＵＲＬが正当であると判断したとき、アプリケーションサーバ２のＵＲＬに対応するアプリ識別情報２１１を含む、認証要求に対する応答を、トークン取り出しページのＵＲＬに対応するリダイレクト先に送信する。かかる構成によれば、認証部３２は、アプリ識別情報２１１をトークン取り出しページのＵＲＬに対応するリダイレクト先に送信するので、アプリケーション１０の正当性の判断をリダイレクト先のユーザに委ねることができる。この結果、データ参照システム９は、データサーバ３毎にアプリケーションの認証に係る情報を登録していなくても、アプリケーション１０の正当性を判定することができる。

また、上記実施例によれば、認証部３２は、アプリケーションサーバ２のＵＲＬに対応するアプリ識別情報２１１を、認証要求に対する応答として通信端末１に送信する。そして、認証部３２は、通信端末１から、ユーザの認証情報を受付けると、トークンを払い出し、払い出したトークンを、認証要求に対する応答として、リダイレクト情報に対応するリダイレクト先に送信する。かかる構成によれば、認証部３２は、認証要求に対する応答として、アプリ識別情報２１１を送信し、その後トークンを送信するので、段階的にアプリケーション１０の正当性を判定することができる。

また、上記実施例によれば、認証部３２は、認証要求を受け付けると、リダイレクト情報がアプリケーション関連情報の配下であるか否かを判定することによってリダイレクト情報の正当性を判断する。かかる構成によれば、認証部３２は、不当なリダイレクト情報を検知できる。すなわち、認証部３２は、認証要求をしたアプリケーション１０が正当でないことを検知できる。

また、上記実施例によれば、アプリケーション１０は、データサーバ３に対し、アプリケーション１０に対応するアプリケーションサーバ２のＵＲＬおよびアプリケーションサーバ２上のトークン取り出しページのＵＲＬを含む認証要求を送信する。そして、ブラウザ１１は、認証要求に対する応答をデータサーバ３より受けたときは、応答に含まれる、アプリケーションサーバ２のＵＲＬに対応するアプリ識別情報２１１を表示する。そして、アプリケーション１０は、認証要求に対する応答をデータサーバ３より受けたときは、応答のリダイレクト先情報と認証要求に含まれる情報とに基づき、応答の正当性を検証する。かかる構成によれば、ブラウザ１１が、アプリケーションサーバ２のＵＲＬに対応するアプリ識別情報２１１を表示するので、ユーザに、アプリケーションサーバ２のＵＲＬに対応するアプリケーション１０の正当性を判断させることができる。また、アプリケーション１０は、応答のリダイレクト先情報と認証要求に含まれる情報に基づき、応答の正当性を検証するので、応答に至った認証要求を指示したアプリケーションの正当性を判定できる。

なお、アプリケーションサーバ２は、既知のパーソナルコンピュータ、ワークステーション等の情報処理装置に、上記した記憶部２１と提示部２２等の各機能を搭載することによって実現することができる。また、データサーバ３は、既知のパーソナルコンピュータ、ワークステーション等の情報処理装置に、上記した記憶部３１と認証部３２等の各機能を搭載することによって実現することができる。

また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、認証部３２と制御部３３とを１個の部として統合しても良い。一方、認証部３２を、リダイレクト情報の正当性を判定する第１の認証部とユーザの正当性を認証する第２の認証部とに分散しても良い。また、記憶部２１をアプリケーションサーバ２の外部装置としてネットワーク４経由で接続するようにしても良い。

［サーバのハードウェア構成］
図９は、サーバのハードウェア構成の一例を示す図である。ここでいうサーバとは、アプリケーションサーバ２およびデータサーバ３を意味する。図９に示すように、サーバ１０００は、ＲＡＭ１０１０と、ネットワークインタフェース装置１０２０と、ＨＤＤ１０３０と、ＣＰＵ１０４０、媒体読取装置１０５０およびバス１０６０とを有する。ＲＡＭ１０１０、ネットワークインタフェース装置１０２０、ＨＤＤ１０３０、ＣＰＵ１０４０、媒体読取装置１０５０は、バス１０６０によって接続されている。

そして、データサーバ３の場合、ＨＤＤ１０３０には、図１に示した認証部３２、制御部３３の機能を実現するアプリケーション認証プログラムなどのプログラムが記憶される。また、ＨＤＤ１０３０には、図１に示した記憶部３１に記憶されるサービスＡ、サービスＢなど各種サービスに対応するデータが記憶される。そして、ＣＰＵ１０４０がアプリケーション認証プログラムをＨＤＤ１０３０から読み出してＲＡＭ１０１０にロードすることにより、アプリケーション認証プログラムは、アプリケーション認証プロセスとして機能するようになる。そして、アプリケーション認証プロセスは、ＨＤＤ１０３０から読み出した情報などを適宜ＲＡＭ１０１０上の自身に割り当てられた領域にロードし、このロードしたデータなどに基づいて各種データ処理を実行する。

また、アプリケーションサーバ２の場合、ＨＤＤ１０３０には、図１に示した提示部２２の機能を実現するアプリケーション認証プログラムなどのプログラムが記憶される。また、ＨＤＤ１０３０には、図１に示した記憶部２１に記憶されるアプリケーション２１０、アプリ識別情報２１１など各種データが記憶される。そして、ＣＰＵ１０４０がアプリケーション認証プログラムをＨＤＤ１０３０から読み出してＲＡＭ１０１０にロードすることにより、アプリケーション認証プログラムは、アプリケーション認証プロセスとして機能するようになる。そして、アプリケーション認証プロセスは、ＨＤＤ１０３０から読み出した情報などを適宜ＲＡＭ１０１０上の自身に割り当てられた領域にロードし、このロードしたデータなどに基づいて各種データ処理を実行する。

媒体読取装置１０５０は、アプリケーション認証プログラムなどのプログラムがＨＤＤ１０３０に記憶されていない場合であっても、プログラムを記憶する媒体などからアプリケーション認証プログラムなどのプログラムを読み取る。媒体読取装置１０５０には、例えばＣＤ−ＲＯＭや光ディスク装置がある。

ネットワークインタフェース装置１０２０は、外部装置とネットワーク経由で接続する装置であり、無線または有線に対応する装置である。

［通信端末のハードウェア構成］
図１０は、通信端末のハードウェア構成の一例を示す図である。図１０に示すように、通信端末９００は、無線通信部９１０と、表示部９２０と、音声入出力部９３０と、入力部９４０と、プロセッサ９５０と、記憶部９６０とを有する。無線通信部９１０、表示部９２０、音声入出力部９３０、入力部９４０および記憶部９６０は、それぞれプロセッサ９５０と接続されている。

記憶部９６０は、プログラム記憶部９６１と、データ記憶部９６２と、ＲＡＭ（Random Access Memory）９６３とを有する。プログラム記憶部９６１には、図１に示したアプリケーション１０、ブラウザ１１を含むアプリケーション認証プログラムが記憶される。データ記憶部９６２には、例えば、データサーバ３およびアプリケーションサーバ２から送信される認証要求を問い合わせる画面やアプリ識別情報２１１など各種データが記憶される。なお、記憶部９６０は、例えば、ＲＡＭ、フラッシュメモリ（flash memory）などの半導体メモリ素子、または、ハードディスク（ＨＤＤ：Hard Disk Drive）、光ディスクなどの記憶装置である。

プロセッサ９５０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路またはＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路である。そして、プロセッサ９５０がアプリケーション認証プログラムを記憶部９６０から読み出してＲＡＭ９６３にロードすることにより、アプリケーション認証プログラムなどのプログラムは、アプリケーション認証プロセスなどのプロセスとして機能するようになる。そして、アプリケーション認証プロセスは、データ記憶部９６２から読み出した情報などを適宜ＲＡＭ９６３上の自身に割り当てられた領域にロードし、このロードしたデータなどに基づいて各種データ処理を実行する。

なお、上記のアプリケーション認証プログラムは、公衆回線、インターネット、ＬＡＮ、ＷＡＮ（Wide Area Network）などを介してサーバ１０００、通信端末９００に接続される他のコンピュータ（またはサーバ）などに記憶されるようにしても良い。この場合には、サーバ１０００がネットワークインタフェース装置１０２０を介して他のコンピュータなどからアプリケーション認証プログラムを読み出して実行する。通信端末９００が無線通信部９１０を介して他のコンピュータなどからアプリケーション認証プログラムを読み出して実行する。

１通信端末
２アプリケーションサーバ
３データサーバ
４ネットワーク
９データ参照システム
１０、２１０アプリケーション
１１ブラウザ
２１，３１記憶部
２２提示部
２１１アプリ識別情報
３２認証部
３３制御部

Claims

コンピュータに、
端末から送信される前記端末で動作するアプリケーションに関するアプリケーション関
連情報およびリダイレクト情報を含むアクセス要求を受付け、
前記アプリケーション関連情報に対応する特定情報と認証要求をユーザに問い合わせる
画面とを前記アクセス要求を送信した前記端末に送信し、
前記端末から認証情報を受け付け、前記認証情報に基づいて認証に成功し、且つ、前記
リダイレクト情報が正当であると判断したとき、前記リダイレクト情報に対応するリダイ
レクト先を含むアクセス応答を、前記端末に送信する、
処理を実行させることを特徴とするアプリケーション認証プログラム。
前記アクセス応答を前記端末に送信する処理は、トークンを前記リダイレクト先に付与した情報を、前記アクセス要求に対する応答として送信する
処理を実行させることを特徴とする請求項１に記載のアプリケーション認証プログラム。
前記アクセス要求を受け付けると、前記リダイレクト情報が前記アプリケーション関連情報の配下であるか否かによって前記リダイレクト情報の正当性を判断する
処理を実行させることを特徴とする請求項１に記載のアプリケーション認証プログラム。
コンピュータに、
端末で動作するアプリケーションより、認証サーバに対し、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を送信し、
前記アクセス要求に対する第１の応答を前記認証サーバより受けたときは、前記第１の応答に含まれる前記アプリケーション関連情報に対応する特定情報と、前記第１の応答に含まれる認証要求をユーザに問い合わせる画面とを画面上に表示し、
前記アクセス要求に対する第２の応答を前記認証サーバより受けたときは、前記第２の応答に含まれるリダイレクト先の情報と前記アプリケーションの前記アクセス要求に含まれる情報とに基づき、前記第２の応答の正当性を検証する、
処理を実行させることを特徴とするアプリケーション認証プログラム。
端末から送信される前記端末で動作するアプリケーションに関するアプリケーション関連情報およびリダイレクト情報を含むアクセス要求を受付ける受付部と、
前記アプリケーション関連情報に対応する特定情報と認証要求をユーザに問い合わせる
画面とを前記アクセス要求を送信した前記端末に送信する送信部と、
前記端末から認証情報を受け付け、前記認証情報に基づいて認証に成功し、且つ、前記リダイレクト情報が正当であると判断したとき、前記リダイレクト情報に対応するリダイレクト先を含むアクセス応答を、前記端末に送信する送信部と、
を有することを特徴とする認証サーバ。
端末で動作するアプリケーションより、認証サーバに対し、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を送信する送信部と、
前記送信部によって送信された前記アクセス要求に対する第１の応答を前記認証サーバより受けたときは、前記第１の応答に含まれる前記アプリケーション関連情報に対応する特定情報と、前記第１の応答に含まれる認証要求をユーザに問い合わせる画面とを画面上に表示する表示部と、
前記送信部によって送信された前記アクセス要求に対する第２の応答を前記認証サーバより受けたときは、前記第２の応答に含まれるリダイレクト先の情報と前記アプリケーションの前記アクセス要求に含まれる情報に基づき、前記第２の応答の正当性を検証する検証部と、
を有することを特徴とする端末。
端末と認証サーバとを有するデータ参照システムにおけるアプリケーション認証方法であって、
前記端末が、
当該端末で動作するアプリケーションより、前記認証サーバに対し、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を送信し、
前記認証サーバが、
前記端末から送信される前記端末で動作するアプリケーションに関するアプリケーション関連情報およびリダイレクト情報を含むアクセス要求を受付け、
前記アプリケーション関連情報に対応する特定情報と認証要求をユーザに問い合わせる
画面とを含む第１の応答を前記アクセス要求を送信した前記端末に送信し、
前記端末から認証情報を受け付け、前記認証情報に基づいて認証に成功し、且つ、前記リダイレクト情報が正当であると判断したとき、前記リダイレクト情報に対応するリダイレクト先を含む第２の応答を、前記端末に送信し、
前記端末が、
前記アクセス要求に対する第１の応答を前記認証サーバより受けたときは、前記第１の応答に含まれる前記アプリケーション関連情報に対応する特定情報と、前記第１の応答に含まれる認証要求をユーザに問い合わせる画面とを画面上に表示し、
前記アクセス要求に対する第２の応答を前記認証サーバより受けたときは、前記第２の応答に含まれるリダイレクト先の情報と前記アプリケーションの前記アクセス要求に含まれる情報とに基づき、前記第２の応答の正当性を検証する、
各処理を実行することを特徴とするアプリケーション認証方法。