図面 (/)

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

出願人 富士通株式会社
発明者 三好直樹下野暁生吉無田護水野翔平
出願日 2013年1月30日 (8年7ヶ月経過) 出願番号 2013-016251
公開日 2014年8月21日 (7年0ヶ月経過) 公開番号 2014-149561
状態 特許登録済
技術分野 記憶装置の機密保護 オンライン・システムの機密保護
主要キーワード アプリケーション特定情報 アプリケーション関連情報 アプリ識別情報 アプリリスト アクセス要求情報 ネットワークインタフェース装置 リダイレクト情報 アプリサーバ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2014年8月21日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (16)

課題

アプリケーション正当性を判定する。

解決手段

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

概要

背景

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

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

概要

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

目的

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

効果

実績

技術文献被引用数
2件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

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

請求項2

該リダイレクト先に送信する処理は、前記アプリケーション関連情報に対応するアプリケーション特定情報を、前記アクセス要求に対する応答として送信し、前記端末から、ユーザの認証情報を受付けると、トークンを、前記アクセス要求に対する応答として送信する処理を実行させることを特徴とする請求項1に記載のアプリケーション認証プログラム。

請求項3

前記アクセス要求を受け付けると、前記リダイレクト情報が前記アプリケーション関連情報の配下であるか否かによって前記リダイレクト情報の正当性を判断する処理を実行させることを特徴とする請求項1に記載のアプリケーション認証プログラム。

請求項4

コンピュータに、端末上で動作するアプリケーションより、認証サーバに対し、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を送信し、前記アクセス要求に対する応答を前記認証サーバより受けたときは、前記応答に含まれる前記アプリケーション関連情報に対応するアプリケーション特定情報を表示するとともに、前記応答のリダイレクト先情報と前記アプリケーションのアクセス要求情報とに基づき、前記応答の正当性を検証する、処理を実行させることを特徴とするアプリケーション認証プログラム。

請求項5

端末上で動作するアプリケーションから、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を受付け、前記アクセス要求に含まれた情報に基づいて、前記リダイレクト情報が正当であるか否かを判定する判定部と、前記判定部によって前記リダイレクト情報が正当であると判定されたとき、前記アクセス要求に対する応答であって、前記アプリケーション関連情報に対応するアプリケーション特定情報を含むアクセス応答を、前記リダイレクト情報に対応するリダイレクト先に送信する送信部と、を有することを特徴とする認証サーバ。

請求項6

端末上で動作するアプリケーションより、認証サーバに対し、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を送信する送信部と、前記送信部によって送信された前記アクセス要求に対する第1の応答を前記認証サーバより受けたときは、前記第1の応答に含まれる前記アプリケーション関連情報に対応するアプリケーション特定情報を表示する表示部と、前記送信部によって送信された前記アクセス要求に対する第2の応答を前記認証サーバより受けたときは、前記第2の応答のリダイレクト先情報と前記アプリケーションのアクセス要求情報に基づき、前記応答の正当性を検証する検証部と、を有することを特徴とする端末。

請求項7

端末と認証サーバとを有するデータ参照システムにおけるアプリケーション認証方法であって、前記端末が、当該端末上で動作するアプリケーションより、前記認証サーバに対し、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を送信し、前記認証サーバが、前記端末上で動作するアプリケーションから、アプリケーション関連情報およびリダイレクト情報を含むアクセス要求を受付け、前記リダイレクト情報が正当であると判断したとき、前記アクセス要求に対する応答であって、前記アプリケーション関連情報に対応するアプリケーション特定情報を含むアクセス応答を、前記リダイレクト情報に対応するリダイレクト先を含む前記端末に送信し、前記端末が、前記アクセス応答を前記認証サーバより受けたときは、前記アクセス応答に含まれる前記アプリケーション関連情報に対応するアプリケーション特定情報を表示するとともに、前記アクセス応答のリダイレクト先情報と前記アプリケーションのアクセス要求情報に基づき、前記アクセス応答の正当性を検証する、各処理を実行することを特徴とするアプリケーション認証方法。

技術分野

0001

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

背景技術

0002

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

0003

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

先行技術

0004

特開2012−194722号公報

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

0005

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

0006

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

0007

図11に示すように、OAuth2を利用したサービスでは、アプリA,B,C,Dの認証情報として例えばアプリリストを、サービス提供側の例えばアプリケーションの提供者が認証サーバに登録する。そして、認証サーバは、OAuth2を利用してアプリA,B,C,Dの各アプリケーションのアプリ認証を行うことができる。

