特許 6785526 ネットワークサービス連携方法、クライアントサービスプラットフォーム、クライアントインスタンス生成サーバ及びプログラム

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

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

(11)【特許番号】6785526

(24)【登録日】2020年10月29日

(45)【発行日】2020年11月18日

(54)【発明の名称】ネットワークサービス連携方法、クライアントサービスプラットフォーム、クライアントインスタンス生成サーバ及びプログラム

(51)【国際特許分類】

   H04L 12/66 20060101AFI20201109BHJP

   H04L 12/70 20130101ALI20201109BHJP

   G06F 21/33 20130101ALI20201109BHJP

【ＦＩ】

   H04L12/66 B

   H04L12/70 100Z

   G06F21/33

【請求項の数】4

【全頁数】12

(21)【出願番号】特願2017-179958(P2017-179958)

(22)【出願日】2017年9月20日

(65)【公開番号】特開2019-57778(P2019-57778A)

(43)【公開日】2019年4月11日

【審査請求日】2019年8月28日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100119677

【弁理士】

【氏名又は名称】岡田 賢治

(74)【代理人】

【識別番号】100115794

【弁理士】

【氏名又は名称】今下 勝博

(72)【発明者】

【氏名】川幡 太一

(72)【発明者】

【氏名】坂井田 規夫

(72)【発明者】

【氏名】谷口 篤

(72)【発明者】

【氏名】南 勇貴

【審査官】 野元 久道

(56)【参考文献】

【文献】 津田 宏 外３名，研究開発最前線，ＦＵＪＩＴＳＵ，富士通株式会社，２０１１年 ９月２９日，第62巻 第5号，p.531-537

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

Ｈ０４Ｌ １２／６６

Ｇ０６Ｆ ２１／３３

Ｈ０４Ｌ １２／７０

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

【請求項1】

ユーザ端末毎に所望のサービスを提供するリソースサーバのオープンＡＰＩを利用可能なクライアントをインスタンスとして生成するクライアントインスタンス生成サーバと、前記ユーザ端末から前記クライアントへのアクセスを介するクライアントゲートウェーと、前記クライアントから前記リソースサーバへのアクセスを介するサービスゲートウェーと、を備えたクライアントサービスプラットフォームにおけるネットワークサービス連携方法であって、
前記クライアントインスタンス生成サーバが、
前記クライアントの生成とともに、前記クライアントへの前記クライアントゲートウェー以外からのアクセス、および前記クライアントから前記サービスゲートウェー以外へのアクセスを遮断するファイアウォール機能を生成し、
前記ファイアウォール機能は、
前記クライアントの有効性を確認するアクセストークンを前記リソースサーバ側から前記クライアントゲートウェーに取得させ、前記ユーザ端末から前記クライアントゲートウェー及び前記クライアントを経由して前記サービスゲートウェーへ転送されるアクセスに前記アクセストークンを付加するとともに、
前記ユーザ端末の識別情報、前記リソースサーバのアドレス及び前記クライアントのアドレスを前記クライアントゲートウェーから前記サービスゲートウェーへ通知させ、前記サービスゲートウェーにて前記クライアントから前記サービスゲートウェーへ転送される前記アクセスの送信元と送信先を確認する
ことを特徴とするネットワークサービス連携方法。

【請求項2】

ユーザ端末毎に所望のサービスを提供するリソースサーバのオープンＡＰＩを利用可能なクライアントをインスタンスとして生成するクライアントインスタンス生成サーバと、
前記ユーザ端末から前記クライアントへのアクセスを介するクライアントゲートウェーと、
前記クライアントから前記リソースサーバへのアクセスを介するサービスゲートウェーと、
を備えたクライアントサービスプラットフォームであって、
前記クライアントインスタンス生成サーバは、
前記クライアントの生成とともに、前記クライアントへの前記クライアントゲートウェー以外からのアクセス、および前記クライアントから前記サービスゲートウェー以外へのアクセスを遮断するファイアウォール機能を生成し、
前記ファイアウォール機能は、
前記クライアントの有効性を確認するアクセストークンを前記リソースサーバ側から前記クライアントゲートウェーに取得させ、前記ユーザ端末から前記クライアントゲートウェー及び前記クライアントを経由して前記サービスゲートウェーへ転送されるアクセスに前記アクセストークンを付加するとともに、
前記ユーザ端末の識別情報、前記リソースサーバのアドレス及び前記クライアントのアドレスを前記クライアントゲートウェーから前記サービスゲートウェーへ通知させ、前記サービスゲートウェーにて前記クライアントから前記サービスゲートウェーへ転送される前記アクセスの送信元と送信先を確認する
ことを特徴とするクライアントサービスプラットフォーム。

