JP6119709B2 - サービスプロバイダ装置、プログラム及びサービス提供方法 - Google Patents

サービスプロバイダ装置、プログラム及びサービス提供方法 Download PDF

Info

Publication number
JP6119709B2
JP6119709B2 JP2014199413A JP2014199413A JP6119709B2 JP 6119709 B2 JP6119709 B2 JP 6119709B2 JP 2014199413 A JP2014199413 A JP 2014199413A JP 2014199413 A JP2014199413 A JP 2014199413A JP 6119709 B2 JP6119709 B2 JP 6119709B2
Authority
JP
Japan
Prior art keywords
information
service
domain
unit
web service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014199413A
Other languages
English (en)
Other versions
JP2016071561A (ja
Inventor
浩和 番野
浩和 番野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Brother Industries Ltd
Original Assignee
Brother Industries Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Brother Industries Ltd filed Critical Brother Industries Ltd
Priority to JP2014199413A priority Critical patent/JP6119709B2/ja
Priority to US14/867,383 priority patent/US9686264B2/en
Publication of JP2016071561A publication Critical patent/JP2016071561A/ja
Application granted granted Critical
Publication of JP6119709B2 publication Critical patent/JP6119709B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Description

本発明は、サービスプロバイダ装置とプログラムとサービス提供方法に関する。
Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍによって、インターネットを利用するための技術が標準化されている。例えば、非特許文献１には、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ Ｌｅｖｅｌ ２が開示されている。この技術を用いると、例えば、次のような通信が可能となる。ユーザが操作する端末装置では、Ｗｅｂブラウザを介してＪａｖａＳｃｒｉｐｔ（登録商標）によるアプリケーションによって、特定のサービスクライアントによる特定のＷｅｂサービスが利用されているとする。この状態において、前述の端末装置は、Ｗｅｂブラウザを介して、ドメインが異なる外部のサービスプロバイダ装置によって提供されるＷｅｂサービスにおける情報にアクセスすることができる。その結果、特定のＷｅｂサービスに対応する表示がなされているＷｅｂブラウザ上に、サービスプロバイダ装置によって提供されるＷｅｂサービスの情報を表示することができる。
World Wide Web Consortium、"XMLHttpRequest Level 2 W3C Working Draft 17 January 2012"、［online］、［平成２６年９月１０日検索］、インターネット<URL：http://www.w3.org/TR/XMLHttpRequest2/>
多くの拠点から利用されるＷｅｂサービスの場合、サービスクライアントが、複数の異なる場所に配置されることがある。例えば、各サービスクライアントには異なるサブドメインが割り振られ、アクセス元の通信環境から近いサービスクライアントが利用される。このような、特定のサービスクライアントによるＷｅｂサービスから、基底サイトドメインが異なる外部のサービスプロバイダ装置によって提供される認証が必要なＷｅｂサービスに、例えば、Ｗｅｂブラウザに搭載されたＪａｖａＳｃｒｉｐｔ（登録商標）によるアプリケーションプログラムを介して通信するとする。通信には、例えば、標準化されたＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルが用いられる。ＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルでは、認証を必要とするリソースに対しては、その仕様上、任意のドメイン（サービスクライアント）からのアクセスを許可することはできない。ＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルでは、認証を必要とするリソースに対しては、アクセスを許可する特定のドメインを指定する必要がある。但し、上述した通り、アクセス元となるドメインが不定である場合、アクセス元が、許可すべきドメインかを判断することができない。その結果、通信が確立できない可能性がある。一方、接続元ドメイン名を、そのままアクセスを許可する特定のドメインとして指定する方法が考えられる。しかし、接続元に関わらず、全てのドメインとの通信を確立させると、セキュリティレベルが下がることが懸念される。
本発明は、セキュリティを確保しつつ、特定のＷｅｂサービスとのスムーズな連携を可能とする、サービスプロバイダ装置、プログラム及びサービス提供方法を提供することを目的とする。
本発明の一側面は、インターネットを介した第一Ｗｅｂサービスを提供するサービスプロバイダ装置であって、所定のＷｅｂサービスを提供する所定のサービスクライアントに対応する第一識別情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続を認可する認可情報を転送するアドレスに対応する転送先情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された認証情報と、を関連付けて記憶する関連付け部と、第二Ｗｅｂサービスを提供する第一サービスクライアントに、Ｗｅｂブラウザを介してアクセスしている端末装置から送信され、前記第一サービスクライアントのドメイン情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、第三Ｗｅｂサービスを提供する第二サービスクライアントに対応して発行された認証情報と、を含み、前記第一Ｗｅｂサービスに対応するリソースへの接続を要求するリソース要求を、前記サービスプロバイダ装置を前記インターネットに接続する前記サービスプロバイダ装置の通信部を介して取得する取得手段と、前記取得手段によって取得された前記リソース要求に含まれる前記認証情報に一致する、前記関連付け部に記憶された前記認証情報に関連付けられた前記転送先情報を、前記関連付け部から特定する特定手段と、前記取得手段によって取得された前記リソース要求に含まれる前記ドメイン情報と、前記特定手段によって特定された前記転送先情報と、が少なくとも一部のドメインの階層で一致するかを判断する判断手段と、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致する場合、認証が必要であることを示す情報と前記ドメイン情報とを含む、前記リソース要求に対する第一応答を、前記通信部から前記端末装置に送信し、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記ドメイン情報を含まない、前記リソース要求に対する第二応答を、前記通信部から前記端末装置に送信する、送信手段と、を備えるサービスプロバイダ装置である。
これによれば、第一Ｗｅｂサービスに対応するリソースへの接続に利用される認証情報が、第二サービスクライアントに対応して発行されている状態において、第一サービスクライアントにＷｅｂブラウザを介してアクセスしている端末装置に、この認証情報によって、同じリソースへの接続を認可することができる。端末装置が、第一サービスクライアントに、Ｗｅｂブラウザを介してアクセスしている状態において、第一Ｗｅｂサービスに対応するリソースに接続する場合、再度、第一サービスクライアントに対応する認証情報を発行する必要がない。第一Ｗｅｂサービスと第二Ｗｅｂサービスの連携と、第一Ｗｅｂサービスと第三Ｗｅｂサービスの連携を、スムーズに実現させることができる。
サービスプロバイダ装置において、前記関連付け部は、前記第一識別情報と、前記転送先情報と、を関連付けて記憶する第一関連付け部と、前記第一識別情報に対応する第二識別情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された前記認証情報と、を関連付けて記憶する第二関連付け部と、を含み、前記特定手段は、前記取得手段によって取得された前記リソース要求に含まれる前記認証情報に一致する、前記第二関連付け部に記憶された前記認証情報に関連付けられた前記第二識別情報を、前記第二関連付け部から特定し、特定された前記第二識別情報に対応する前記第一識別情報に関連付けられた前記転送先情報を、前記第一関連付け部から特定する、ようにしてもよい。これによれば、各情報を第一関連付け部と第二関連付け部に適宜記憶し、転送先情報を特定することができる。第二関連付け部に、第一識別情報に対応する第二識別情報を記憶させることで、第一関連付け部と第二関連付け部にそれぞれ記憶された各情報を関連付けることができる。
サービスプロバイダ装置において、前記判断手段は、最下位のドメインの階層より上位の階層で、前記ドメイン情報と、前記転送先情報と、が一致するかを判断し、前記送信手段は、前記最下位のドメインの階層より上位の階層で、前記ドメイン情報と前記転送先情報とが一致する場合、前記第一応答を、前記通信部から前記端末装置に送信し、前記最下位のドメインの階層より上位の階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記第二応答を、前記通信部から前記端末装置に送信する、ようにしてもよい。これによれば、第一サービスクライアントが、第二サービスクライアントと基底ドメインが共通するかを判断することができる。端末装置が、第二サービスクライアントと共通した基底ドメインのサブドメインである第一サービスクライアントに、Ｗｅｂブラウザを介してアクセスしている状態において、第二サービスクライアントに対応して発行された認証情報によって、第一Ｗｅｂサービスに対応するリソースへの接続を認可することができる。
サービスプロバイダ装置において、前記関連付け部は、更に、前記転送先情報のドメインの階層を示す階層情報を関連付けて記憶し、前記判断手段は、前記階層情報に対応するドメインの階層で、前記ドメイン情報と、前記転送先情報と、が一致するかを判断し、前記送信手段は、前記階層情報に対応するドメインの階層で、前記ドメイン情報と前記転送先情報とが一致する場合、前記第一応答を、前記通信部から前記端末装置に送信し、前記階層情報に対応するドメインの階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記第二応答を、前記通信部から前記端末装置に送信する、ようにしてもよい。これによれば、第二サービスクライアントと同一であると判断される第一サービスクライアントの範囲を適宜設定することができる。
サービスプロバイダ装置は、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された前記認証情報として、ＯＡｕｔｈプロトコルにおけるアクセストークンを生成する生成手段を備え、前記関連付け部は、更に、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された前記認証情報として、前記生成手段によって生成された前記アクセストークンを関連付けて記憶し、前記取得手段は、前記ドメイン情報と、前記第二サービスクライアントに対応して発行された前記認証情報としての前記アクセストークンと、を含むリソース要求を、前記通信部を介して取得し、前記特定手段は、前記取得手段によって取得された前記リソース要求に含まれる前記アクセストークンに一致する、前記関連付け部に記憶された前記アクセストークンに関連付けられた前記転送先情報を、前記関連付け部から特定する、ようにしてもよい。これによれば、ＯＡｕｔｈプロトコルにおけるアクセストークンを認証情報として、第一サービスクライアントにＷｅｂブラウザを介してアクセスしている端末装置に、認可済みのリソースへの接続を認可することができる。
サービスプロバイダ装置において、前記取得手段は、前記リソース要求として、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルにおけるＨＴＴＰリクエストを取得し、前記特定手段は、前記取得手段によって取得された前記ＨＴＴＰリクエストに含まれる前記アクセストークンに一致する、前記関連付け部に記憶された前記アクセストークンに関連付けられた前記転送先情報を、前記関連付け部から特定し、前記送信手段は、前記取得手段によって取得された前記ＨＴＴＰリクエストに対して、前記第一応答と、前記第二応答と、を前記通信部から前記端末装置に送信する、ようにしてもよい。これによれば、ＯＡｕｔｈプロトコルとＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルによって、第一サービスクライアントにＷｅｂブラウザを介してアクセスしている端末装置に、認可済みのリソースへの接続を認可することができる。
本発明の他の側面は、インターネットを介した第一Ｗｅｂサービスを提供するサービスプロバイダ装置を制御するコンピュータが実行可能なプログラムであって、前記コンピュータを、第二Ｗｅｂサービスを提供する第一サービスクライアントに、Ｗｅｂブラウザを介してアクセスしている端末装置から送信され、前記第一サービスクライアントのドメイン情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、第三Ｗｅｂサービスを提供する第二サービスクライアントに対応して発行された認証情報と、を含み、前記第一Ｗｅｂサービスに対応するリソースへの接続を要求するリソース要求を、前記サービスプロバイダ装置を前記インターネットに接続する前記サービスプロバイダ装置の通信部を介して取得する取得手段と、所定のＷｅｂサービスを提供する所定のサービスクライアントに対応する第一識別情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続を認可する認可情報を転送するアドレスに対応する転送先情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された認証情報と、を関連付けて記憶する関連付け部から、前記取得手段によって取得された前記リソース要求に含まれる前記認証情報に一致する、前記関連付け部に記憶された前記認証情報に関連付けられた前記転送先情報を特定する特定手段と、前記取得手段によって取得された前記リソース要求に含まれる前記ドメイン情報と、前記特定手段によって特定された前記転送先情報と、が少なくとも一部のドメインの階層で一致するかを判断する判断手段と、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致する場合、認証が必要であることを示す情報と前記ドメイン情報とを含む、前記リソース要求に対する第一応答を、前記通信部から前記端末装置に送信し、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記ドメイン情報を含まない、前記リソース要求に対する第二応答を、前記通信部から前記端末装置に送信する、送信手段と、して機能させるプログラムである。
これによれば、インターネットを介した通信機能を備える情報処理装置を、上記の対応するサービスプロバイダ装置とすることができる。上記の対応するサービスプロバイダ装置と同様の作用が実現される。このプログラムは、上記の各サービスプロバイダ装置と同様、コンピュータによる所定の手段に他の機能を含ませ、又はコンピュータを他の手段として機能させるプログラムとして特定することもできる。この場合、プログラムは、上記の各サービスプロバイダ装置のうち、対応するサービスプロバイダ装置と同様の作用を奏する。
本発明の更に他の側面は、インターネットを介した第一Ｗｅｂサービスを提供するサービスプロバイダ装置で実行されるサービス提供方法であって、第二Ｗｅｂサービスを提供する第一サービスクライアントに、Ｗｅｂブラウザを介してアクセスしている端末装置から送信され、前記第一サービスクライアントのドメイン情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、第三Ｗｅｂサービスを提供する第二サービスクライアントに対応して発行された認証情報と、を含み、前記第一Ｗｅｂサービスに対応するリソースへの接続を要求するリソース要求を、前記サービスプロバイダ装置を前記インターネットに接続する前記サービスプロバイダ装置の通信部を介して取得する取得工程と、所定のＷｅｂサービスを提供する所定のサービスクライアントに対応する第一識別情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続を認可する認可情報を転送するアドレスに対応する転送先情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された認証情報と、を関連付けて記憶する関連付け部から、前記取得工程で取得された前記リソース要求に含まれる前記認証情報に一致する、前記関連付け部に記憶された前記認証情報に関連付けられた前記転送先情報を特定する特定工程と、前記取得工程で取得された前記リソース要求に含まれる前記ドメイン情報と、前記特定工程で特定された前記転送先情報と、が少なくとも一部のドメインの階層で一致するかを判断する判断工程と、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致する場合、認証が必要であることを示す情報と前記ドメイン情報とを含む、前記リソース要求に対する第一応答を、前記通信部から前記端末装置に送信し、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記ドメイン情報を含まない、前記リソース要求に対する第二応答を、前記通信部から前記端末装置に送信する、送信工程と、を含むサービス提供方法である。
これによれば、上記の対応するサービスプロバイダ装置と同様の作用が実現される。このサービス提供方法は、上記の各サービスプロバイダ装置と同様、所定の工程に他の手順を含ませ、又は他の工程を含むサービス提供方法として特定することもできる。この場合、サービス提供方法は、上記の各サービスプロバイダ装置のうち、対応するサービスプロバイダ装置と同様の作用を奏する。
本発明によれば、セキュリティを確保しつつ、特定のＷｅｂサービスとのスムーズな連携を可能とする、サービスプロバイダ装置、プログラム及びサービス提供方法を得ることができる。
Ｗｅｂサービスシステムの概略構成を示す図である。 受付処理のフローチャートである。 第一データベースの一例を示す図である。 ＯＡｕｔｈ認証の処理手順の一例を示すシーケンス図である。 第二データベースの一例を示す図である。 取得判断処理のフローチャートである。 ユーザ端末とサービスプロバイダ装置の間の通信の一例を示す図である。 ＨＴＴＰレスポンスの他の例を示す図である。 ＨＴＴＰレスポンスの更に他の例を示す図である。
本発明を実施するための実施形態について、図面を用いて説明する。本発明は、以下に記載の構成に限定されるものではなく、同一の技術的思想において種々の構成を採用することができる。例えば、以下に示す構成の一部は、省略し又は他の構成等に置換してもよい。他の構成を含むようにしてもよい。
＜Ｗｅｂサービスシステム＞
Ｗｅｂサービスシステム１０は、サービスプロバイダ装置２０と、第一サービスクライアント４０と、第二サービスクライアント６０を含む。Ｗｅｂサービスシステム１０において、サービスプロバイダ装置２０と、第一サービスクライアント４０と、第二サービスクライアント６０は、インターネット１２に接続されている。インターネット１２には、複数の端末装置が接続されている。端末装置は、各端末装置のユーザによって操作される。各端末装置のユーザは、端末装置を介して、インターネット１２を利用することができる。図１では、実施形態の説明に用いる１台の端末装置が図示されている。実施形態では、この１台の端末装置を「ユーザ端末８０」という。
サービスプロバイダ装置２０は、第一Ｗｅｂサービスを提供するサーバ装置である。サービスプロバイダ装置２０に関するこの他の説明は後述する。第一サービスクライアント４０は、第二Ｗｅｂサービスを提供するコンシューマである。第二サービスクライアント６０は、第三Ｗｅｂサービスを提供するコンシューマである。第一サービスクライアント４０と第二サービスクライアント６０は、ハードウェア的には、既に実用化された汎用のサーバ装置と同様である。第一サービスクライアント４０による第二Ｗｅｂサービスの提供と、第二サービスクライアント６０による第三Ｗｅｂサービスの提供は、従来と同様の手法によって行われる。そのため、第一サービスクライアント４０と第二サービスクライアント６０の説明は適宜省略する。
実施形態では、第一Ｗｅｂサービスを提供するサービスプロバイダ装置２０のドメイン情報は「ｂａｒ．ｏｔｈｅｒ．ｃｏｍ」とし、ＵＲＩは「ｈｔｔｐｓ：／／ｂａｒ．ｏｔｈｅｒ．ｃｏｍ」とする。第二Ｗｅｂサービスを提供する第一サービスクライアント４０のドメイン情報は「ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」とし、ＵＲＩは「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」とする。第三Ｗｅｂサービスを提供する第二サービスクライアント６０のドメイン情報は「ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」とし、ＵＲＩは「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」とする。第一サービスクライアント４０と第二サービスクライアント６０に関し、「ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」と「ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」は、基底ドメイン「ｅｘａｍｐｌｅ．ｃｏｍ」のサブドメインである。第一サービスクライアント４０と第二サービスクライアント６０は、ポータルサイトを介して利用することができるものであってもよい。ポータルサイトのＵＲＩは、例えば、「ｈｔｔｐｓ：／／ｐｏｒｔａｌ．ｅｘａｍｐｌｅ．ｃｏｍ」とされる。
Ｗｅｂサービスシステム１０では、例えば、次のような処理を実現することができる。ユーザ端末８０を操作するユーザが、第一Ｗｅｂサービスと第二Ｗｅｂサービスと第三Ｗｅｂサービスに登録し、これら各サービスを利用することができるとする。第一Ｗｅｂサービスは、データ保管サービスであるとする。第二Ｗｅｂサービスは、ソーシャルネットワーキングサービスであるとする。第三Ｗｅｂサービスは、電子メールサービスであるとする。例えば、このユーザは、第一Ｗｅｂサービスと第二Ｗｅｂサービスを連携させて、第一Ｗｅｂサービスに保管された写真データを、第二Ｗｅｂサービスに投稿することができる。このユーザは、第一Ｗｅｂサービスと第三Ｗｅｂサービスを連携させて、第一Ｗｅｂサービスに保管された写真データを電子メールに添付し、この写真データが添付された電子メールを送信することができる。各サービス間の連携には、Ｗｅｂサービス用のＡＰＩ（Application Programming Interface ）が利用される。
ユーザ端末８０は、通信機能を有する公知の情報処理装置である。ユーザ端末８０には、Ｗｅｂブラウザがインストールされている。インターネット１２へのアクセスは、Ｗｅｂブラウザを介して行われる。Ｗｅｂブラウザ上では、アクセス先のＷｅｂサービス用のＪａｖａＳｃｒｉｐｔ（登録商標）によるアプリケーションが動作する。このアプリケーションは、アクセス先からユーザ端末８０に送信される。ユーザ端末８０としては、例えば、パーソナルコンピュータ、タブレット端末又はスマートフォンが挙げられる。ユーザ端末８０に関する説明は適宜省略する。
＜サービスプロバイダ装置＞
サービスプロバイダ装置２０について、図１を参照して説明する。サービスプロバイダ装置２０は、ＣＰＵ２１と、記憶装置２２と、ＲＡＭ２３と、通信部２４を備える。これら各部２１〜２４は、バス２５に接続される。ＣＰＵ２１は、演算処理を実行する。記憶装置２２は、コンピュータが読み取り可能な記憶媒体によって構成される。例えば、記憶装置２２は、ハードディスク及び／又はフラッシュメモリによって構成される。この他、記憶装置２２は、ＲＯＭを含むものであってもよい。記憶装置２２には、各種のプログラムが記憶される。例えば、記憶装置２２には、ＯＳ（Operating System）と各種のアプリケーションが記憶される。記憶装置２２に記憶されるアプリケーションには、後述する受付処理（図２参照）のプログラムと、取得判断処理（図６参照）のプログラムが含まれる。例えば、アプリケーションは、記憶装置２２に事前にインストールされる。
事前のインストールは、例えば、半導体メモリ等のコンピュータが読み取り可能な記憶媒体に記憶されたプログラムが、サービスプロバイダ装置２０の読取部（不図示）によって読み取られることで行われる。サービスプロバイダ装置２０が、例えば、光学ドライブ（不図示）を備えている場合、事前のインストールは、光学メディアに記憶されたプログラムが、光学ドライブによって読み取られることで行われるようにしてもよい。この他、事前のインストールは、インターネット１２に接続されるサービスプロバイダ装置２０とは別のサーバ装置のハードディスク等のコンピュータが読み取り可能な記憶媒体に記憶されたプログラムが、通信部２４で伝送信号として受信されることで行われるようにしてもよい。何れの形態とするかは、諸事情を考慮して適宜決定される。コンピュータが読み取り可能な記憶媒体は、一時的な記憶媒体（例えば、伝送信号）を含まない、非一時的な記憶媒体であってもよい。非一時的な記憶媒体は、情報を記憶する期間に関わらず、情報を記憶可能な記憶媒体であればよい。
ＲＡＭ２３は、ＣＰＵ２１が各種のプログラムを実行する際に利用される記憶領域となる。ＲＡＭ２３には、処理の実行途中に、処理で利用される所定のデータと情報が、所定の記憶領域に記憶される。例えば、ＲＡＭ２３には、第一データベース（図３参照）と第二データベース（図５参照）が記憶される。但し、第一データベースと第二データベースは、記憶装置２２に記憶されるようにしてもよい。サービスプロバイダ装置２０では、ＣＰＵ２１が、記憶装置２２に記憶された、ＯＳと、図２に示す受付処理及び図６に示す取得判断処理の各プログラムを実行する等して、サービスプロバイダ装置２０を制御する。これにより、サービスプロバイダ装置２０では、各種の機能手段が実現される。
通信部２４は、サービスプロバイダ装置２０をインターネット１２に接続し、インターネット１２を介したデータ通信を行う。例えば、サービスプロバイダ装置２０では、通信部２４を介してユーザ端末８０との間で各種の指令とデータが送受信される。通信部２４は、例えば、イーサネット（登録商標）規格に適合するインターフェース回路等である。通信部２４によるインターネット１２への接続は、有線接続とされる。但し、通信部２４によるインターネット１２への接続は、無線接続であってもよい。
サービスプロバイダ装置２０は、図６に示す取得判断処理のプログラムが記憶装置２２に記憶され、取得判断処理において、図３に示す第一データベースと図５に示す第二データベースが利用される点が、公知のサーバ装置と相違する。但し、サービスプロバイダ装置２０は、ハードウェア的には、公知のサーバ装置と同様のサーバ装置である。従って、上記では説明を省略したが、サービスプロバイダ装置２０は、上述した各部２１〜２５の他、公知のサーバ装置が備える構成を備える。
＜受付処理＞
サービスプロバイダ装置２０で実行される受付処理について、図２を参照して説明する。受付処理は、第一サービスクライアント４０と第二サービスクライアント６０を含むサービスクライアントによって提供されるサービスを、第一Ｗｅｂサービスと連携させる場合に、事前に行われる。受付処理は、例えば、サービスクライアントからの登録要求がサービスプロバイダ装置２０において受け付けられた場合に開始される。登録要求は、例えば、インターネット１２を介して、要求元のサービスクライアントから送信され、通信部２４で受信される。ＣＰＵ２１は、通信部２４を介して登録要求を取得し、受付処理を開始する。
受付処理を開始させたＣＰＵ２１は、クライアントＩＤと、シークレットＩＤを生成する（Ｓ２１）。クライアントＩＤは、サービスクライアントを識別する識別情報であり、サービスクライアント毎の特有のＩＤである。シークレットＩＤは、電子署名に用いられるＩＤである。シークレットＩＤは、コンシューマシークレットと称されることもある。シークレットＩＤは、公知のＯＡｕｔｈ認証でも、利用される情報である。そのため、シークレットＩＤに関するこの他の説明は省略する。
次に、ＣＰＵ２１は、第一データベースへの所定の情報の登録を制御する（Ｓ２３）。第一データベースは、上述した通り、ＲＡＭ２３又は記憶装置２２に記憶されている。第一データベースに登録される所定の情報としては、例えば、レコードＩＤとサービス名とクライアントＩＤとシークレットＩＤとリダイレクトＵＲＩと階層情報が挙げられる。受付処理によって、Ｓ２３で登録された各情報は、それぞれが関連付けられた状態で、第一データベースに記憶される（図３参照）。
レコードＩＤは、第一データベースに記憶されたレコードを識別する通し番号である。サービス名は、登録対象のサービスクライアントが提供するサービスの名称である。例えば、登録対象が第二サービスクライアント６０である場合、サービス名として、第二Ｗｅｂサービスの名称「ｑｕｘ」が登録される。クライアントＩＤとシークレットＩＤは、Ｓ１１で生成された情報である。リダイレクトＵＲＩは、認可コードを転送するアドレスに対応する転送先情報である。認可コードの転送については後述する。階層情報は、図６に示す取得判断処理のＳ３９で、ドメイン情報の同一性の判断条件となるリダイレクトＵＲＩのドメインの階層を示す情報である。例えば、リダイレクトＵＲＩが「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」である場合において、セカンドレベルドメインまでの一致が判断条件に設定される。この場合、階層情報は、「ｅｘａｍｐｌｅ．ｃｏｍ」となる。
Ｓ２３において、レコードＩＤは、自動的に生成される。サービス名とリダイレクトＵＲＩと階層情報は、登録対象のサービスを提供するサービスクライアント側からの申請に従って行われる。即ち、上述した登録要求は、サービス名とリダイレクトＵＲＩと階層情報を含む。ＣＰＵ２１は、取得された登録要求から、これら各情報を取得する。
続けて、ＣＰＵ２１は、Ｓ２３で第一データベースに登録された登録結果の送信を制御する（Ｓ２５）。ＣＰＵ２１は、登録結果の送信指令を通信部２４に出力する。これに伴い、登録結果が、通信部２４から、登録要求の送信元であるサービスクライアントに送信される。Ｓ２５で送信される登録結果は、直前のＳ２３で第一データベースに登録された全ての情報を含む。例えば、登録要求が、第二サービスクライアント６０から送信されていたとする。この場合、登録結果が、通信部２４から第二サービスクライアント６０に送信される。送信される登録結果は、レコードＩＤ「１」のレコードに含まれる全ての情報を含む。但し、登録結果に含ませる情報は、上述した各情報の一部とするようにしてもよい。この場合においても、クライアントＩＤは、登録結果に含まれる。なお、今回の受付処理によって、レコードＩＤ「１」が登録される場合、この登録は、第一データベースに何れの情報も記憶されていない状態で行われる。Ｓ２５を実行した後、ＣＰＵ２１は、受付処理を終了する。
＜ＯＡｕｔｈ認証＞
第一Ｗｅｂサービスと第二Ｗｅｂサービス、又は第一Ｗｅｂサービスと第三Ｗｅｂサービスを連携させる場合、公知のＷｅｂサービスシステムと同様、ＯＡｕｔｈプロトコルによるＯＡｕｔｈ認証が行われる。ＯＡｕｔｈ認証の概略について、図４を参照して説明する。この説明は、第一Ｗｅｂサービスを提供するサービスプロバイダ装置２０と、第三Ｗｅｂサービスを提供する第二サービスクライアント６０を例として行う。図３に示す第一データベースにおけるレコードＩＤ「１」は、第三Ｗｅｂサービスを提供する第二サービスクライアント６０に対応するレコードである。
ユーザ端末８０において、ユーザは、Ｗｅｂブラウザを起動させ、Ｗｅｂブラウザに、ユーザ端末８０の操作部を介して所定の操作を入力する。例えば、ユーザは、Ｗｅｂブラウザに、第二サービスクライアント６０（第三Ｗｅｂサービス）へのアクセス操作を入力する。これに伴い、Ｗｅｂブラウザは、第二サービスクライアント６０のＵＲＩ「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」に従い、第二サービスクライアント６０にアクセスする。ユーザ端末８０では、第三Ｗｅｂサービスのサービス画面がＷｅｂブラウザに表示される。Ｗｅｂブラウザでは、第三Ｗｅｂサービス用のＪａｖａＳｃｒｉｐｔ（登録商標）によるアプリケーションが実行される。第三Ｗｅｂサービス用のＪａｖａＳｃｒｉｐｔ（登録商標）は、例えば、Ｗｅｂブラウザが、第二サービスクライアント６０にアクセスしたときにダウンロードされるようにしてもよい。
次に、ユーザは、Ｗｅｂブラウザに対して、ＯＡｕｔｈ認証の操作を行う。これに伴い、ＯＡｕｔｈ認証開始要求が、ユーザ端末８０から第二サービスクライアント６０に送信される（Ｔ１）。第二サービスクライアント６０では、ＯＡｕｔｈ認証開始要求に応じて、ＯＡｕｔｈ認証開始応答が、ユーザ端末８０に送信される（Ｔ２）。ＯＡｕｔｈ認証開始応答は、第一Ｗｅｂサービスを提供するサービスプロバイダ装置２０に対応する認証用のＵＲＩを含む。ユーザ端末８０では、第一Ｗｅｂサービス用の認証画面の送信要求が、ＯＡｕｔｈ認証開始応答に含まれるＵＲＩに従い、サービスプロバイダ装置２０に送信される（Ｔ３）。
サービスプロバイダ装置２０では、Ｔ３での送信要求に応じて、第一Ｗｅｂサービス用の認証画面に対応するデータが、ユーザ端末８０に送信される（Ｔ４）。このデータを受信したユーザ端末８０では、第一Ｗｅｂサービス用の認証画面が、Ｗｅｂブラウザに表示される（Ｔ５）。ユーザは、ユーザ端末８０の操作部を介して、ログイン情報を入力する。ユーザ端末８０では、入力されたログイン情報が受け付けられ、受け付けられたログイン情報が、サービスプロバイダ装置２０に送信される（Ｔ６）。サービスプロバイダ装置２０では、認証処理が、ユーザ端末８０からのログイン情報に従い行われる（Ｔ７）。
Ｔ７では、ログイン情報が適切であった場合、ユーザＩＤとアプリケーションＩＤが、関連付けられた状態で、第二データベースに登録される（図５参照）。サービスプロバイダ装置２０において、第二データベースは、上述した通り、ＲＡＭ２３又は記憶装置２２に記憶されている。登録対象となるアプリケーションＩＤは、連携対象のＷｅｂサービスを提供するサービスクライアントに対応する。実施形態では、第一データベースにおいて、次のクライアントＩＤに関連付けられたレコードＩＤが、アプリケーションＩＤとして、第二データベースに登録される。前述のクライアントＩＤは、連携対象のＷｅｂサービスを提供するサービスクライアントに対応するクライアントＩＤである。従って、第二サービスクライアント６０を例とする場合、レコードＩＤ「１」が、アプリケーションＩＤとして登録される（図３及び図５参照）。第一データベースのレコードＩＤと第二データベースのアプリケーションＩＤによって、第一データベースに記憶されたレコードと、第二データベースに記憶されたレコードを関連付けることができる。
ログイン情報が適切であった場合、サービスプロバイダ装置２０では、承認画面に対応するデータが、ユーザ端末８０に送信される（Ｔ８）。承認画面に対応するデータを受信したユーザ端末８０では、承認画面がＷｅｂブラウザに表示される（Ｔ９）。承認画面は、ユーザに、第一ＷｅｂサービスのＡＰＩを利用したユーザのリソースへの接続に対して、認可又は不認可の選択を求める画面である。承認画面は、例えば、ＯＫボタンと、キャンセルボタンを含む。ＯＫボタンは認可に関連付けられ、キャンセルボタンは不認可に関連付けられる。ユーザは、ユーザ端末８０の操作部を介して、ＯＫボタンとキャンセルボタンの何れかに対する操作を入力する。ＯＫボタンに対する操作が受け付けられた場合、ユーザ端末８０では、認可指令が、サービスプロバイダ装置２０に送信される（Ｔ１０）。サービスプロバイダ装置２０では、認可指令に応じて、リダイレクトＵＲＩに認可コードが引数として付与される（Ｔ１１）。
Ｔ１１を、上述した通り、第二サービスクライアント６０を例として説明する。この場合、認可コードが付与されるリダイレクトＵＲＩは、図３に示す第一データベースで、レコードＩＤ「１」に関連付けられたリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」である。サービスプロバイダ装置２０では、認可コードが生成される。認可コードは、第一ＷｅｂサービスのＡＰＩを利用したユーザのリソースへの接続を認める認可情報である。リソースは、サービスプロバイダ装置２０によって管理される第一Ｗｅｂサービスに対応するデータ等である。第一Ｗｅｂサービスが、データ保管サービスである場合、ユーザのリソースは、例えば、このユーザが第一Ｗｅｂサービスを利用して保管する写真データである。
次に、サービスプロバイダ装置２０では、認可コードが付与されたリダイレクトＵＲＩが、ユーザ端末８０に送信される（Ｔ１２）。ユーザ端末８０では、Ｗｅｂブラウザにおけるアクセス先が、認可コードが付与されたリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」へと移動する。このとき、ユーザ端末８０では、リダイレクトＵＲＩに引数として付与された認可コードが、第二サービスクライアント６０に送信される（Ｔ１３）。認可コードを受信した第二サービスクライアント６０では、発行要求が、サービスプロバイダ装置２０に送信される。発行要求は、サービスプロバイダ装置２０に対して、アクセストークンの発行を要求する指令である。アクセストークンは、第一Ｗｅｂサービスにおけるユーザのリソースに接続する際に利用される認証情報である。発行要求は、Ｔ１３で受信された認可コードを含む。この他、発行要求は、例えば、第二サービスクライアント６０で管理される登録結果に含まれる、クライアントＩＤを含む。登録結果は、図２に示す受付処理のＳ２５で、サービスプロバイダ装置２０から送信される。発行要求に、第二サービスクライアント６０で管理される登録結果に含まれる、シークレットＩＤを含ませるようにしてもよい。
サービスプロバイダ装置２０では、Ｔ１４での発行要求に応じて、アクセストークンが発行される（Ｔ１５）。Ｔ１５では、発行されたアクセストークンが、第二データベースに登録される。このとき、アクセストークンは、直前のＴ７で、第二データベースに登録されたユーザＩＤとアプリケーションＩＤに、関連付けられた状態で登録される。実施形態では、Ｔ１５で、第二サービスクライアント６０からの発行要求に応じて、アクセストークン「ｄ２１ｃ９ｄ８８１ｅｂａ６９８８ｂｅ４８０ｅｆａｂ４５ｄｅ２ｂ９」が生成され、第二データベースに登録される。これにより、第二データベースには、ユーザＩＤ「４２３」とアプリケーションＩＤ「１」とアクセストークン「ｄ２１ｃ９ｄ８８１ｅｂａ６９８８ｂｅ４８０ｅｆａｂ４５ｄｅ２ｂ９」が、関連付けられた状態で記憶される（図５参照）。第二データベースにおいても、第一データベースと同様、ユーザＩＤとアプリケーションＩＤとアクセストークンが記憶された各レコードに対して、レコードＩＤが関連付けられる。第二データベースにおけるレコードＩＤは、第二データベースに記憶されたレコードを識別する通し番号である。
その後、サービスプロバイダ装置２０では、発行されたアクセストークンが、要求元である第二サービスクライアント６０に送信される（Ｔ１６）。これにより、ＯＡｕｔｈ認証が終了する。第二サービスクライアント６０に対応して発行されたアクセストークンは、基底ドメインが共通する第一サービスクライアント４０においても利用することができる。
＜取得判断処理＞
サービスプロバイダ装置２０で実行される取得判断処理について、図６を参照して説明する。ユーザ端末８０では、上述したように、ＯＡｕｔｈ認証が実行され、第一Ｗｅｂサービスと第二Ｗｅｂサービスの連携が実現されている。このような状態において、ユーザ端末８０では、Ｗｅｂブラウザを介したアクセス先が、第二サービスクライアント６０から、基底ドメインが共通する、第一サービスクライアント４０に変更されたとする。この場合、第一サービスクライアント４０からユーザ端末８０に、第二Ｗｅｂサービス用のＪａｖａＳｃｒｉｐｔ（登録商標）によるアプリケーションが送信される。更に、第一サービスクライアント４０からユーザ端末８０に、上述したＯＡｕｔｈ認証で、第二サービスクライアント６０に対応して発行されたアクセストークンが送信される。同一の基底ドメインを有するサービスクライアント間では、一のサービスクライアントに対して発行されたアクセストークンは、発行元のサービスプロバイダ装置２０のＵＲＩと共に、他のサービスクライアントに共有されるものとする。即ち、第二サービスクライアント６０に対応して発行されたアクセストークンは、サービスプロバイダ装置２０のＵＲＩと共に、第一サービスクライアント４０にも保存されているものとする。
Ｗｅｂブラウザでは、第二Ｗｅｂサービス用のＪａｖａＳｃｒｉｐｔ（登録商標）によるアプリケーションが実行される。ユーザ端末８０において、Ｗｅｂブラウザを介した、サービスプロバイダ装置２０と第一サービスクライアント４０のそれぞれとの通信は、第二Ｗｅｂサービス用のＪａｖａＳｃｒｉｐｔ（登録商標）によるアプリケーションによって実現される。この通信は、例えば、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ Ｌｅｖｅｌ ２に従う。ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ Ｌｅｖｅｌ ２では、ＪａｖａＳｃｒｉｐｔ（登録商標）によるアプリケーションは、複数のドメイン（クロスドメイン）との通信が可能となる。
取得判断処理は、例えば、上述したような状態で実行される。取得判断処理の説明は、このような状態を例として行う。取得判断処理を開始させたＣＰＵ２１は、ユーザ端末８０からのＨＴＴＰリクエストが取得されたかを判断する（Ｓ３１）。ＨＴＴＰリクエストは、通信部２４で受信される。ＣＰＵ２１は、通信部２４を介してＨＴＴＰリクエストを取得する。Ｓ３１で取得されるＨＴＴＰリクエストは、第一ＷｅｂサービスのＡＰＩを利用した、ユーザのリソースへの接続を要求するリソース要求である。取得されたＨＴＴＰリクエストは、ＲＡＭ２３に記憶される。
リソース要求としてのＨＴＴＰリクエストは、アクセストークンと、オリジンを含む。実施形態における例に基づけば、Ｓ３１で取得されるＨＴＴＰリクエストは、図７に示すように、アクセストークンとして「ｄ２１ｃ９ｄ８８１ｅｂａ６９８８ｂｅ４８０ｅｆａｂ４５ｄｅ２ｂ９」を含む（ＨＴＴＰリクエストの「Ａｕｔｈｏｒｉｚａｔｉｏｎ：」参照）。このＨＴＴＰリクエストは、図７に示すように、オリジンとしてアクセス元のドメイン情報を含むＵＲＩ「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」を含む（ＨＴＴＰリクエストの「Ｏｒｉｇｉｎ：」参照）。このようなＨＴＴＰリクエストは、公知のＸＭＬＨｔｔｐＲｅｑｕｅｓｔ Ｌｅｖｅｌ ２に従っている。そのため、これに関するこの他の説明は省略する。
次に、ＣＰＵ２１は、取得されたＨＴＴＰリクエストから、アクセストークンと、オリジンとして指定されたＵＲＩを取得する（Ｓ３３）。ＣＰＵ２１は、第二データベースから、取得されたアクセストークンに一致するアクセストークンに関連付けられたアプリケーションＩＤを特定する（Ｓ３５）。第二データベースが図５に示す状態であるとする。この場合、ＣＰＵ２１は、第二データベースで、アクセストークン「ｄ２１ｃ９ｄ８８１ｅｂａ６９８８ｂｅ４８０ｅｆａｂ４５ｄｅ２ｂ９」に関連付けられたアプリケーションＩＤ「１」を特定する。
続けて、ＣＰＵ２１は、後述するＳ３９の判断条件となるリダイレクトＵＲＩを特定する（Ｓ３７）。判断条件となるリダイレクトＵＲＩは、第一データベースで、Ｓ３５で特定されたアプリケーションＩＤに一致するレコードＩＤに関連付けられたリダイレクトＵＲＩである。ＣＰＵ２１は、Ｓ３３で取得されたＵＲＩと、Ｓ３７で特定されたリダイレクトＵＲＩが一致するかを判断する（Ｓ３９）。判断に際し、ＣＰＵ２１は、このリダイレクトＵＲＩと共に、Ｓ３５で特定されたアプリケーションＩＤに一致するレコードＩＤに関連付けられた階層情報を特定する。即ち、ＣＰＵ２１は、Ｓ３７で、第一データベースから、Ｓ３５で特定されたアプリケーションＩＤに一致するレコードＩＤに関連付けられたリダイレクトＵＲＩを取得し、Ｓ３９で、第一データベースから、同じレコードＩＤに関連付けられた階層情報を取得する。ＣＰＵ２１は、次のような場合、Ｓ３３で取得されたＵＲＩと、Ｓ３７で特定されたリダイレクトＵＲＩは一致すると判断する。即ち、ＣＰＵ２１は、Ｓ３３で取得されたＵＲＩと、Ｓ３７で特定されたリダイレクトＵＲＩが同じである場合、両情報は一致するとし、Ｓ３９を肯定（Ｓ３９：Ｙｅｓ）する。更に、ＣＰＵ２１は、Ｓ３３で取得されたＵＲＩと、前述した階層情報に対応する階層におけるリダイレクトＵＲＩの部分が一致する場合、両情報は一致（部分一致）するとし、Ｓ３９を肯定（Ｓ３９：Ｙｅｓ）する。
例えば、第一データベースが図３に示す状態であり、第二データベースが図５に示す状態であるとする。Ｓ３３で、ＨＴＴＰリクエストからオリジンとして指定されたＵＲＩ「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」が取得され、Ｓ３５で、アプリケーションＩＤ「１」が特定されていたとする。この場合、Ｓ３７でＣＰＵ２１は、第一データベースから、レコードＩＤ「１」に関連付けられたリダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」を特定する。Ｓ３９でＣＰＵ２１は、「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」と「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」が一致するかを判断する。その際、ＣＰＵ２１は、第一データベースにアクセスし、レコードＩＤ「１」に関連付けられた階層情報「ｅｘａｍｐｌｅ．ｃｏｍ」を特定する。「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」は、「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」のうち、階層情報「ｅｘａｍｐｌｅ．ｃｏｍ」に従った最下位のドメインの階層より上位の階層（トップレベルドメイン及びセカンドレベルドメイン）の部分「ｅｘａｍｐｌｅ．ｃｏｍ」を含む。従って、ＣＰＵ２１は、両情報は一致（部分一致）するとして、Ｓ３９を肯定（Ｓ３９：Ｙｅｓ）する。これとは異なり、例えば、Ｓ３７でリダイレクトＵＲＩとして「ｈｔｔｐｓ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ」が特定され、階層情報として「ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ」が特定されていたとする。この場合、「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」は、リダイレクトＵＲＩのうち、前述した階層情報に対応する階層の部分「ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ」を含まない。従って、ＣＰＵ２１は、Ｓ３９を否定（Ｓ３９：Ｎｏ）する。
Ｓ３９が肯定された場合（Ｓ３９：Ｙｅｓ）、ＣＰＵ２１は、ＨＴＴＰレスポンスに、「認証要」と「許可ドメイン」を指定する（Ｓ４１）。ＨＴＴＰレスポンスは、取得されたＨＴＴＰリクエストに対する応答である。「認証要」は、認証が必要であることを示す情報である。「許可ドメイン」は、許可されたドメインを示す情報である。図７に示すＨＴＴＰレスポンスは、これら２個の情報が指定されたＨＴＴＰレスポンスである。このＨＴＴＰレスポンスでは、「認証要」として、「Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌ： ｔｒｕｅ」が指定されている。「許可ドメイン」として、アクセス元のドメイン情報を含むＵＲＩ「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」を含む、「Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎ： ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」が指定されている。
Ｓ３９が否定された場合（Ｓ３９：Ｎｏ）、又はＳ４１を実行した後、ＣＰＵ２１は、ＨＴＴＰレスポンスの送信を制御する（Ｓ４３）。即ち、ＣＰＵ２１は、ＨＴＴＰレスポンスの送信指令を通信部２４に出力する。送信先は、ＨＴＴＰリクエストの送信元であるユーザ端末８０に設定される。これに伴い、ＨＴＴＰレスポンスが、通信部２４からユーザ端末８０に送信される。Ｓ４１が実行されていた場合、上述した通り、「認証要」と「許可ドメイン」を含むＨＴＴＰレスポンス（図７参照）が送信される。Ｓ３９が否定（Ｓ３９：Ｎｏ）され、Ｓ４１が未実行である場合、「許可ドメイン」を含まないＨＴＴＰレスポンス（図８参照）、又は「認証要」と「許可ドメイン」を含まないＨＴＴＰレスポンス（図９参照）が送信される。図８に示すＨＴＴＰレスポンスでは、「Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎ」における指定が空の状態とされる。図９に示すＨＴＴＰレスポンスは、アクセスする権限がないことを明示的に示すステータスを含む。図７〜図９に示すＨＴＴＰレスポンスは、公知のＸＭＬＨｔｔｐＲｅｑｕｅｓｔ Ｌｅｖｅｌ ２に従っている。そのため、これらに関するこの他の説明は省略する。
Ｓ４３を実行した後、ＣＰＵ２１は、処理をＳ３１に戻す。その後、ＣＰＵ２１は、Ｓ３１以降の処理を繰り返して実行する。取得判断処理は、この処理の終了指示がサービスプロバイダ装置２０で受け付けられ、ＣＰＵ２１がこれを取得した場合に終了する。
＜実施形態の効果＞
実施形態によれば、次のような効果を得ることができる。
（１）サービスプロバイダ装置２０では、第一データベースと第二データベースが、ＲＡＭ２３又は記憶装置２２に記憶される。第一データベースには、レコードＩＤとサービス名とクライアントＩＤとシークレットＩＤとリダイレクトＵＲＩと階層情報が、関連付けられた状態で記憶される（図３参照）。第二データベースには、レコードＩＤとユーザＩＤとアプリケーションＩＤとアクセストークンが、関連付けられた状態で記憶される（図５参照）。第一データベースと第二データベースでは、第一データベースのレコードＩＤと第二データベースのアプリケーションＩＤによって、第一データベースに記憶されたレコードと、第二データベースに記憶されたレコードが関連付けられる。
サービスプロバイダ装置２０で実行される取得判断処理（図６参照）では、第二データベースから、ＨＴＴＰリクエストに含まれるアクセストークンに一致するアクセストークンに関連付けられたアプリケーションＩＤが特定される（図６のＳ３５参照）。続けて、第一データベースで、このアプリケーションＩＤに一致するレコードＩＤに関連付けられたリダイレクトＵＲＩが、Ｓ３９の判断条件として特定され（図６のＳ３７参照）、ＨＴＴＰリクエストでオリジンとして指定されたアクセス元のドメイン情報を含むＵＲＩと、リダイレクトＵＲＩの一致が判断される（図６のＳ３９参照）。オリジンとして指定されたＵＲＩとリダイレクトＵＲＩが一致している場合（図６のＳ３９：Ｙｅｓ参照）、ＨＴＴＰレスポンスに、「認証要（Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｃｒｅｄｅｎｔｉａｌ： ｔｒｕｅ）」と、「許可ドメイン（Ａｃｃｅｓｓ−Ｃｏｎｔｒｏｌ−Ａｌｌｏｗ−Ｏｒｉｇｉｎ： ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ）」が指定される（図６のＳ４１及び図７参照）。両ＵＲＩが一致していない場合（図６のＳ３９：Ｎｏ参照）、ＨＴＴＰレスポンスには、「認証要」と「許可ドメイン」は指定されない（図６のＳ４１：未実行）。その後、ＨＴＴＰレスポンスが、ＨＴＴＰリクエストの送信元であるユーザ端末８０に送信される（図６のＳ４３参照）。
そのため、第一ＷｅｂサービスのＡＰＩを利用したユーザのリソースへの接続に利用されるアクセストークンが、第二サービスクライアント６０に対応して発行されている状態（図４のＴ１５及びＴ１６参照）において、第一サービスクライアント４０にＷｅｂブラウザを介してアクセスしているユーザ端末８０（図７参照）に、このアクセストークンによって、同じリソースへの接続を認可することができる。ユーザ端末８０が、第一サービスクライアント４０に、Ｗｅｂブラウザを介してアクセスしている状態において、第一Ｗｅｂサービスに対応するリソースに接続する場合、再度、第一サービスクライアント４０に対応するアクセストークンを発行する必要がない。第一Ｗｅｂサービスと第二Ｗｅｂサービスの連携と、第一Ｗｅｂサービスと第三Ｗｅｂサービスの連携を、スムーズに実現させることができる。
（２）第一データベースにおいて、リダイレクトＵＲＩのドメイン階層を示す情報として階層情報を登録することとした（図３参照）。階層情報がリダイレクトＵＲＩの一部に対応する場合、図６のＳ３９で、第一サービスクライアント４０が、第二サービスクライアント６０と基底ドメインが共通するかを判断することができる。階層情報の設定によって、第二サービスクライアント６０と同一であると判断される第一サービスクライアント４０の範囲を適宜設定することができる。
＜変形例＞
上述した実施形態は、次のようにすることもできる。以下に示す変形例のうちの幾つかの構成は、適宜組み合わせて採用することもできる。以下では、上記とは異なる点を説明することとし、同様の点についての説明は適宜省略する。
（１）上記では、ＯＡｕｔｈプロトコルとＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルを例として説明した。そのため、アックセストークンを認証情報とした。認証は、ＯＡｕｔｈプロトコル及びＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルとは異なるプロトコルを利用することもできる。この場合、認証情報には、利用されるプロトコルにおいて定義された、ＯＡｕｔｈプロトコル及びＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルにおけるアクセストークンに相当する情報が用いられる。
（２）上記では、第一データベースにおける階層情報として、ドメイン情報を記憶することとした（図３参照）。階層情報は、例えば、階層を示す数値であってもよい。図３に示す第一データベースにおけるレコードＩＤ「１」に関連付けられた、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」を例として説明する。この場合、階層情報として「２」を記憶するようにしてもよい。階層情報「２」は、セカンドレベルドメインに対応する。図６に示す取得判断処理におけるＳ３７でＣＰＵ２１は、第一データベースから、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」を特定する。その後、Ｓ３９でＣＰＵ２１は、上記同様、Ｓ３３で取得されたＵＲＩと、リダイレクトＵＲＩの一致を判断する。その際、ＣＰＵ２１は、階層情報「２」を特定する。即ち、ＣＰＵ２１は、Ｓ３３で取得されたＵＲＩと、リダイレクトＵＲＩ「ｈｔｔｐｓ：／／ｑｕｘ．ｅｘａｍｐｌｅ．ｃｏｍ」のうち、階層情報「２」に対応する階層の部分「ｅｘａｍｐｌｅ．ｃｏｍ」が一致（部分一致）するかを判断する。
（３）上記では、図６に示す取得判断処理のＳ３７で、Ｓ３５で特定されたアプリケーションＩＤに一致するレコードＩＤに関連付けられたリダイレクトＵＲＩを特定し、Ｓ３９で、Ｓ３３で取得されたＵＲＩと、Ｓ３７で特定されたリダイレクトＵＲＩが一致するかを判断することとした。図６のＳ３７とＳ３９に対応する処理は、次のように行うようにしてもよい。即ち、Ｓ３７のタイミングで、ＣＰＵ２１は、第一データベースで、Ｓ３５で特定されたアプリケーションＩＤに一致するレコードＩＤに関連付けられた階層情報を、判断条件となるリダイレクトＵＲＩの一部又は全部として特定する。Ｓ３９のタイミングで、ＣＰＵ２１は、Ｓ３３で取得されたＵＲＩと、リダイレクトＵＲＩの一部又は全部である階層情報が一致するかを判断する。例えば、第一データベースが図３に示す状態であり、第二データベースが図５に示す状態であるとする。図６のＳ３３で、ＨＴＴＰリクエストから、オリジンとして指定されたＵＲＩ「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」が取得され、Ｓ３５で、アプリケーションＩＤ「１」が特定されていたとする。この場合、Ｓ３７のタイミングで、ＣＰＵ２１は、第一データベースから、レコードＩＤ「１」に関連付けられた階層情報「ｅｘａｍｐｌｅ．ｃｏｍ」を、判断条件となるリダイレクトＵＲＩの一部として特定する。Ｓ３９のタイミングで、ＣＰＵ２１は、「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」と「ｅｘａｍｐｌｅ．ｃｏｍ」の一致を判断する。「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」は、「ｅｘａｍｐｌｅ．ｃｏｍ」を含む。換言すれば、「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」は、最下位のドメインの階層より上位の階層（トップレベルドメイン及びセカンドレベルドメイン）で、「ｅｘａｍｐｌｅ．ｃｏｍ」に一致（部分一致）する。従って、ＣＰＵ２１は、Ｓ３９を肯定（Ｓ３９：Ｙｅｓ）する。これとは異なり、例えば、Ｓ３７で「ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ」が特定されていたとする。この場合、「ｈｔｔｐｓ：／／ｆｏｏ．ｅｘａｍｐｌｅ．ｃｏｍ」は、「ｗｗｗ．ｅｘａｍｐｌｅ．ｊｐ」を含まない。従って、ＣＰＵ２１は、Ｓ３９を否定（Ｓ３９：Ｎｏ）する。
（４）上記では、第二データベースにおけるアプリケーションＩＤとして、第一データベースにおけるレコードＩＤを記憶することとした（図５参照）。第二データベースにおいて、アプリケーションＩＤとして登録される識別情報は、第一データベースに記憶されるレコードＩＤ以外の情報であってもよい。例えば、第二データベースでは、アプリケーションＩＤとして、第一データベースに記憶されたクライアントＩＤを記憶するようにしてもよい。即ち、第二データベースにおけるアプリケーションＩＤは、第一データベースに記憶されたレコードとの関連付けを可能とする情報であればよい。
第一データベースと第二データベースは、単一のデータベースとしてもよい。即ち、第一データベースと第二データベースは、レコードＩＤとサービス名とクライアントＩＤとシークレットＩＤとリダイレクトＵＲＩと階層情報とユーザＩＤとアクセストークンが、関連付けられた状態で記憶される、単一のデータベースとしてもよい。このデータベースでは、第一データベースに記憶されたレコードと、第二データベースに記憶されたレコードを関連付けるアプリケーションＩＤは、省略するようにしてもよい。この場合、図６に示す取得判断処理におけるＳ３５は省略される。図６のＳ３７では、図６のＳ３３で取得されたアクセストークンに一致するアクセストークンに関連付けられたリダイレクトＵＲＩが取得され、図６のＳ３９以降の処理が上記同様に行われる。
１０ サービス提供システム
１２ インターネット
２０ サービスプロバイダ装置
２１ ＣＰＵ
２２ 記憶装置
２３ ＲＡＭ
２４ 通信部
２５ バス
４０ 第一サービスクライアント
６０ 第二サービスクライアント
８０ ユーザ端末

Claims (8)

  1. インターネットを介した第一Ｗｅｂサービスを提供するサービスプロバイダ装置であって、
    所定のＷｅｂサービスを提供する所定のサービスクライアントに対応する第一識別情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続を認可する認可情報を転送するアドレスに対応する転送先情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された認証情報と、を関連付けて記憶する関連付け部と、
    第二Ｗｅｂサービスを提供する第一サービスクライアントに、Ｗｅｂブラウザを介してアクセスしている端末装置から送信され、前記第一サービスクライアントのドメイン情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、第三Ｗｅｂサービスを提供する第二サービスクライアントに対応して発行された認証情報と、を含み、前記第一Ｗｅｂサービスに対応するリソースへの接続を要求するリソース要求を、前記サービスプロバイダ装置を前記インターネットに接続する前記サービスプロバイダ装置の通信部を介して取得する取得手段と、
    前記取得手段によって取得された前記リソース要求に含まれる前記認証情報に一致する、前記関連付け部に記憶された前記認証情報に関連付けられた前記転送先情報を、前記関連付け部から特定する特定手段と、
    前記取得手段によって取得された前記リソース要求に含まれる前記ドメイン情報と、前記特定手段によって特定された前記転送先情報と、が少なくとも一部のドメインの階層で一致するかを判断する判断手段と、
    前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致する場合、認証が必要であることを示す情報と前記ドメイン情報とを含む、前記リソース要求に対する第一応答を、前記通信部から前記端末装置に送信し、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記ドメイン情報を含まない、前記リソース要求に対する第二応答を、前記通信部から前記端末装置に送信する、送信手段と、を備えるサービスプロバイダ装置。
  2. 前記関連付け部は、
    前記第一識別情報と、前記転送先情報と、を関連付けて記憶する第一関連付け部と、
    前記第一識別情報に対応する第二識別情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された前記認証情報と、を関連付けて記憶する第二関連付け部と、を含み、
    前記特定手段は、前記取得手段によって取得された前記リソース要求に含まれる前記認証情報に一致する、前記第二関連付け部に記憶された前記認証情報に関連付けられた前記第二識別情報を、前記第二関連付け部から特定し、特定された前記第二識別情報に対応する前記第一識別情報に関連付けられた前記転送先情報を、前記第一関連付け部から特定する、請求項１に記載のサービスプロバイダ装置。
  3. 前記判断手段は、最下位のドメインの階層より上位の階層で、前記ドメイン情報と、前記転送先情報と、が一致するかを判断し、
    前記送信手段は、前記最下位のドメインの階層より上位の階層で、前記ドメイン情報と前記転送先情報とが一致する場合、前記第一応答を、前記通信部から前記端末装置に送信し、前記最下位のドメインの階層より上位の階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記第二応答を、前記通信部から前記端末装置に送信する、請求項１又は請求項２に記載のサービスプロバイダ装置。
  4. 前記関連付け部は、更に、前記転送先情報のドメインの階層を示す階層情報を関連付けて記憶し、
    前記判断手段は、前記階層情報に対応するドメインの階層で、前記ドメイン情報と、前記転送先情報と、が一致するかを判断し、
    前記送信手段は、
    前記階層情報に対応するドメインの階層で、前記ドメイン情報と前記転送先情報とが一致する場合、前記第一応答を、前記通信部から前記端末装置に送信し、前記階層情報に対応するドメインの階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記第二応答を、前記通信部から前記端末装置に送信する、請求項１から請求項３の何れか１項に記載のサービスプロバイダ装置。
  5. 前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された前記認証情報として、ＯＡｕｔｈプロトコルにおけるアクセストークンを生成する生成手段を備え、
    前記関連付け部は、更に、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された前記認証情報として、前記生成手段によって生成された前記アクセストークンを関連付けて記憶し、
    前記取得手段は、前記ドメイン情報と、前記第二サービスクライアントに対応して発行された前記認証情報としての前記アクセストークンと、を含むリソース要求を、前記通信部を介して取得し、
    前記特定手段は、前記取得手段によって取得された前記リソース要求に含まれる前記アクセストークンに一致する、前記関連付け部に記憶された前記アクセストークンに関連付けられた前記転送先情報を、前記関連付け部から特定する、請求項１から請求項４の何れか１項に記載のサービスプロバイダ装置。
  6. 前記取得手段は、前記リソース要求として、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔプロトコルにおけるＨＴＴＰリクエストを取得し、
    前記特定手段は、前記取得手段によって取得された前記ＨＴＴＰリクエストに含まれる前記アクセストークンに一致する、前記関連付け部に記憶された前記アクセストークンに関連付けられた前記転送先情報を、前記関連付け部から特定し、
    前記送信手段は、前記取得手段によって取得された前記ＨＴＴＰリクエストに対して、前記第一応答と、前記第二応答と、を前記通信部から前記端末装置に送信する、請求項５に記載のサービスプロバイダ装置。
  7. インターネットを介した第一Ｗｅｂサービスを提供するサービスプロバイダ装置を制御するコンピュータが実行可能なプログラムであって、
    前記コンピュータを、
    第二Ｗｅｂサービスを提供する第一サービスクライアントに、Ｗｅｂブラウザを介してアクセスしている端末装置から送信され、前記第一サービスクライアントのドメイン情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、第三Ｗｅｂサービスを提供する第二サービスクライアントに対応して発行された認証情報と、を含み、前記第一Ｗｅｂサービスに対応するリソースへの接続を要求するリソース要求を、前記サービスプロバイダ装置を前記インターネットに接続する前記サービスプロバイダ装置の通信部を介して取得する取得手段と、
    所定のＷｅｂサービスを提供する所定のサービスクライアントに対応する第一識別情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続を認可する認可情報を転送するアドレスに対応する転送先情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された認証情報と、を関連付けて記憶する関連付け部から、前記取得手段によって取得された前記リソース要求に含まれる前記認証情報に一致する、前記関連付け部に記憶された前記認証情報に関連付けられた前記転送先情報を特定する特定手段と、
    前記取得手段によって取得された前記リソース要求に含まれる前記ドメイン情報と、前記特定手段によって特定された前記転送先情報と、が少なくとも一部のドメインの階層で一致するかを判断する判断手段と、
    前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致する場合、認証が必要であることを示す情報と前記ドメイン情報とを含む、前記リソース要求に対する第一応答を、前記通信部から前記端末装置に送信し、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記ドメイン情報を含まない、前記リソース要求に対する第二応答を、前記通信部から前記端末装置に送信する、送信手段と、して機能させるプログラム。
  8. インターネットを介した第一Ｗｅｂサービスを提供するサービスプロバイダ装置で実行されるサービス提供方法であって、
    第二Ｗｅｂサービスを提供する第一サービスクライアントに、Ｗｅｂブラウザを介してアクセスしている端末装置から送信され、前記第一サービスクライアントのドメイン情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、第三Ｗｅｂサービスを提供する第二サービスクライアントに対応して発行された認証情報と、を含み、前記第一Ｗｅｂサービスに対応するリソースへの接続を要求するリソース要求を、前記サービスプロバイダ装置を前記インターネットに接続する前記サービスプロバイダ装置の通信部を介して取得する取得工程と、
    所定のＷｅｂサービスを提供する所定のサービスクライアントに対応する第一識別情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続を認可する認可情報を転送するアドレスに対応する転送先情報と、前記第一Ｗｅｂサービスに対応するリソースへの接続に関し、前記第一識別情報によって識別される前記所定のサービスクライアントに対応して発行された認証情報と、を関連付けて記憶する関連付け部から、前記取得工程で取得された前記リソース要求に含まれる前記認証情報に一致する、前記関連付け部に記憶された前記認証情報に関連付けられた前記転送先情報を特定する特定工程と、
    前記取得工程で取得された前記リソース要求に含まれる前記ドメイン情報と、前記特定工程で特定された前記転送先情報と、が少なくとも一部のドメインの階層で一致するかを判断する判断工程と、
    前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致する場合、認証が必要であることを示す情報と前記ドメイン情報とを含む、前記リソース要求に対する第一応答を、前記通信部から前記端末装置に送信し、前記少なくとも一部のドメインの階層で、前記ドメイン情報と前記転送先情報とが一致しない場合、前記ドメイン情報を含まない、前記リソース要求に対する第二応答を、前記通信部から前記端末装置に送信する、送信工程と、を含むサービス提供方法。
JP2014199413A 2014-09-29 2014-09-29 サービスプロバイダ装置、プログラム及びサービス提供方法 Active JP6119709B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2014199413A JP6119709B2 (ja) 2014-09-29 2014-09-29 サービスプロバイダ装置、プログラム及びサービス提供方法
US14/867,383 US9686264B2 (en) 2014-09-29 2015-09-28 Service providing apparatus, storage medium and service providing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014199413A JP6119709B2 (ja) 2014-09-29 2014-09-29 サービスプロバイダ装置、プログラム及びサービス提供方法

Publications (2)

Publication Number Publication Date
JP2016071561A JP2016071561A (ja) 2016-05-09
JP6119709B2 true JP6119709B2 (ja) 2017-04-26

Family

ID=55585722

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014199413A Active JP6119709B2 (ja) 2014-09-29 2014-09-29 サービスプロバイダ装置、プログラム及びサービス提供方法

Country Status (2)

Country Link
US (1) US9686264B2 (ja)
JP (1) JP6119709B2 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170187726A1 (en) * 2015-12-24 2017-06-29 Zeta (Better World Technology Pvt. Ltd.) Cross-domain message authentication
KR101775518B1 (ko) * 2016-02-23 2017-09-06 한국전자통신연구원 접근 권한 별로 분리된 브라우저 프로세스를 이용한 브라우저 제공 방법 및 이를 이용한 장치
JP6596597B2 (ja) * 2016-11-30 2019-10-30 キヤノン電子株式会社 情報処理装置およびその制御方法、並びにプログラム
KR20190013357A (ko) * 2017-08-01 2019-02-11 주식회사 유비스티 게임화 투어테인먼트 서비스 플랫폼
EP3553719B1 (en) * 2018-04-11 2020-05-13 Barclays Execution Services Limited System for reliably accessing a protected resource
US12047373B2 (en) * 2019-11-05 2024-07-23 Salesforce.Com, Inc. Monitoring resource utilization of an online system based on browser attributes collected for a session
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
CN114222301B (zh) * 2021-12-13 2024-04-12 奇安盘古(上海)信息技术有限公司 诈骗站点处理方法、装置及存储介质

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001325229A (ja) 2000-05-17 2001-11-22 Daiwa House Ind Co Ltd インターネットにおける認証システム及びサービスシステム
US20020133720A1 (en) * 2001-03-16 2002-09-19 Clickgarden Method for filtering the transmission of data on a computer network to Web domains
JP4179535B2 (ja) * 2002-09-03 2008-11-12 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワークシステム、リバースプロキシ、コンピュータ装置、データ処理方法及びプログラム
WO2005103960A1 (en) * 2004-04-20 2005-11-03 The Boeing Company Apparatus and method for redirecting unresolvable addresses using a local care-of ip address
JP2008197973A (ja) * 2007-02-14 2008-08-28 Mitsubishi Electric Corp ユーザ認証システム
JP2010074431A (ja) * 2008-09-17 2010-04-02 Ricoh Co Ltd 外部認証を用いた認証機能連携機器、認証機能連携システム及び認証機能連携プログラム
JP2011034462A (ja) * 2009-08-04 2011-02-17 Canon Inc 情報処理装置及びその処理方法
EP2315149B1 (en) * 2009-10-26 2019-11-20 Alcatel Lucent System and method for accessing private digital content
WO2012069263A2 (en) * 2010-11-24 2012-05-31 Telefonica, S.A. Method for authorizing access to protected content
KR20130105714A (ko) * 2010-12-17 2013-09-25 노키아 지멘스 네트웍스 오와이 웹 리소스들을 위한 유저 인터랙션
US8990557B2 (en) * 2011-02-17 2015-03-24 Ebay Inc. Identity assertion framework
JP5820188B2 (ja) * 2011-08-19 2015-11-24 キヤノン株式会社 サーバおよびその制御方法、並びにプログラム
US8667579B2 (en) * 2011-11-29 2014-03-04 Genband Us Llc Methods, systems, and computer readable media for bridging user authentication, authorization, and access between web-based and telecom domains
CN103716283B (zh) * 2012-09-29 2017-03-08 国际商业机器公司 用于在流程中处理调用的Web服务的OAuth认证的方法和系统

Also Published As

Publication number Publication date
US9686264B2 (en) 2017-06-20
JP2016071561A (ja) 2016-05-09
US20160094534A1 (en) 2016-03-31

Similar Documents

Publication Publication Date Title
JP6119709B2 (ja) サービスプロバイダ装置、プログラム及びサービス提供方法
US20200296107A1 (en) Centralized authentication for granting access to online services
CN110138718B (zh) 信息处理系统及其控制方法
JP6533871B2 (ja) ウェブアプリケーションへのサインオンを制御するためのシステムおよび方法
US9053306B2 (en) Authentication system, authentication server, service providing server, authentication method, and computer-readable recording medium
JP6929181B2 (ja) デバイスと、その制御方法とプログラム
JP2018163616A (ja) 認証認可サーバー、リソースサーバー、認証認可システム、認証方法及びプログラム
US20180205745A1 (en) System, method and computer program product for access authentication
JP5485356B1 (ja) 情報処理装置、情報処理装置の制御方法、および制御プログラム。
US9787679B2 (en) Teleconference system and storage medium storing program for teleconference
JP2016051329A (ja) コンテンツ管理装置及びその制御方法
JP2019101668A (ja) システムおよびその制御方法
JP4847483B2 (ja) 個人属性情報提供システムおよび個人属性情報提供方法
KR101803535B1 (ko) 일회용 토큰을 이용한 싱글 사인온 서비스 인증방법
JP5690030B1 (ja) 情報処理装置、情報処理方法、プログラム及び記録媒体
JP2016085638A (ja) サーバー装置、端末装置、システム、情報処理方法及びプログラム
JP7200776B2 (ja) 情報処理システム及びプログラム
JP6570090B2 (ja) ルータ装置及びルータ装置のフィルタリング方法
KR20140121571A (ko) 통합 인증 시스템, 그의 통합 인증 방법 및 이를 위한 장치
JP6162056B2 (ja) 広告コンテンツ配信システムおよび広告コンテンツ配信方法
JP6059307B1 (ja) 端末装置、情報送信方法、及び情報送信プログラム
TWI772954B (zh) 透過裝置識別符之網路接取技術
JP7243144B2 (ja) 端末装置、認証支援装置及びプログラム
JP6395227B2 (ja) ルータ装置及びルータ装置のフィルタリング方法
JP2013257625A (ja) 認証要求変換装置および認証要求変換方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160309

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170117

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170228

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170313

R150 Certificate of patent or registration of utility model

Ref document number: 6119709

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150