0008

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

0009

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

0010

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

0011

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

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

0012

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

発明の効果

0013

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

図面の簡単な説明

0014

図1は、実施例に係るデータ参照システムの全体構成を示すブロック図である。
図2は、アプリ識別情報の内容の一例を示す図である。
図3は、実施例に係る通信端末側での処理のフローチャートを示す図である。
図4は、実施例に係るデータサーバ側での処理のフローチャートを示す図である。
図5は、実施例に係るアプリケーションサーバ側での処理のフローチャートを示す図である。
図6は、実施例に係るアプリケーション認証処理のシーケンスを示す図である。
図7は、実施例に係るアプリケーション認証処理の変形例のシーケンスを示す図である。
図8Aは、不正なアプリケーションが認証要求をする例を示す図(1)である。
図8Bは、不正なアプリケーションが認証要求をする例を示す図(2)である。
図8Cは、不正なアプリケーションが認証要求をする例を示す図(3)である。
図9は、サーバハードウェア構成の一例を示す図である。
図10は、通信端末のハードウェア構成の一例を示す図である。
図11は、OAuth2を利用したサービスを示す図である。
図12は、アプリ認証が煩雑になるという問題を示す図である。
図13は、不当なアプリケーションに騙られた場合の一例を示す図である。

0015

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

0016

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

0017

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

0018

通信端末1には、アプリケーション10およびブラウザ11が記憶される。通信端末1は、例えば、スマートフォンであったり、PHS(Personal Handyphone System)であったり、PDA(Personal Digital Assistants)であったり、PC(Personal Computer)であっても良く、通信可能な通信端末であれば良い。

0019

アプリケーション10は、通信端末1がアプリケーションサーバ2によって提供されるサービスを受けるためのソフトウェアである。通信端末1は、ユーザが提供を受けたいサービスに対応するアプリケーションを、当該サービスを提供するアプリケーションサーバ2から取得し、例えば、RAM(Random Access Memory)やHDD(Hard Disk Drive)に格納する。

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

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

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

続いて、ブラウザ11は、データサーバ3からの応答により認証要求を問い合わせる画面を表示する(ステップS13)。そして、ブラウザ11は、アプリケーション10に対応するアプリ識別情報211の取得要求をアプリケーションサーバ2のURLに送信する(ステップS14)。

0036

その後、ブラウザ11は、アプリケーションサーバ2からアプリケーション10に対応するアプリ識別情報211を受信したか否かを判定する(ステップS15)。アプリケーション10に対応するアプリ識別情報211を受信しなかったと判定した場合(ステップS15;No)、ブラウザ11は、アプリ認証が失敗したことを示す認証結果を出力させるべく、ステップS22に移行する。

0037

一方、アプリケーション10に対応するアプリ識別情報211を受信したと判定した場合(ステップS15;Yes)、ブラウザ11は、受信したアプリ識別情報211を、認証要求を問い合わせる画面上に表示する(ステップS16)。これにより、ブラウザ11は、アプリケーション10のアプリ識別情報を表示することで、ユーザにアプリケーション10の正当性を委ねることができる。すなわち、ユーザは、ブラウザ11によって表示されたアプリ識別情報を視認することで、アプリケーション10の正当性を判別できる。

0038

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

0039

一方、ユーザ名、パスワードを取得したと判定した場合(ステップS17;Yes)、ブラウザ11は、ユーザ名、パスワードを、ユーザのデータサーバ3に送信する(ステップS18)。

0040

その後、ブラウザ11は、データサーバ3から認証要求に対する応答を受信したか否かを判定する(ステップS19)。認証要求に対する応答を受信しなかったと判定した場合(ステップS19;No)、ブラウザ11は、アプリ認証が失敗したことを示す認証結果を出力させるべく、ステップS22に移行する。

0041

一方、認証要求に対する応答を受信したと判定した場合(ステップS19;Yes)、ブラウザ11は、応答に含まれるアプリケーションサーバ2上のトークン取り出しページのURLから、トークン取り出しページをダウンロードする(ステップS20)。認証要求に対する応答は、例えばロケーションヘッダに指定される。一例として、ロケーションヘッダに指定された応答が、「Location :https://hoge.example.com/{token_parse_script}#{token}」であるとする。すると、ブラウザ11は、「https://hoge.example.com/{token_parse_script}」から、トークン取り出しページをダウンロードする。