【請求項3】

ユーザ端末毎に所望のサービスを提供するリソースサーバのオープンＡＰＩを利用可能なクライアントをインスタンスとして、前記ユーザ端末から前記クライアントへのアクセスを介するクライアントゲートウェーと、前記クライアントから前記リソースサーバへのアクセスを介するサービスゲートウェーと、を備えたクライアントサービスプラットフォームに生成するクライアントインスタンス生成サーバであって、
前記クライアントの生成とともに、前記クライアントへの前記クライアントゲートウェー以外からのアクセス、および前記クライアントから前記サービスゲートウェー以外へのアクセスを遮断するファイアウォール機能を生成し、
前記ファイアウォール機能は、
前記クライアントの有効性を確認するアクセストークンを前記リソースサーバ側から前記クライアントゲートウェーに取得させ、前記ユーザ端末から前記クライアントゲートウェー及び前記クライアントを経由して前記サービスゲートウェーへ転送されるアクセスに前記アクセストークンを付加するとともに、
前記ユーザ端末の識別情報、前記リソースサーバのアドレス及び前記クライアントのアドレスを前記クライアントゲートウェーから前記サービスゲートウェーへ通知させ、前記サービスゲートウェーにて前記クライアントから前記サービスゲートウェーへ転送される前記アクセスの送信元と送信先を確認する
ことを特徴とするクライアントインスタンス生成サーバ。

【請求項4】

コンピュータを請求項３に記載のクライアントインスタンス生成サーバとして機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、複数の異なる事業者が運営するサービスを連携し、ユーザに提供するネットワークサービス連携方法、クライアントサービスプラットフォーム、クライアントインスタンス生成サーバ及びプログラムに関する。

【背景技術】

【0002】

現在、多くのＢ２Ｂ２Ｃ（Ｂｕｓｉｎｅｓｓ ｔｏ Ｂｕｓｉｎｅｓｓ ｔｏ Ｃｏｎｓｕｍｅｒ）サービスは、Ｏａｕｔｈ等の認可技術（例えば、非特許文献２を参照。）を用いてユーザの権限の一部を委譲している。この方法では、権限の委譲先のサービスの信頼性は、ＨＴＴＰＳによるリダイレクトにおけるＵＲＬと証明書による信用に基づいている。

【0003】

なお、背景には次のような技術がある。
１．オープンＡＰＩ・ＡＰＩエコノミー
サービス提供にあたり、複数の他サービスを利用し、組み合わせる（連携させる）ことで、効率的なサービス構築を実現させる。そのために、サービスＡＰＩをオープンにし、他者による利用を促進させる技術である。
２．マイクロサービス
サービスを構築する際に、一枚岩のプログラムで作るのではなく、機能毎に細かく分割し、ネットワークでそれらをつなげることで、サービスの部品単位のスケーラビリティと可用性を高める技術である。
３．ＯＡｕｔｈ２（非特許文献１）
自サービスを他サービスに利用させるためにＡＰＩを整備する際、自サービスが持つ個人のＩＤ・パスワードを他サービスに知らせないようにするために、他サービスへの利用認可は自サービスで行い、他サービスには「トークン」を発行し、ＡＰＩアクセスの際にそのトークンも附帯させる技術である。本技術の前は、「スクレイピング」による情報取得が一般であり、ＩＤ・パスワードの漏洩の危険性があった。
４．ＦａａＳ（Ｆｕｎｃｔｉｏｎ ａｓ ａ Ｓｅｒｖｉｃｅ）
サービス連携にあたり、使用するクラウドの資源を極小化するために、ユーザがサービスを利用するときのみ動的に資源を確保し、それ以外は資源を開放する。利用者がいないときは資源を確保しないため、全体としての資源利用効率は他のＸａａＳ（ＩａａＳ／ＰａａＳ）サービスより良い。
５．コンテナ技術
オペレーティング・システムが管理する計算機の諸資源を、ＯＳの名前空間で分離し、分離された資源間の通信には仮想的なネットワークのみを用いることで、低コストで仮想化環境を実現する技術である。

【先行技術文献】

【非特許文献】

【0004】

【非特許文献1】ＲＦＣ６７４９

【発明の概要】

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

【0005】

現在の認可技術の手法には２つの問題点がある。
１つ目は、クライアント（ユーザの一部権限の委譲先のサービス）は技術的には、通過するデータを自分の自由に利用することができ、悪意があれば利用者の情報を第三者に漏洩させることができる点である。
２つ目は、権限の委譲元のサービス（リソースサーバ）は委譲先のサービス（クライアント）をＵＲＬ等で個別に管理しなければならず、オープンＡＰＩであるにも関わらず接続先を限定したり、管理したりしなければならず、自由な接続が実現できない点である。

【0006】

従来のＢ２Ｂ２Ｃのフレームワークにおいて、中間のＢが、処理中に得られた情報を外部に漏洩することを防ぐ手段は一般には存在しない。このため、金融のようなプライバシーの高い情報を扱うサービスにおいて、オープンＡＰＩによるクライアント間の自由競争を阻害していた。また、現状では複数の銀行の口座情報を見るためには、サービスはユーザのＩＤやパスワードを預かり、代理ログインしてスクレイピングしなければならず、パスワードの漏洩のリスクがあった。

【0007】

つまり、従来技術には次のような課題があった。
日常生活で扱われる様々なデータや機器を利用するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が共通化ないしオープン化され、ユーザがＡＰＩをアクセスする第三者サービス（クライアント）を経由してサービスを利用することが望まれている。そのためには、ユーザが第三者サービスに自分の利用するサービスにおける権限の一部を委譲する必要がある。しかし、悪意ある第三者サービスが、委譲された権限を悪用してユーザの個人情報を外部に流出させる可能性があり、これを防ぐような技術的な対処方法は、現在存在していない。

【0008】

なお、ＯＡｕｔｈ２では、中間アプリケーションの信頼性を確認する手段として第三者サービスへのＨＴＴＰＳリダイレクト先ＵＲＬに対して、発行される信頼ある認証機関の証明書で確認することを想定しているが、これは社会的な契約による制約であり、技術的な情報漏えい防止の担保はとられていない。

【0009】

そこで、本発明は、上記課題を解決するために、ユーザがＡＰＩをアクセスする第三者サービスに対して技術的な情報漏えい防止ができるネットワークサービス連携方法、クライアントサービスプラットフォーム、クライアントインスタンス生成サーバ及びプログラムを提供することを目的とする。

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

【0010】

上記目的を達成するために、本発明は、あるサービスがユーザの個人情報を持ち、他サービスに自サービスを利用させるＡＰＩを提供している状況において、自サービスが持つ利用者の個人情報を他サービスが利用する際、他サービスが外部に自サービスの情報を漏洩させないよう、自サービスと他サービスを接続する閉じたネットワークを動的に生成することとした。

【0011】

具体的には、本発明に係るネットワークサービス連携方法は、
ユーザ端末毎に所望のサービスを提供するリソースサーバのオープンＡＰＩを利用可能なクライアントをインスタンスとして、
前記ユーザ端末から前記クライアントインスタンスへのアクセスを介するクライアントゲートウェーと、前記クライアントインスタンスから前記リソースサーバへのアクセスを介するサービスゲートウェーと、を備えたクライアントサービスプラットフォームに生成するネットワークサービス連携方法であって、
前記クライアントインスタンスの生成とともに、前記クライアントインスタンスへの前記クライアントゲートウェー以外からのアクセス、および前記クライアントインスタンスから前記サービスゲートウェー以外へのアクセスを遮断するファイアウォール機能を生成する
ことを特徴とする。

【0012】

また、本発明に係るクライアントサービスプラットフォームは、
ユーザ端末毎に所望のサービスを提供するリソースサーバのオープンＡＰＩを利用可能なクライアントをインスタンスとして生成するクライアントインスタンス生成サーバと、
前記ユーザ端末から前記クライアントインスタンスへのアクセスを介するクライアントゲートウェーと、
前記クライアントインスタンスから前記リソースサーバへのアクセスを介するサービスゲートウェーと、
を備えたクライアントサービスプラットフォームであって、
前記クライアントインスタンス生成サーバは、前記クライアントインスタンスの生成とともに、前記クライアントインスタンスへの前記クライアントゲートウェー以外からのアクセス、および前記クライアントインスタンスから前記サービスゲートウェー以外へのアクセスを遮断するファイアウォール機能を生成することを特徴とする。