0042

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

0043

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

0044

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

0045

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

0046

まず、認証部32は、アプリケーションから認証要求を受信したか否かを判定する(ステップS31)。認証要求には、アプリケーションに対応するアプリケーションサーバ2のURLおよびアプリケーションサーバ2上のトークン取り出しページのURL(リダイレクトURL)が含まれる。アプリケーションから認証要求を受信しなかったと判定した場合(ステップS31;No)、認証部32は、認証要求を受信するまで、判定処理を繰り返す。

0047

一方、アプリケーションから認証要求を受信したと判定した場合(ステップS31;Yes)、認証部32は、認証要求を問い合わせる画面を通信端末1に送信する(ステップS32)。ここでは、認証部32は、アプリケーション10から認証要求を受信したとする。

0048

その後、認証部32は、通信端末1からユーザ名、パスワードを受信したか否かを判定する(ステップS33)。通信端末1からユーザ名、パスワードを受信しなかったと判定した場合(ステップS33;No)、認証部32は、アプリ認証が失敗したことを示す認証結果を送信させるべく、ステップS39に移行する。

0049

一方、通信端末1からユーザ名、パスワードを受信したと判定した場合(ステップS33;Yes)、認証部32は、ユーザ名、パスワードを用いて、自身のデータサーバ3に対するログインを試みる(ステップS34)。認証部32は、ログインに成功したか否かを判定する(ステップS35)。ログインに失敗したと判定した場合(ステップS35;No)、認証部32は、アプリ認証が失敗したことを示す認証結果を送信させるべく、ステップS39に移行する。

0050

一方、ログインに成功したと判定した場合(ステップS35;Yes)、認証部32は、リダイレクトURLがアプリケーションサーバ2のURLの配下であるか否かを判定する(ステップS36)。例えば、認証部32は、リダイレクトURLの文字列内の部分文字列が、アプリケーションサーバ2のURLの文字列に含まれるか否かを判定する。リダイレクトURLがアプリケーションサーバ2のURLの配下でないと判定した場合(ステップS36;No)、認証部32は、アプリ認証が失敗したことを示す認証結果を送信させるべく、ステップS39に移行する。これにより、認証部32は、不当なアプリケーション10からの認証要求であることを検証することができる。

0051

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

0052

一方、リダイレクトURLがアプリケーションサーバ2のURLの配下であると判定した場合(ステップS36;Yes)、認証部32は、トークンを払い出す(ステップS37)。そして、認証部32は、リダイレクトURLに、払い出したトークンをフラグメントで付与する。そして、認証部32は、付与して得られた情報をロケーションヘッダに指定してブラウザ11に戻す(ステップS38)。そして、データサーバ側の処理が終了する。

0053

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

0054

まず、提示部22は、通信端末1からアプリ識別情報211の取得要求を受信したか否かを判定する(ステップS41)。通信端末1からアプリ識別情報211の取得要求を受信しなかったと判定した場合(ステップS41;No)、提示部22は、アプリ識別情報211の取得要求を受信するまで、判定処理を繰り返す。

0055

一方、通信端末1からアプリ識別情報211の取得要求を受信したと判定した場合(ステップS41;Yes)、提示部22は、アプリ識別情報211を通信端末1に送信する(ステップS42)。すなわち、認証要求で指定されたアプリケーションサーバ2のURLに対応するアプリケーションサーバ2の提示部22が、自身の記憶部21に記憶されたアプリ識別情報211を通信端末1に送信する、これにより、提示部22は、通信端末1にアプリ識別情報211を提示できるので、通信端末1のユーザにアプリケーション10の正当性を判断させることができる。そして、アプリケーションサーバ2側の処理が終了する。

0056

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

0057

ユーザUが通信端末1のアプリケーションAを起動すると(ステップS91)、起動後のアプリケーションAが、認証要求をユーザUのデータサーバ3に送信する(ステップS92)。認証要求には、アプリケーションサーバ2のURLおよびアプリケーションサーバ2上のトークン取り出しページのURL(リダイレクトURL)が指定される。

0058