【0013】

さらに、本発明に係るクライアントインスタンス生成サーバは、
ユーザ端末毎に所望のサービスを提供するリソースサーバのオープンＡＰＩを利用可能なクライアントをインスタンスとして、
前記ユーザ端末から前記クライアントインスタンスへのアクセスを介するクライアントゲートウェーと、前記クライアントインスタンスから前記リソースサーバへのアクセスを介するサービスゲートウェーと、を備えたクライアントサービスプラットフォームに生成するクライアントインスタンス生成サーバであって、
前記クライアントインスタンスの生成とともに、前記クライアントインスタンスへの前記クライアントゲートウェー以外からのアクセス、および前記クライアントインスタンスから前記サービスゲートウェー以外へのアクセスを遮断するファイアウォール機能を生成することを特徴とする。

【0014】

本発明は、サービス連携における被利用側が持つ利用者情報の保護を、ＦａａＳ（Ｆｕｎｃｔｉｏｎ ａｓ ａ Ｓｅｒｖｉｃｅ）の技術および最新のコンテナ技術をベースに、Ｏａｕｔｈ２（ＲＦＣ ６７４９）の仕組みから進化させたものである。

【0015】

前述したように、「他サービスに自サービスを利用してもらいたいが、自サービスの利用者のＩＤやパスワードを他サービスには知られたくない」場合の認可技術として、Ｏａｕｔｈ２規格がある。しかし、Ｏａｕｔｈ２では、「他サービスに自サービスを利用してもらう際に、自サービスの顧客データが他サービス経由で外部に流出されるのを防ぐ」ことは想定されていない。それは、他サービスのサーバが、他サービス提供者の管理下にあるためである。

【0016】

近年、クラウド技術の発展・エッジ技術の発展により、サービスの配置に自由度が増し、その究極の形として、サービスが必要な時だけ機能が活性化される ＦａａＳ（Ｆｕｎｃｔｉｏｎ ａｓ ａ Ｓｅｒｖｉｃｅ）が注目されている。

【0017】

そこで、本発明は、オープンＡＰＩを利用する他サービスをＦａａＳ化したものに限定し、特定プラットフォーム下に配置、他サービスを利用する自サービスのエンドユーザ毎に、他サービスのインスタンスを動的に生成し、情報を保護する仮想ネットワークを動的に構築ないし配置することで、上記の課題を解決する。

【0018】

具体的には、クライアント・インスタンスを生成する際、その「クライアント・インスタンス」への「クライアント・ゲートウェー」以外からのアクセス、および「クライアント・インスタンス」から「サービス・ゲートウェー」および「クライアント用リソース・データベース」以外へのアクセスの通信を遮断するファイアウォールをインスタンスに設けている。

【0019】

従って、本発明は、ユーザがＡＰＩをアクセスする第三者サービスに対して技術的な情報漏えい防止ができるネットワークサービス連携方法、クライアントサービスプラットフォーム、及びクライアントインスタンス生成サーバを提供することができる。

【0020】

詳細な動作は次の通りである。
前記ファイアウォール機能は、
前記クライアントインスタンスの有効性を確認するアクセストークンを前記リソースサーバ側から前記クライアントゲートウェーに取得させ、前記ユーザ端末から前記クライアントゲートウェー及び前記クライアントインスタンスを経由して前記サービスゲートウェーへ転送されるアクセスに前記アクセストークンを付加するとともに、
前記ユーザ端末の識別情報、前記リソースサーバのアドレス及び前記クライアントインスタンスのアドレスを前記クライアントゲートウェーから前記サービスゲートウェーへ通知させ、前記サービスゲートウェーにて前記クライアントインスタンスから前記サービスゲートウェーへ転送される前記アクセスの送信元と送信先を確認する
ことを特徴とする。

【0021】

また、本発明に係るプログラムは、コンピュータを前記クライアントインスタンス生成サーバとして機能させるためのプログラムである。本発明に係るクライアントインスタンス生成サーバは、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

【発明の効果】

【0022】

本発明は、ユーザがＡＰＩをアクセスする第三者サービスに対して技術的な情報漏えい防止ができるネットワークサービス連携方法、クライアントサービスプラットフォーム、クライアントインスタンス生成サーバ及びプログラムを提供することができる。

【図面の簡単な説明】

【0023】

【図1】本発明に係るネットワークサービス連携方法を説明する図である。

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

【0024】

添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

【0025】

［概要］
本実施形態の「エンティティ」「クライアント」「認可コード」「アクセストークン」「リソースサーバ」「認可サーバ」などの用語は、ＯＡｕｔｈ２（非特許文献１）での用法を用いる。

【0026】

本実施形態は、「リソースサーバ」のオープンＡＰＩを用いる「クライアント」が、「エンティティ」が意図していない第三者にネットワーク的に接続することを防ぐ技術である。

【0027】

本実施形態は、ＯＡｕｔｈの「認可」の仕組みをＦａａＳの技術で発展させ、仮想ネットワーク技術を取り入れることにより、従来は困難とされていた「クライアント」自身が「リソースサーバ」の情報を使いつつも、それを「クライアント」が第三者に漏洩させることを防ぐものである。

【0028】

本実施形態は、サービスの認可サーバへのユーザの認証とクライアントからのアクセスの認可に伴い発行される「認可コード」を、エンティティがクライアントへアクセスする際に認可サーバと照合し、アクセストークンの発行を受ける。それによってＯＳの制御グループ技術を使って動的に接続先を制限する。また、パスワードや金銭の振込先のような、クライアントに秘匿したい情報は事前にサーバにクライアントとは別の方法でアクセスする。なお、本技術は認証を対象としない。また、携帯端末の専用アプリや、Ｊａｖａ（登録商標）Ｓｃｉｐｒｔで書かれたＷｅｂアプリケーションのように、ユーザ側で改造可能なクライアントも対象としない。

【0029】

本実施形態は、Ｗｅｂブラウザで接続され、ユーザ側にサービスのパスワード等の重要な情報を置かないシステムを想定する（ＯＡｕｔｈにおけるＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｌｏｗ）。現在、一般のＷｅｂブラウザからは、ＣＯＲＳ等による特別な許可がないかぎり他サイトへ情報は漏洩されない。

【0030】

本実施形態におけるロール間の全ての通信は、ＨＴＴＰＳ（ＴＣＰ）で行われ、接続先のＩＰアドレスはＵＲＬから一意に決定されることを前提とする。
なお、本実施形態のロールとは次の通りである。
本発明にて、安全な中間サービス（クライアント）を実現するロールは独立した５者である。
（１）エンティティ
利用者の端末。パソコンのＷｅｂブラウザや携帯端末を想定する。
（２）クライアントサービスプラットフォーム
安全なクライアントを動作させるためのプラットフォームである。サービス事業者による運営を想定し、次を含む構成である。
・クライアントゲートウェー
・サービスゲートウェー
・クライアントインスタンス生成サーバ
・クライアントインスタンス
・クライアント用リソースデータベース
・クライアント監視モニタ（必須ではない。図１には記載していない）
（３）サービス
利用者に対する役務を提供する。本実施形態では、利用者はサービスを直接利用するのではなく、クライアントを経由して利用する。サービスは次を含む。
・認可サーバ
・リソースサーバ
（４）クライアント
利用者の代わりにサービスへアクセスする。
（５）証明書発行者
証明書は未発行でも良く、必須ではない。図１には記載していない。

【0031】

［サービス連携初期設定］
（手順１）クライアント・サービス開発者は、開発したクライアント・ソフトウェアを「クライアント・サービスプラットフォーム」の「クライアントインスタンス生成サーバ」に配置する。
ここで、クライアント開発者は、クライアント・ソフトウェアに、クライアントを利用する者の認証情報・アクセス先サービスのアドレスなどを記憶させても良い。また、配置したクライアント・ソフトウェアは任意に更新しても良い。
また、クライアント開発者は、（第三者が発行する）クライアント証明書をクライアントソフトウェアに付加し、サービスのリソース（リソースサーバ）にアクセスする際にその証明書を用いても良い。
（手順２）配置したクライアントに対し、クライアント・サービスプラットフォームはユニークなＵＲＬを発行（払い出し）する。利用者は、このＵＲＬへのアクセスを通じてクライアントを利用する。このＵＲＬはエンティティ側の端末内のソフトウェアに組み込まれてもよい。

【0032】