ユーザUのデータサーバ3側では、認証要求を受信した認証部32が、認証要求を問い合わせる画面を通信端末1に送信する(ステップS93)。この結果、通信端末1側では、ブラウザ11が、認証要求を問い合わせる画面を表示する。そして、ブラウザ11は、認証要求で指定されたアプリケーションサーバ2のURLに対して、アプリ識別情報211の取得要求を送信する(ステップS94)。ここでは、アプリケーションサーバ2のURLは、サービスAに対応するアプリケーションサーバ2であるとする。

0059

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

0060

ここで、ユーザUは、表示されたアプリ識別情報211がアプリケーションAに対応する正当な情報であると判断すれば、ブラウザ11にユーザの認証情報を入力してデータサーバ3に対してログインする。ここでは、ユーザUは、表示されたアプリ識別情報211がアプリケーションAに対応する正当な情報であると判断し、ユーザの認証情報としてユーザ名とパスワードを入力したとする。すると、ブラウザ11は、入力されたユーザ名、パスワードを、ユーザUのデータサーバ3に送信する(ステップS97)。

0061

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

0062

通信端末1のブラウザ11は、応答に含まれるアプリケーションサーバ2上のトークン取り出しページのURLから、トークン取り出しページ212をダウンロードする(ステップS99)。そして、ブラウザ11は、ダウンロードしたトークン取り出しページを実行し、トークンが取り出せるかどうかを確認する。そして、ブラウザ11は、トークンが取り出せる場合、取り出したトークンを認証要求に対する応答としてアプリケーションAに戻す(ステップS100)。

0063

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

0064

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

0065

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

0066

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

0067

ユーザUが通信端末1のアプリケーションAを起動し(ステップS91)、起動後のアプリケーションAが、認証要求をユーザUのデータサーバ3に送信する(ステップS92)。認証要求には、アプリケーションサーバ2のURLおよびアプリケーションサーバ2上のトークン取り出しページのURL(リダイレクトURL)が指定される。

0068

ユーザUのデータサーバ3側では、認証要求を受信した認証部32が、認証要求で指定されたアプリケーションサーバ2のURLに対して、アプリ識別情報211の取得要求を送信する(ステップS93A)。ここでは、アプリケーションサーバ2のURLは、サービスAに対応するアプリケーションサーバ2であるとする。

0069

サービスAに対応するアプリケーションサーバ2側では、アプリ識別情報211の取得要求を受信した提示部22が、自身の記憶部21に記憶されたアプリ識別情報211を取得要求元のユーザUのデータサーバ3に送信する(ステップS93B)。ユーザUのデータサーバ3側では、アプリ識別情報211を取得した認証部32が、アプリ識別情報211と認証要求を問い合わせる画面とを通信端末1に送信する(ステップS93C)。

0070

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

0071

ここで、ユーザUは、表示されたアプリ識別情報211がアプリケーションAに対応する正当な情報であると判断し、ユーザの認証情報としてユーザ名とパスワードを入力したとする。すると、ブラウザ11は、入力されたユーザ名、パスワードを、ユーザUのデータサーバ3に送信する(ステップS97)。

0072

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

0073

通信端末1のブラウザ11は、応答に含まれるアプリケーションサーバ2上のトークン取り出しページのURLから、トークン取り出しページ212をダウンロードする(ステップS99)。そして、ブラウザ11は、ダウンロードしたトークン取り出しページを実行し、トークンが取り出せるかどうかを確認する。そして、ブラウザ11は、トークンが取り出せる場合、取り出したトークンを認証要求に対する応答としてアプリケーションAに戻す(ステップS100)。

0074

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

0075

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

0076

図8Aに示すように、アプリBは、認証要求をユーザUのデータサーバ3に送信する。認証要求には、アプリBによって実施されるサービスBに対応するアプリサーバ(以降、アプリサーバBという)のURLおよびアプリサーバB上のトークン取り出しページのURL(リダイレクトURL)が指定されている。

0077

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

0078

図8Bに示すように、アプリBは、認証要求をユーザUのデータサーバ3に送信する。認証要求には、アプリAによって実施されるサービスAに対応するアプリサーバ(以降、アプリサーバAという)のURLおよびアプリサーバB上のトークン取り出しページのURL(リダイレクトURL)が指定されている。

0079

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

0080

図8Cに示すように、アプリBは、認証要求をユーザUのデータサーバ3に送信する。認証要求には、アプリAによって実施されるサービスAに対応するアプリサーバAのURLおよびアプリサーバA上のトークン取り出しページのURL(リダイレクトURL)が指定されている。

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

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