［動作詳細］
図１は、本実施形態のネットワークサービス連携方法を説明する図である。本ネットワークサービス連携方法は、
ユーザ端末１０２毎に所望のサービスを提供するリソースサーバ１７のオープンＡＰＩを利用可能なクライアントインスタンス１３をインスタンスとして、
ユーザ端末１０２からクライアントインスタンス１３へのアクセスを介するクライアントゲートウェー１１と、クライアントインスタンス１３からリソースサーバ１７へのアクセスを介するサービスゲートウェー１２と、を備えたクライアントサービスプラットフォーム３０１に生成するネットワークサービス連携方法であって、
クライアントインスタンス１３の生成とともに、クライアントインスタンス１３へのクライアントゲートウェー１１以外からのアクセス、およびクライアントインスタンス１３から前記サービスゲートウェー１２以外へのアクセスを遮断するファイアウォール機能を生成する
ことを特徴とする。

【0033】

前記ファイアウォール機能は、
クライアントインスタンス１３の有効性を確認するアクセストークンをサービス１０１側からクライアントゲートウェー１１に取得させ、ユーザ端末１０２からクライアントゲートウェー１１及びクライアントインスタンス１３を経由してサービスゲートウェー１２へ転送されるアクセスに前記アクセストークンを付加するとともに、
ユーザ端末１０２の識別情報、リソースサーバ１７のアドレス及びクライアントインスタンス１３のアドレスをクライアントゲートウェー１１からサービスゲートウェー１２へ通知させ、サービスゲートウェー１２にてクライアントインスタンス１３からサービスゲートウェー１２へ転送される前記アクセスの送信元と送信先を確認する。

【0034】

クライアントサービスプラットフォーム３０１は、
ユーザ端末１０２毎に所望のサービスを提供するリソースサーバ１７のオープンＡＰＩを利用可能なクライアントインスタンス１３をインスタンスとして生成するクライアントインスタンス生成サーバ１４と、
ユーザ端末１０２からクライアントインスタンス１３へのアクセスを介するクライアントゲートウェー１１と、
クライアントインスタンス１３からリソースサーバ１７へのアクセスを介するサービスゲートウェー１２と、
を備える。
そして、クライアントインスタンス生成サーバ１４は、クライアントインスタンス１３の生成とともに、クライアントインスタンス１３へのクライアントゲートウェー１１以外からのアクセス、およびクライアントインスタンス１３からサービスゲートウェー１２以外へのアクセスを遮断するファイアウォール機能を生成する。

【0035】

（ステップＳ０１）
「エンティティ（ユーザ端末１０２）」は、サービス１０１の「認可サーバ１６」にログイン認証し、クライアントインスタンス１３がリソースサーバ１７を利用する権限の範囲を示し、「認可コード」と「リソースサーバのＵＲＬ」を取得する。
（ステップＳ０２）
「エンティティ」は、サービス連携初期設定の（手順２）で示されるクライアントインスタンス１３のＵＲＬにアクセスする。その際、「クライアント・サービスプラットフォーム３０１」の「クライアント・ゲートウェー１１」の認証を受けていないエンティティは、「クライアント・ゲートウェー１１」に「ユーザＩＤ」でログイン（認証）する。
なお、このステップＳ０１とステップＳ０２は前後しても良い。また、ステップＳ０２のログインの後に、自動的にステップ１の認可サーバへリダイレクトしても良い。
（ステップＳ０３）
「エンティティ」は、「クライアント・ゲートウェー１１」に、ステップＳ０１で取得した「認可コード」および「リソースＵＲＬ」を通知する。
（ステップＳ０４）
「クライアント・ゲートウェー１１」は、「認可サーバ１６」に対して、「認可コード」を提示して、「アクセストークン」を取得する。ここで、エンティティが直接、アクセストークンを取得しないのは、エンティティの盗難ないし解析等による不正なリソースサーバへのアクセスを防ぐためである。
（ステップＳ０５）
「クライアント・ゲートウェー１１」は、「サービス・ゲートウェー１２」へ、ユーザ端末１０２の「ユーザＩＤ」や「リソースサーバのアドレス」を通知する。
（ステップＳ０６）
「エンティティ」は、「クライアント・ゲートウェー１１」を経由し、クライアントインスタンス１３へアクセスする。
（ステップＳ０７）
「クライアント・ゲートウェー１１」は、「ユーザＩＤ」に基いて、「クライアント・サービスプラットフォーム３０１」内の当該ＩＤを持つユーザ専用の「クライアントインスタンス１３」がインスタンスで形成されているか否かを確認する。「クライアントインスタンス１３」が存在しない場合は、「クライアント・インスタンス生成サーバ１４」に「クライアントインスタンス１３」の生成を指示する。
（ステップＳ０８）
「クライアント・インスンタンス生成サーバ１４」は、「ユーザＩＤ」固有の「クライアントインスタンス１３」をインスタンスで生成し、当該クライアントインスタンス１３にアクセスするためのアドレスを「クライアント・ゲートウェー１１」に返す。その際、「クライアント・サービスプラットフォーム３０１」は、ユーザ情報を長期保存するための「クライアント用リソース・データベース１５」をユーザＩＤ毎に用意し、「クライアント用リソース・データベース１５」のみ情報（アクセストークンなど）の保存ないし取得を許容しても良い。
（ステップＳ０９）
「クライアント・ゲートウェー１１」は、「サービス・ゲートウェー１２」に「クライアントインスタンス１３」のアドレスを通知する。
（ステップＳ１０）
「クライアント・ゲートウェー１１」は、「エンティティ」からのアクセスに対し、「アクセストークン」をＵＲＬ等に付加し、「クライアントインスタンス１３」へアクセスを転送する。
（ステップＳ１１）
「クライアントインスタンス１３」は、サービスの「リソースサーバ１７」へアクセスする際、ステップＳ１０で受領した「アクセストークン」を付与する。
（ステップＳ１２）
「クライアントインスタンス１３」から「リソースサーバ１７」へアクセスするＨＴＴＰＳ通信パケットは、「サービスゲートウェー１２」において、その発信元および送信先アドレスがチェックされる。発信元および送信先アドレスがステップＳ０５およびステップＳ０９で通知されたアドレス情報と一致していることを確認する。
（ステップＳ１３）
「サービスゲートウェー１２」を通過したパケットは、「リソースサーバ１７」にアクセスし、サービスを受ける。「リソースサーバ１７」は、アクセストークンで「クライアントインスタンス１３」の有効性を確認する。