0089

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

0090

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

0091

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

0092

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

0093

[サーバのハードウェア構成]
図9は、サーバのハードウェア構成の一例を示す図である。ここでいうサーバとは、アプリケーションサーバ2およびデータサーバ3を意味する。図9に示すように、サーバ1000は、RAM1010と、ネットワークインタフェース装置1020と、HDD1030と、CPU1040、媒体読取装置1050およびバス1060とを有する。RAM1010、ネットワークインタフェース装置1020、HDD1030、CPU1040、媒体読取装置1050は、バス1060によって接続されている。

0094

そして、データサーバ3の場合、HDD1030には、図1に示した認証部32、制御部33の機能を実現するアプリケーション認証プログラムなどのプログラムが記憶される。また、HDD1030には、図1に示した記憶部31に記憶されるサービスA、サービスBなど各種サービスに対応するデータが記憶される。そして、CPU1040がアプリケーション認証プログラムをHDD1030から読み出してRAM1010にロードすることにより、アプリケーション認証プログラムは、アプリケーション認証プロセスとして機能するようになる。そして、アプリケーション認証プロセスは、HDD1030から読み出した情報などを適宜RAM1010上の自身に割り当てられた領域にロードし、このロードしたデータなどに基づいて各種データ処理を実行する。

0095

また、アプリケーションサーバ2の場合、HDD1030には、図1に示した提示部22の機能を実現するアプリケーション認証プログラムなどのプログラムが記憶される。また、HDD1030には、図1に示した記憶部21に記憶されるアプリケーション210、アプリ識別情報211など各種データが記憶される。そして、CPU1040がアプリケーション認証プログラムをHDD1030から読み出してRAM1010にロードすることにより、アプリケーション認証プログラムは、アプリケーション認証プロセスとして機能するようになる。そして、アプリケーション認証プロセスは、HDD1030から読み出した情報などを適宜RAM1010上の自身に割り当てられた領域にロードし、このロードしたデータなどに基づいて各種データ処理を実行する。

0096

媒体読取装置1050は、アプリケーション認証プログラムなどのプログラムがHDD1030に記憶されていない場合であっても、プログラムを記憶する媒体などからアプリケーション認証プログラムなどのプログラムを読み取る。媒体読取装置1050には、例えばCD−ROM光ディスク装置がある。

0097

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

0098

[通信端末のハードウェア構成]
図10は、通信端末のハードウェア構成の一例を示す図である。図10に示すように、通信端末900は、無線通信部910と、表示部920と、音声入出力部930と、入力部940と、プロセッサ950と、記憶部960とを有する。無線通信部910、表示部920、音声入出力部930、入力部940および記憶部960は、それぞれプロセッサ950と接続されている。

0099

記憶部960は、プログラム記憶部961と、データ記憶部962と、RAM(Random Access Memory)963とを有する。プログラム記憶部961には、図1に示したアプリケーション10、ブラウザ11を含むアプリケーション認証プログラムが記憶される。データ記憶部962には、例えば、データサーバ3およびアプリケーションサーバ2から送信される認証要求を問い合わせる画面やアプリ識別情報211など各種データが記憶される。なお、記憶部960は、例えば、RAM、フラッシュメモリ(flash memory)などの半導体メモリ素子、または、ハードディスク(HDD:Hard Disk Drive)、光ディスクなどの記憶装置である。

0100

プロセッサ950は、例えば、ASIC(Application Specific IntegratedCircuit)やFPGA(Field Programmable Gate Array)などの集積回路またはCPU(Central Processing Unit)やMPU(Micro Processing Unit)などの電子回路である。そして、プロセッサ950がアプリケーション認証プログラムを記憶部960から読み出してRAM963にロードすることにより、アプリケーション認証プログラムなどのプログラムは、アプリケーション認証プロセスなどのプロセスとして機能するようになる。そして、アプリケーション認証プロセスは、データ記憶部962から読み出した情報などを適宜RAM963上の自身に割り当てられた領域にロードし、このロードしたデータなどに基づいて各種データ処理を実行する。

実施例

0101

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

0102

1通信端末
2アプリケーションサーバ
3データサーバ
4ネットワーク
9データ参照システム
10、210アプリケーション
11ブラウザ
21,31 記憶部
22提示部
211アプリ識別情報
32 認証部
33 制御部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