【0036】

図１で説明した動作は、次の特徴を持つ。
（Ａ）エンティティは、Ｗｅｂブラウザが前提である。Ｗｅｂブラウザには、“Ｓａｍｅ Ｏｒｉｇｉｎ Ｐｏｌｉｃｙ”と呼ばれる、サーバから取得した情報を外部に漏洩させない機構が標準で装備されている。
（Ｂ）エンティティはリソースサーバ１７へアクセスするのに必要なアクセストークンを保存しない。そのため、認可コードの有効期間を短くすることで、エンティティ側のブラウザの内部状態を第三者が解析できたとしても、認可コードの有効期間を渡過していればリソースサーバ１７へのアクセスはできない。
（Ｃ）第三者サービス（クライアントインスタンス１３）は、その通信路をクライアントサービスプラットフォーム３０１が利用するクライアント・ゲートウェー１１およびサービス・ゲートウェー１２によって、アクセス先をリソースサーバ１７に制限されている。クライアントサービスプラットフォーム３０１は、他にアクセスすることをネットワーク的に防止しているため、クライアントインスタンス１３は自分が入手した利用者のプライバシーに関わる情報を、漏洩することはできない。

【0037】

従って、本実施形態で説明したネットワークサービス連携方法は、携帯端末やパソコン等から、ユーザが利用するサービスのオープンＡＰＩを利用する第三者サービス（クライアント）を利用する際、悪意のある第三者サービス（クライアント）がユーザのサービスに関する情報を他に漏洩することを防止できる。

【産業上の利用可能性】

【0038】

本発明に係るネットワークサービス連携方法は、サービスインスタンスの稼動状態を、ＣＰＵやＤＢの利用率としてサービス運営会社に通知するための品質管理サービスを別途用意しても良い。その際、ログ等の情報を経由して情報が漏洩しないよう、第三者が確認できるようにしたり、客観的な性能情報のみをサービス開発者に通知できるように考慮すべきである。

【符号の説明】

【0039】

１１：クライアント・ゲートウェー
１２：サービス・ゲートウェー
１３：クライアントインスタンス
１４：クライアント・インスタンス生成サーバ
１５：クライアント用リソース・データベース
１６：認可サーバ
１７：リソースサーバ
１０１：サービス
１０２：ユーザ端末（エンティティ）
３０１：クライアント・サービスプラットフォーム

【図1】