JP6633636B2 - サービス要求認証の方法及び装置 - Google Patents

Description

本開示は、インターネット技術の技術分野に関し、特にサービス要求を認証するための方法及び装置に関する。

関連出願の相互参照
本願は、参照によりその全体として本明細書に援用される、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｕｔｈｅｎｔｉｃａｔｉｎｇ Ｓｅｒｖｉｃｅ Ｒｅｑｕｅｓｔ」と題する２０１５年１月２８日に出願された、中国特許出願第２０１５１００４３７８６．Ｘ号に対する外国優先権を主張する。

インターネットの連続的な開発に伴い、（例えばサーバ等の）ネットワーク装置によって提供される対応するサービスを取得するためにウェブページで操作することを選択するユーザーの数が増加している。

実際の応用のシナリオでは、ネットワーク装置（以後、第1のサーバと呼ばれる）が別のネットワーク装置（以後、第２のサーバと呼ばれる）に対して、第２のサーバに対応するサービス処理を完了するように要求するサービス要求を開始する必要があるとき、第１のサーバは２つのサーバ間の認証システムにサービス要求を送信する。認証システムはサービス要求を認証する。認証が合格するとき、認証システムは第２のサーバにサービス要求を送信する。それ以外の場合、認証システムは第２のサーバにサービス要求を送信することを拒否する。

既存の技術では、通常、サービス要求は２つのサーバ間のゲートウェイを通して認証される。例えば、ユーザーが航空券を購入するためにウェブページで操作する必要があると仮定すると、ユーザーは端末を通して観光事業のウェブサイトで対応する第１のサーバに発券情報を送信する。第１のサーバは受信された発券情報に従ってゲートウェイ（認証システム）に発券要求を送信する。発券情報を受信すると、ゲートウェイは、第１のサーバがゲートウェイとの合意に署名しているかどうかを判断する。はいの場合、発券要求の認証が合格したと判断され、発券要求は航空発券システムに対応する第２のサーバに送信される。発券要求を受信すると、第２のサーバは発券サービスを処理する。ゲートウェイが、第１のサーバがまだゲートウェイとの合意に署名していないと判断するとき、発券要求の認証は失敗し、発券要求は第２のサーバに送信されるのを拒否される。しかしながら、実際の応用のシナリオでは、第２のサーバとの合意に署名していない第１のサーバまたは端末は、ゲートウェイを迂回して第２のサーバに直接的にアクセスすることができ、サーバ要求の受信時、第２のサーバはサービス要求を処理し、このことはしたがって第２のサーバのセキュリティを削減することがある。

本発明の概要は、発明を実施するための形態でさらに以下に説明される概念の選択を簡略化した形で紹介するために提供される。本発明の概要は主張されている主題のすべての重要な特徴または本質的な特徴を識別することを目的としておらず、主張されている主題の範囲を決定する上で補助として単独で使用されることを目的するものでもない。例えば、用語「技術」は、上記の文脈によって許されるように、及び本開示全体を通してデバイス（複数可）、システム（複数可）、方法（複数可）、及び／またはコンピュータ可読命令を指してよい。

本開示の実施形態は、ゲートウェイとの合意に署名していない端末または第１のサーバがゲートウェイを迂回して第２のサーバに直接的にアクセスするのを防ぐためにサービス要求を認証するための方法及び装置を提供する。

本開示の実施形態は、サービス要求を受信し、サービス要求が位置するセッションを決定すること、及び決定されたセッションに対応するトークンが存在するかどうかを判断することを含むサービス要求認証方法を提供する。トークンは、ゲートウェイからのサービス要求が位置するセッションに対応する。

トークンが存在する場合、方法はサービス要求の認証が合格したと判断することを含む。さらに、トークンが存在しない場合、方法はサービス要求の認証が失敗したと判断することを含む。

本開示の実施形態は、サービス要求を受信するために使用される受信モジュールと、サービス要求が位置するセッションを決定するために使用される第１の決定モジュールと、決定されたセッションに対応するトークンが存在するかどうか判断するために使用される判定モジュールであって、トークンが、ゲートウェイからのサービス要求が位置するセッションに対応する判定モジュールと、決定されたセッションに対応するトークンが存在すると判断されるときに、サービス要求の認証が合格したと判断するために、及び決定されたセッションに対応するトークンが存在しないと判断されるときに、サービス要求の認証が失敗したと判断するために使用される認証モジュールとを含む認証装置を提供する。

本開示の実施形態は、サービス要求の認証のための方法及び装置を提供する。方法は、サービス要求を受信することと、サービス要求が位置するセッションを決定することと、決定されたセッションに対応するトークンが存在するかどうかを判断することとを含み、トークンは、ゲートウェイからのサービス要求が位置するセッションに対応する。トークンが存在する場合、方法は、サービス要求の認証が合格したと判断することと、及び対応するサービスを処理するために進むことを含む。トークンが存在しない場合、方法は、サービス要求の認証が失敗したと判断し、対応するサービスを処理することを拒否することを含む。したがって、ゲートウェイによって転送されるサービス要求に対応するセッションだけがトークンを有することができるので、係るセッションに属する各サービス要求の認証が合格する。セッションに属さないサービス要求は、第２のサーバのサービスインタフェースとの合意に署名していない端末または第１のサーバを通るゲートウェイを迂回する業者によって直接的に送信されるサービス要求であることがあり、認証は失敗する。

本開示の実施形態をよりうまく説明するために、以下は実施形態の説明で使用される図の簡略な紹介である。以下の図が本開示の一部の実施形態だけに関することは明らかである。当業者は、創造的な取り組みなしに本開示の図に従って他の図を入手できる。

本明細書に説明される図面は、本開示のより深い理解を与えるために使用され、出願の一部を成す。本開示の概略の実施形態及びその説明は本開示を示すために使用され、本開示を制限することを目的としていない。

本開示の実施形態に係るサービス要求認証方法の全体的なフローチャートである。 本開示の実施形態に係るサービス要求認証システムの構造概略図である。 本開示の実施形態に係るサービス要求認証方法の特定のフローチャートである。 本開示の実施形態に係るサービス要求認証装置の構造概略図である。

図面に示される順序は例示的な目的のためにすぎない。モジュールは異なる順序でまたは並行して実行できる。

本発明の目的、技術的解決策、及び優位点をよりわかりやすくするために、本開示の技術的解決策は、本開示の特定の実施形態及び対応する添付図面を参照して以下に明確に且つ完全に説明される。明らかに、説明される実施形態は本開示の実施形態のすべてよりむしろ一部分を表すにすぎない。本願の実施形態に基づいて、創造的な取り組みなしに当業者によって得られる他のすべての実施形態は本願の保護範囲に属するものとする。

図１は、以下を含む本開示の実施形態に係るサービス要求認証方法のフローチャートである。

ブロックＳ１０１：サービス要求が受信され、サービス要求が位置するセッションが決定される。

本開示の実施形態では、第２のサーバによって受信されるサービス要求は、以下の３種類のサービス要求を少なくとも含む。

第１のタイプ：ゲートウェイによって直接的に転送されるサービス要求。サービス要求は、第１のサーバまたは端末によってゲートウェイを通して転送され、第１のサーバの業者は第２のサーバのサービスインタフェースとの合意に署名している。例えば、業者サーバ（第１のサーバ）がゲートウェイを通してサービスサーバ（第２のサーバ）のサービスインタフェースにアクセスする必要がある場合、業者はサービスサーバのサービスインタフェースとの合意に事前に署名する必要があり、それによってゲートウェイはサービスサーバに対して業者サーバによって送信されるサービス要求を転送する。

第２のタイプ：第１のサーバまたは端末から直接的なサービス要求。係るサービス要求及びゲートウェイによって転送されるサービス要求は同じセッションに属する。つまり、サービス要求はゲートウェイによって転送されるサービス要求と関連付けられたサービス要求である。第２のサーバは端末または第１のサーバからサービス要求を直接的に受信する。

実際の応用のシナリオでは、第１のタイプのサービス要求及び第２のタイプのサービス要求を開始する開始プログラムは通常（例えば、同じ端末または同じ第１のサーバ等）同じであり、第２のサーバは、端末または第１のサーバがゲートウェイを通過せずに第２のサーバにサービス要求を直接的に送信できるようにする。

第３のタイプ：第１のサーバまたは端末からの直接的なサービス要求。係るサービス要求は、ゲートウェイによって転送されるサービス要求が位置するセッションに属していない。つまり、サービス要求はゲートウェイによって転送されるサービス要求と関連付けられていない。実際の応用のシナリオでは、サービス要求は、第２のサーバのサービスインタフェースとの合意に署名していない業者によって第２のサーバに直接的に送信され、端末または第１のサーバを通るゲートウェイを迂回するサービス要求であることがある。例えば、業者は支払いサーバのサービスインタフェースとの合意に署名しておらず、ゲートウェイは、業者サーバによって開始されるサービス要求の受信時、支払いサーバにサービス要求を転送しない（つまり、業者サーバは支払いサーバにアクセスすることを許されていない）。しかしながら、業者サーバまたは端末は支払いサーバにサービス要求を直接的に送信して、支払いサーバにアクセスするためにゲートウェイを迂回できる。

本開示の実施形態では、ゲートウェイ及び第２のサーバは同じドメインに位置する。図２に示されるように、ゲートウェイ及び第２のサーバは破線のボックス内の同じドメインに位置する。

本開示の実施形態では、ゲートウェイによって転送されるサービス要求（第１のタイプのサービス要求）の受信時、第２のサーバは対応するセッションを確立する。その後、サービス要求と関連付けられた他のサービス要求が受信されると、その後受信される各サービス要求（第２のタイプのサービス要求）も、再確立される必要がないセッションに属する。端末または第１のサーバによって送信され、第１のタイプのサービス要求と関連付けられていないサービス要求の受信時、第２のサーバはサービス要求に対応するセッションを確立することもあれば、確立しないこともある。本開示はサービス要求に対応するセッションを確立する場合に説明される。

本開示の実施形態では、サービス要求は、支払いタイプのサービス要求、転送タイプのサービス要求、再充電タイプのサービス要求等であることがある。

実施形態では、サービス要求は、支払いタイプのサービス要求である。

支払いタイプのサービス要求は、具体的には、支払い要求、支払い要求と関連付けられたログイン要求、修正要求等を含んでよい。

例えば、業者が支払いサーバのサービスインタフェースとの合意に署名していると仮定すると、ユーザーは端末を通して業者サーバによって提供されるページで操作し、商品Ｓを購入することを選択し、ゲートウェイに支払い要求を送信する。ゲートウェイは支払いサーバに受信された支払い要求を転送する。支払いサーバは支払い要求に従って端末に支払いページをプッシュする。ユーザーは商品Ｓのオンライン支払いを完了するために支払いページで操作する。したがって、ゲートウェイから支払いサーバによって受信される支払い要求は第１のタイプのサービス要求である。

もう１つ例を挙げると、上記の例では、支払いサーバは受信された支払いサービスに従ってセッション１を確立し、セッション１に対応するトークン１を生成し、端末に支払いページをプッシュする。ユーザーは支払いページで操作し、端末を通して支払いサーバに修正要求（サービス要求）を直接的に送信する。支払いサーバによって受信され、支払い要求として同じセッション（セッション１）に属する修正要求は第２のタイプのサービス要求である。

もう１つ例を挙げると、上記例での支払い要求のリンクアドレスがＸであると仮定すると、業者が支払いサーバのサービスインタフェースとの合意に署名しておらず、端末を通して支払いサーバに支払い要求を直接的に送信する場合、支払い要求はゲートウェイによって転送される支払い要求と関連付けられておらず（つまり、サービスインタフェースに直接的にアクセスするための支払い要求及びゲートウェイによって転送される支払い要求は同じセッションに属さず）、支払い要求は第３のタイプのサービス要求であり、リンクアドレスは具体的にＵＲＬ（ユニフォームリソースロケータ）である場合がある。

ブロックＳ１０２：決定されたセッションに対応するトークンが存在するかどうかが判断される。トークンが存在する場合、ブロックＳ１０３が実行される。それ以外の場合、ブロックＳ１０４が実行される。

本開示の実施形態では、トークンは、ゲートウェイからのサービス要求が位置するセッションに対応する。

実際の応用のシナリオに関しては、第２のサーバは、ゲートウェイ識別子がサービス要求によって伝えられるリンクアドレスに存在するかどうかに従って、サービス要求がゲートウェイからかどうかを判断する。しかしながら、第２のサーバは通常、サービス要求を開始する端末または第１のサーバの業者が支払いサーバのサービスインタフェースとの合意に署名しているかどうかを判断できない。第２のサーバは、支払いサーバとの合意に署名していない業者によって直接的に送信されるサービス要求を処理し、端末または第１のサーバを通るゲートウェイを迂回する。

支払いサーバとの合意に署名しておらず、端末または第１のサーバを通るゲートウェイを迂回する業者によって直接的に送信されるサービス要求を第２のサーバが処理するのを防ぐために、本開示の実施形態では、第２のサーバはゲートウェイによって転送されない任意のサービス要求に対するトークンを生成しない。相応して、係るサービス要求のためにセッションが確立される場合、セッションはトークンも有さない。したがって、第２のサーバが第１のサーバまたは端末によって直接的に送信されるサービス要求を受信するとき、サービス要求が位置するセッションを決定でき、セッションに対応するトークンが存在するかどうかを判断できる。存在する場合、それは、係るサービス要求及びゲートウェイからのサービス要求が同じセッションに属し、サービス要求を開始した端末または第１のサーバの業者は、支払いサーバのサービスインタフェースとの合意に署名していることを示す。サービス要求の認証が合格し、対応するサービスを処理するために進むことが判断できる。存在しない場合、それはサービス要求がゲートウェイによって転送されるサービス要求と関連付けられておらず、業者は支払いサーバのサービスインタフェースとの合意に署名していなかったことを示す。サービス要求の認証が失敗し、対応するサービスの処理が拒否されることが判断できる。代わりに、それはサービス要求がゲートウェイによって転送されるサービス要求と関連付けられてよいが、ゲートウェイによって転送されるサービス要求が位置するセッションが有効ではないことを示す。現在受信されているサービス要求に対応するセッションは見つけることができない。サービス要求の認証が失敗し、対応するサービスの処理が拒否されることが判断できる。

例えば、支払いサーバがゲートウェイから支払い要求１を受信するときセッション１が確立され、セッション１に対応するトークン１が生成されると仮定する。支払いサーバが以後、端末Ａによって直接的に送信され、支払い要求１に基づいている修正要求を受信するとすれば、修正要求がセッション１に属すると判断される。

支払いサーバが端末Ｂによって直接的に送信される支払い要求２を受信するときにセッション２が確立され、支払い要求２に対応するトークンが生成されず、言うまでもなくセッション２もトークンを有さないと仮定する。（ゲートウェイ、端末Ａ、または端末Ｂ等の）送信端末、サービス要求、及びセッション及びトークンの間の対応する関係性は表１に示される。

表１では、ゲートウェイからの支払い要求１はセッション１及びトークン１に対応し、端末Ａからの直接的な修正要求はセッション１及びトーク１に対応し、端末Ｂから直接的な支払い要求２はセッション２に対応し、セッション２は対応するトークンを有さない。

支払いサーバによって受信されるサービス要求が支払い要求１であるとき、表１に従って、支払い要求１が位置するセッションがセッション１であると判断できる。さらに、セッション１に対応するトークン１が存在すると判断され、支払い要求１の認証が合格し、支払いページが提示されると判断できる。

支払いサーバによって受信されるサービス要求が端末Ａから直接的な修正要求であるとき、表１に従って、修正要求が位置するセッションがセッション１であると判断される。さらに、セッション１に対応するトークン１が存在すると判断することもできる。すなわち、修正要求を開始した端末Ａまたは業者サーバはゲートウェイとの合意に署名していると判断できる。それによって、修正要求の認証が合格し、ログインページが提示されると判断できる。

支払いサーバによって受信されるサービス要求が端末Ｂによって直接的に送信される支払い要求２であると仮定すると、表１に従って、支払い要求２が位置するセッションがセッション２であると判断される。さらに、セッション２に対応するトークンが存在しないと判断される。すなわち、業者が支払いサーバのサービスインタフェースとの合意に署名していなかったと判断できる。したがって、支払い要求２の認証が失敗し、支払いページが提示されるのを拒否されると判断できる。

ブロックＳ１０３：サービス要求の認証が合格したと判断される。

サービス要求の認証が合格したと判断されるとき、第２のサーバはサービス要求に対応するサービスを処理できる。

ブロックＳ１０４：サービス要求の認証が失敗したと判断される。

サービス要求の認証が失敗したと判断されるとき、第２のサーバはサービス要求に対応するサービスを処理することを拒否する。

本開示の図１に示される方法に従って、第１のサーバまたは端末から直接的にサービス要求を受信すると、第２のサーバは、サービス要求が位置するセッションを決定し、セッションに対応するトークンが存在するかどうかを判断する。トークンが存在する場合、それは係るサービス要求はゲートウェイによって転送されるサービス要求と関連付けられ、第１のサーバの業者は第２のサーバのサービスインタフェースとの合意に署名していることを示す。サービス要求の認証が合格し、対応するサービスを処理するために進むと判断される。トークンが存在しない場合、それは、係るサービス要求がゲートウェイによって転送されるサービス要求と関連付けられておらず、業者が第２のサーバのサービスインタフェースとの合意に署名していなかったことを示す。サービス要求の認証が失敗し、対応するサービスの処理が拒否されると判断される。これは、実際上、第２のサーバのサービスインタフェースとの合意に署名していなかった業者が、端末または第１のサーバを通るゲートウェイを迂回して、第２のサーバのサービスインタフェースにアクセスすることを防ぐことができる。

実施形態では、第２のサーバが端末または第１のサーバによって送信され、第１のタイプのサービス要求（つまり、第３のタイプのサービス要求）と関連付けられないサービス要求を受信するとき、セッションは確立されないことがある。

したがって、本開示の実施形態では、端末または第１のサーバによって送信されるサービス要求の受信時、第２のサーバは、サービス要求に対応するトークンが存在するかどうかを最初に判断する。はいの場合、それはサービス要求がゲートウェイによって転送されるサービス要求と関連付けられるサービス要求であり、サービス要求の認証が合格することを示す。それ以外の場合、それは、サービス要求がゲートウェイによって転送されるサービス要求と関連付けられておらず、ゲートウェイを迂回してサービスインタフェースに直接的にアクセスするサービス要求である可能性があることを示す。それによって、認証は失敗する。

本開示の実施形態では、第２のサーバが、サービス要求が位置するセッションに対応するトークンを生成後、トークンは（ストレージモジュールとも呼ばれる）指定された記憶領域に記憶できる。概して、（略して「Ｓｅｓｓｉｏｎ」と呼ばれる）セッション記憶領域は、セッションのコンテンツを記憶するための記憶領域である。本開示の実施形態では、トークンはセッションに対応するＳｅｓｓｉｏｎに記憶できる。Ｓｅｓｓｉｏｎの高いセキュリティのため、Ｓｅｓｓｉｏｎに記憶されるトークンも安全である。

相応して、第２のサーバが、決定されたセッションに対応するトークンが存在するかどうか、具体的にはトークンがセッションに対応するＳｅｓｓｉｏｎに存在するかどうかを判断するとき。

実際の応用のシナリオに関して、第２のサーバは、アカウント番号ログイン要求、アカウント番号登録要求、またはパスワード変更要求を含むが、これに限定されるものではない特定のタイプのサービス要求を処理する必要がある。セキュリティのために、係る特定のタイプのサービス要求の処理の前に、Ｓｅｓｓｉｏｎでの（セッションコンテンツ及びトークン等の）コンテンツが削除される必要があり、これによって係る特定のタイプのサービス要求に対応するセッションコンテンツだけが、係る特定のタイプのサービス要求の以後の処理時に確保される。

本開示の実施形態のセッションの削除が、セッションの削除よりむしろセッションコンテンツの削除を指すことに留意されたい。

例えば、セッション１が支払い要求に基づいて確立されたセッションであると仮定すると、ログイン要求（特定のタイプのサービス要求）はセッション１に属し、セッション１はトークン１に対応し、セッションコンテンツ１とセッション１のトークン１の両方ともＳｅｓｓｉｏｎ１に記憶される。ログイン要求の受信時、支払いサーバは、ログイン要求に対応するセッションコンテンツ１がＳｅｓｓｉｏｎ１に記憶され、Ｓｅｓｓｉｏｎ１のセッションコンテンツ１及びトークン１が削除されると判断する。次いで、ログイン要求が処理される。処理で生成されるセッションコンテンツはＳｅｓｓｉｏｎ１に記憶される。

実際の応用のシナリオでは、セッション１に基づいた修正要求等の他のサービス要求は、ログイン要求が処理された後に受信されてよい。例えば、支払いサーバがＳｅｓｓｉｏｎ１でトークン１を削除した後、支払いサーバはセッション１に基づいて送信される修正要求を受信してよい。Ｓｅｓｓｉｏｎ１のトークン１が削除されているので、支払いサーバは修正要求に対応するトークンがＳｅｓｓｉｏｎ１に存在しないと判断してよく、したがって、修正要求の認証が失敗したと間違って判断することがある。

本開示の実施形態では、第２のサーバが、受信されたサービス要求が特定のタイプのサービス要求であると判断するとき、及び事前に生成されたトークンが、サービス要求が位置するセッションに対応するＳｅｓｓｉｏｎに記憶された後、Ｓｅｓｓｉｏｎに記憶されたトークンは特定のタイプのサービス要求によって伝えられるリンクアドレスにコピーされる。特定の実施形態でのリンクアドレスはＵＲＬ（ユニフォームリソースロケータ）である場合がある。

実際の応用のシナリオに関して、ＵＲＬのトークンは不正に変更されることがある。ゲートウェイによって転送されるサービス要求が位置するセッションのトークンが不正に変更された後、第２のサーバは、セッションに属するサービス要求を、第２のサーバとの合意に署名せず、端末または第１のサーバを通るゲートウェイを迂回した業者によって送信されるサービス要求と間違えることがあり、係るサービス要求を処理することを拒否する。

したがって、本開示の実施形態では、特定のタイプのサービス要求によって伝えられるＵＲＬにＳｅｓｓｉｏｎに記憶されるトークンをコピーすることに関して、実施形態では、Ｓｅｓｓｉｏｎに記憶されるトークンは暗号化され、署名されてよい。暗号化されたまたは署名されたトークンは特定のタイプのサービス要求によって伝えられるＵＲＬにコピーされる。

相応して、第２のサーバが、決定されたセッションに対応するトークンが存在するかどうか、特定の実施形態では、トークンが、セッションコンテンツが記憶されるＳｅｓｓｉｏｎに存在するかどうかを判断するとき。存在しない場合、トークンが特定のタイプのサービス要求のリンクアドレスに存在するかどうかがさらに判断できる。

任意選択で、暗号化されたトークンまたは署名されたトークンが特定のタイプのサービス要求のリンクアドレスに存在すると判断されるとき、復号または署名検証がトークンに対して実行できる。復号が成功する場合または署名検証が合格するとき、それはトークンが有効であることを示す。トークンは、サービス要求が位置するセッションに対応するトークンとして決定される。復号が失敗するまたは署名検証が失敗するとき、それは、トークンが無効なトークンであることを示し、サービス要求に対応するトークンが存在しないと判断される。

Ｓｅｓｓｉｏｎはリンクアドレスよりも安全であるので、トークンは特定のタイプのサービス要求のリンクアドレスに存在すると判断されるとき、リンクアドレスのトークンは、サービス要求が位置するセッションを記憶するＳｅｓｓｉｏｎにさらにコピーできる。

上記例に続いて、支払いサーバがログイン要求（特定のタイプのサービス要求）を受信した後、Ｓｅｓｓｉｏｎ１に記憶されるトークン１はログイン要求によって伝えられるＵＲＬにコピーされる。支払いサーバがログイン要求を処理し、セッション１に属する修正要求を受信した後、支払いサーバは、修正要求が位置するセッション１を決定し、セッション１に対応するＳｅｓｓｉｏｎ１を決定し、次いで修正要求が位置するセッション１に対応するトークン１がＳｅｓｓｉｏｎ１に存在するかどうかを判断する。トークン１がＳｅｓｓｉｏｎ１に存在しないと判断されるとき、トークン１が、ログイン要求によって伝えられるＵＲＬに存在するかどうかが判断される。トークン１がＵＲＬに存在すると判断されるとき、修正要求の認証が合格したと判断できる。セッション１に対応するトークン１のセキュリティを改善するために、ＵＲＬのトークン１はさらにＳｅｓｓｉｏｎ１にコピーできる。

実施形態では、第２のサーバが、決定されたセッションに対応するトークンが存在するかどうか判断するとき、セッションに対応するトークンがサービス要求のリンクアドレスに存在するかどうかは最初に判断されてよい。存在しない場合、次いでセッションに対応するトークンがＳｅｓｓｉｏｎに存在するかどうかが判断される。すなわち、トークンがＳｅｓｓｉｏｎに存在するかどうかを判断し、トークンがリンクアドレスに存在するかどうかを判断するシーケンスは制限されない。

実際の応用のシナリオに関して、第２のサーバによって受信されるサービス要求は、認証される必要があるサービス要求、及び認証される必要のないサービス要求を含む。認証される必要がないサービス要求の場合、第２のサーバは最初にサービス要求を認証し、認証が合格すると対応するサービスを処理する。認証される必要がないサービス要求の場合、第２のサーバは対応するサービス処理を直接的に実行できる。

例えば、料金をベースにしたサービスの場合、業者は、第２のサーバのサービスインタフェースとの合意に事前に署名する必要がある。第２のサーバは対応するサービス要求を認証する必要がある。認証が合格すると、それは、端末または第１のサーバに対応する業者が第２のサーバのサービスインタフェースとの合意に署名し、対応する処理が実行されることを示す。それ以外の場合、それは、端末または第１のサーバに対応する業者が第２のサーバのサービスインタフェースとの合意の署名しておらず、対応する処理が実行されないことを示す。認証される必要があるサービス要求は、支払いタイプのサービス要求、転送タイプのサービス要求、再充電タイプのサービス要求等を含むが、これに限定されるものではない。自由なサービスの場合、第２のサーバは対応するサービス要求を認証する必要はなく、サービス要求を直接的に処理できる。

本開示の実施形態は、第２のサーバによって、決定されたセッションに対応するトークンが存在するかどうかを判断する前に、サービス要求が認証される必要があるサービス要求であるかどうかを判断することと、サービス要求が認証される必要があるサービス要求である場合、本開示の実施形態に従ってサービス要求認証方法を実行することと、それ以外の場合、サービス処理を直接的に実行することとをさらに含む。

実施形態では、認証される必要のあるサービス要求のタイプは事前に設定できる。例えば、認証される必要のあるサービス要求のタイプは、支払いタイプのサービス要求、転送タイプのサービス要求、再充電タイプのサービス要求等を含むために事前に設定できる。

本開示の実施形態に係るサービス要求認証方法は、図３に示されるように以下に詳細に説明される。

図３を参照すると、本開示の実施形態に係るサービス要求認証方法はステップを含む。

ブロックＳ３０１：サービス要求を受信するステップ。

ブロックＳ３０２：サービス要求が、認証される必要があるサービス要求であるかどうかを判断するステップ。はいの場合、ブロックＳ３０３を実行する。それ以外の場合、ブロックＳ３１０を実行する。

ブロックＳ３０３：サービス要求がゲートウェイからかどうかを判断するステップ。はいである場合、ブロックＳ３０４を実行し、それ以外の場合、ブロックＳ３０６を実行する。

ブロックＳ３０４：サービス要求に基づいてセッションを確立し、セッションに対応するトークンを生成するステップ。

ブロックＳ３０５：セッションに対応するＳｅｓｓｉｏｎにトークンを記憶するステップ。受信されたサービス要求が特定のタイプのサービス要求であるとき、サービス要求のＵＲＬにトークンをコピーする。

ブロックＳ３０６：サービス要求が位置するセッションを決定するステップ。

ブロックＳ３０７：トークンが決定されたセッションの特定のタイプのサービス要求のＵＲＬに存在するかどうかを判断するステップ。はいの場合、ブロックＳ３０９及びブロックＳ３１０を実行する。それ以外の場合、ブロックＳ３０８を実行する。

ブロックＳ３０８：トークンが決定されたセッションに対応するＳｅｓｓｉｏｎに存在するかどうかを判断するステップ。はいの場合、ブロックＳ３１０を実行し、それ以外の場合、ブロックＳ３１１を実行する。

ブロックＳ３０９：決定されたセッションに対応するＳｅｓｓｉｏｎに特定のタイプのサービス要求のＵＲＬのトークンをコピーするステップ。

ブロックＳ３１０：サービス要求を処理するステップ。

ブロックＳ３１１：サービス要求を処理することを拒否するステップ。

ブロックＳ３０７及びブロックＳ３０８は交換可能である。

本開示の実施形態に係るサービス要求認証方法は上記に説明される。同じ概念に基づいて、本開示の実施形態は、図４に示されるようにサービス要求認証装置をさらに提供する。

典型的な構成では、コンピューティング装置は１つまたは複数の中央演算処理装置（ＣＰＵ）、Ｉ／Ｏインタフェース、ネットワークインタフェース、及び内蔵メモリを含んでよい。例として及び制限ではなく、図４は例示的なサービス要求認証装置４００を示す。図４を参照すると、本開示の実施形態に係る装置４００は１つまたは複数のプロセッサ４０２、入出力（Ｉ／Ｏ）インタフェース４０４、ネットワークインタフェース４０６、及びメモリ４０８を含んでよい。

メモリ４０８は、揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、及び／または例えば読出し専用メモリ（ＲＯＭ）もしくはフラッシュＲＡＭ等の不揮発性メモリ等のコンピュータ可読メモリを含んでよい。内蔵メモリはコンピュータ可読媒体の例である。実施形態では、メモリ４０８はコンピュータ可読媒体の例として見なすことができる。

コンピュータ可読媒体は、任意の方法または技術を通して情報記憶を実装できる恒久的な媒体、非恒久的な媒体、可動媒体、及び非可動媒体を含む。情報はコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータであってよい。コンピュータの記憶媒体の例は、計算装置によってアクセスできる情報を記憶するために使用できる、相変化ＲＡＭ（ＰＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、他のタイプのランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリ、または他の内蔵メモリ技術、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、または他の光メモリ、カセット、カセットメモリ及びディスクメモリ、または他の磁気メモリ装置、または他の非伝送媒体を含むが、これに限定されるものではない。本明細書に定義されるように、コンピュータ可読媒体は、変調されたデータ信号及び搬送波等の一過性コンピュータ可読媒体（一過性媒体）を除外する。

実施形態では、メモリ４０８はプログラムモジュール４１０及びプログラムデータ４１２を含んでよい。例えば、プログラムモジュール４１０はサービス要求を受信するために使用される受信モジュール４１、サービス要求が位置するセッションを決定するために使用される第１の決定モジュール４２、決定されたセッションに対応するトークンが存在するかどうかを判断するために使用される判定モジュール４３であって、トークンがゲートウェイからのサービス要求が位置するセッションに対応している判定モジュール４３、及び決定されたセッションに対応するトークンが存在すると判断されるとき、サービス要求の認証が合格したと判断するために、または決定されたセッションに対応するトークンが存在しないと判断されるとき、サービス要求の認証が失敗したと判断するために使用される認証モジュール４４を含んでよい。

任意選択で、装置４００は、受信モジュール４１によって受信されるサービス要求が、ゲートウェイによって転送されるサービス要求であるときに、ゲートウェイによって転送されるサービス要求が位置するセッションに対応するトークンを生成するために使用されるトークン生成モジュール４５をさらに含んでよい。

装置４００は、セッションに対応するトークンが生成された後に、セッションに対応するＳｅｓｓｉｏｎに生成されたトークンを記憶するために使用されるストレージモジュール４６をさらに含んでよい。

任意選択で、装置４００は、受信されたサービス要求が特定のサービスのサービス要求であるときに、生成されたトークンがセッションに対応するＳｅｓｓｉｏｎに記憶された後に、サービス要求によって伝えられるリンクアドレスにＳｅｓｓｉｏｎに記憶されるトークンをコピーするために使用される第１のコピーモジュール４７をさらに含んでよい。

任意選択で、判定モジュール４３は、決定されたセッションに対応するトークンがＳｅｓｓｉｏｎに存在しないときに、決定されたセッションに対応するトークンがリンクアドレスに存在するかどうかを判断するために使用されてよい。

任意選択で、装置４００は、判定モジュールが決定されたセッションに対応するトークンがリンクアドレスに存在すると判断するときに、Ｓｅｓｓｉｏｎにリンクアドレスのトークンをコピーするために使用される第２のコピーモジュール４８をさらに含んでよい。

任意選択で、装置４００は、決定されたセッションに対応するトークンが存在するかどうかが判断される前に、サービス要求が、認証される必要のあるサービス要求であると判断するために使用される第２の決定モジュール４９をさらに含んでよい。

要約すれば、本開示は、サービス要求認証の方法及び装置を提供する。方法は、第１のサーバまたは端末から直接的にサービス要求を受信した後に、第２のサーバがサービス要求が位置するセッションを決定すること、及びセッションに対応するトークンが存在するかどうかを判断することを含む。トークンが存在する場合、それは、サービス要求及びゲートウェイによって転送されるサービス要求が同じセッションに属し、サービス要求を開始した端末または第１のサーバの業者は第２のサーバのサービスインタフェースとの合意に署名していることを示す。次いで、サービス要求の認証が合格し、対応するサービスを処理するために進むと判断される。トークンが存在しない場合、それは、サービス要求及びゲートウェイによって転送されるサービス要求が同じセッションに属さず、サービス要求を開始した端末または第１のサーバの業者が第２のサーバのサービスインタフェースとの合意に署名しなかったことを示す。次いで、サービス要求の認証が失敗し、対応するサービスの処理を拒否されると判断される。これは、第２のサーバのサービスインタフェースとの合意に署名しない業者が端末または第１のサーバを通るゲートウェイを迂回して、第２のサーバにアクセスするのを実際上防ぐことができる。

当業者は、本開示の実施形態が方法、装置もしくはデバイス、またはコンピュータプログラム製品として提供され得ることを理解すべきである。したがって、本開示はハードウェアの実施形態、ソフトウェアの実施形態、またはソフトウェアとハードウェアの両方を結合する実施形態として実装されてよい。さらに、本開示は、コンピュータ使用可能プログラムコードを含む（磁気ディスクメモリ、ＣＤ−ＲＯＭ、光メモリ等を含むが、これに限定されるものではない）１つまたは複数のコンピュータ使用可能記憶媒体で実装されるコンピュータプログラム製品であってよい。

本開示は、本開示の実施形態に係る方法、装置もしくはデバイス（システム）及びコンピュータプログラム製品のフローチャート図及び／またはブロック図を参照して説明される。各フローチャート及び／またはブロック図、ならびにフローチャート図及び／またはブロック図の中のフローチャート及び／またはブロック図の組合せがコンピュータプログラム命令によって実装できることが理解される。これらのコンピュータプログラム命令は、マシンを作り出すために汎用コンピュータ、特殊目的コンピュータのプロセッサ、組込みプロセッサ、または他のプログラム可能データ処理装置に提供されてよく、これによりコンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行する命令は、フローチャートの中の１つまたは複数のフローチャート、及び／またはブロック図の中の１つまたは複数のブロックに指定される機能を実装するための手段を作成する。

また、これらのコンピュータプログラム命令は、コンピュータまたは他のプログラム可能データ処理装置に特定の方法で機能するように命令できるコンピュータ可読メモリに記憶されてもよく、これによりコンピュータ可読メモリに記憶される命令は、フローチャートの中の１つまたは複数のフローチャート、及び／またはブロック図の中の１つまたは複数のブロックに指定される機能を実装する命令手段を含む製造品を作り出す。

また、コンピュータプログラム命令は、一連の操作ステップをコンピュータまたは他のプログラム可能装置上で実行させて、コンピュータまたは他のプログラム可能装置で実行する命令がフローチャートの中の１つまたは複数のフローチャート、及び／またはブロック図の中の１つまたは複数のブロックで指定される機能を実装するためのステップを提供するように、コンピュータ実装プロセスを作り出すために、コンピュータまたは他のプログラム可能データ処理装置にロードされてもよい。

また、用語「含む」及びその変形は非排他的な包含をカバーすることを目的とし、これにより「一連の要素のプロセス、方法、商品、またはデバイスを含む」の表現はこれらの要素を含むだけではなく、明示的に示されていない他の要素も含む、またはさらにプロセス、方法、商品、またはデバイスの固有の要素を含むことにも留意されたい。追加の制限のない条件下では、文「・・・を含む」によって定義される要素は、要素のプロセス、方法、商品、またはデバイスの中の追加の同一の要素を除外していない。

当業者は、本開示の実施形態が方法、システム、またはコンピュータプログラム製品として提供されてよいことを理解すべきである。したがって、本開示は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはソフトウェア及びハードウェアを結合する実施形態として実装されてよい。さらに、本開示は、コンピュータ使用可能プログラムコードを含む（磁気ディスクメモリ、ＣＤ−ＲＯＭ、光メモリ等を含むが、これに限定されるものではない）１つまたは複数のコンピュータ使用可能記憶媒体で実装されるコンピュータプログラム製品であってよい。

上記説明は単に本開示の実施形態にすぎず、本開示を制限することを目的としていない。当業者にとって、本開示は多様な変更形態及び変形形態を有してよい。本開示の趣旨及び原理により行われる任意の変更形態、同等の置換、改善等は、本開示の特許請求の範囲の範囲内に含まれるべきである。

Claims (18)

1. サービス要求認証装置によって実行されるサービス要求認証方法であって、
   サービス要求を受信することと、
   前記サービス要求がゲートウェイから来るかどうかを決定することと、
   前記サービス要求が前記ゲートウェイから来ることを決定すると、
   前記サービス要求に基づいてセッションを確立することと、
   前記サービス要求が位置する前記セッションに対応するトークンを生成することと、
   前記生成されたトークンを前記セッションに対応するセッション記憶領域に格納することと、
   前記サービス要求が位置する前記セッションを決定することと、
   前記決定されたセッションに対応する前記トークンが存在するかどうかを決定することであって、前記トークンは、前記サービス要求が位置する前記セッションに対応する、ことと、
   前記サービス要求の認証が合格したかどうかを決定することと、
   前記サービス要求が前記ゲートウェイから来ないことを決定すると、
   前記サービス要求が位置するセッションを決定することと、
   前記決定されたセッションに対応するトークンが存在するかどうかを決定することであって、前記トークンは、前記サービス要求が位置する前記セッションに対応する、ことと、
   前記サービス要求の認証が合格したかどうかを決定することと
   を含む方法。
2. 前記決定されたセッションに対応する前記トークンが存在すると決定することと、
   前記サービス要求の前記認証が合格したと決定することと、
   をさらに含む、請求項１に記載の方法。
3. 前記決定されたセッションに対応する前記トークンが存在しないと決定することと、
   前記サービス要求の前記認証が失敗したと決定することと、
   をさらに含む、請求項１に記載の方法。
4. 前記生成されたトークンが前記セッションに対応する前記セッション記憶領域に格納された後に前記サービス要求によって伝えられるリンクアドレスに前記セッション記憶領域に格納された前記トークンをコピーすることをさらに含む、請求項１に記載の方法。
5. 前記決定されたセッションに対応する前記トークンが存在するかどうかを決定することが、前記決定されたセッションに対応する前記トークンが前記セッションに存在しないとき、前記決定されたセッションに対応する前記トークンが前記リンクアドレスに存在するかどうかを決定することを含む、請求項４に記載の方法。
6. 前記決定されたセッションに対応する前記トークンが前記リンクアドレスに存在すると決定することに応えて、前記セッションに前記リンクアドレスの前記トークンをコピーすることをさらに含む、請求項５に記載の方法。
7. 前記決定されたセッションに対応する前記トークンが存在するかどうかを決定する前に、前記サービス要求が、認証されるサービス要求を含むと決定することをさらに含む、請求項１に記載の方法。
8. サービス要求認証装置であって、
   １つまたは複数のプロセッサと、
   前記１つまたは複数のプロセッサに結合されたメモリであって、前記メモリは、前記１つまたは複数のプロセッサによって実行可能な複数のモジュールを格納する、メモリと、
   を備え、前記実行可能な複数のモジュールは、
   サービス要求を受信するように構成された受信モジュールと、
   前記サービス要求がゲートウェイから来るかどうかを決定するように構成された判定モジュールと、
   前記サービス要求が前記ゲートウェイから来ることを前記判定モジュールが決定すると、前記サービス要求が位置するセッションに対応するトークンを生成するように構成されたトークン生成モジュールと、
   前記サービス要求が位置する前記セッションを決定するように構成された第１の決定モジュールと、
   前記決定されたセッションに対応する前記トークンが存在するかどうかを決定するようにさらに構成された前記判定モジュールであって、前記トークンが、前記サービス要求が位置する前記セッションに対応する、前記判定モジュールと、
   前記サービス要求の認証が合格するかどうかを決定するように構成された認証モジュールと、
   を備え、
   前記サービス要求が前記ゲートウェイから来ないことを決定すると、前記実行可能な複数のモジュールの１つまたは複数は、
   前記サービス要求が位置するセッションを決定し、
   前記決定されたセッションに対応するトークンが存在するかどうかを決定し、前記トークンは、前記サービス要求が位置する前記セッションに対応する
   ように構成される、サービス要求認証装置。
9. 前記決定されたセッションに対応する前記トークンが存在すると決定することに応えて、前記認証モジュールは、前記サービス要求の前記認証が合格したと決定するようにさらに構成される、請求項８に記載のサービス要求認証装置。
10. 前記決定されたセッションに対応する前記トークンが存在しないと決定することに応えて、前記認証モジュールは、前記サービス要求の前記認証が失敗したと決定するようにさらに構成される、請求項８に記載のサービス要求認証装置。
11. 前記実行可能な複数のモジュールは、前記セッションに対応する前記トークンが生成された後に、前記セッションに対応するセッション記憶領域に前記生成されたトークンを格納するように構成されたストレージモジュールをさらに備える、請求項８に記載のサービス要求認証装置。
12. 前記実行可能な複数のモジュールは、前記受信されたサービス要求が特定のタイプのサービス要求を備えるとき、前記サービス要求によって伝えられるリンクアドレスに前記セッション記憶領域に格納される前記トークンをコピーするように構成された第１のコピーモジュールをさらに備える、請求項１１に記載のサービス要求認証装置。
13. 前記決定されたセッションに対応する前記トークンが前記セッション記憶領域に存在しないとき、前記判定モジュールは、前記決定されたセッションに対応する前記トークンが前記リンクアドレスに存在するかどうかを決定するようにさらに構成される、請求項１２に記載のサービス要求認証装置。
14. 前記実行可能な複数のモジュールは、前記判定モジュールが、前記決定されたセッションに対応する前記トークンが前記リンクアドレスに存在すると決定することに応えて、前記セッションに前記リンクアドレスの前記トークンをコピーするように構成された第２のコピーモジュールをさらに備える、請求項１３に記載のサービス要求認証装置。
15. 実行可能命令を格納する１つまたは複数のコンピュータ可読媒体であって、１つまたは複数のプロセッサによって実行されるとき、前記１つまたは複数のプロセッサに、
    サービス要求を受信することと、
    前記サービス要求がゲートウェイから来るかどうかを決定することと、
    前記サービス要求が前記ゲートウェイから来ることを決定すると、
    前記サービス要求に基づいてセッションを確立することと、
    前記サービス要求が位置する前記セッションに対応するトークンを生成することと、
    前記生成されたトークンを前記セッションに対応するセッション記憶領域に格納することと、
    前記サービス要求が位置する前記セッションを決定することと、
    前記決定されたセッションに対応する前記トークンが存在するかどうかを決定することであって、前記トークンは、前記サービス要求が位置する前記セッションに対応する、ことと、
    前記サービス要求の認証が合格したかどうかを決定することと、
    前記サービス要求が前記ゲートウェイから来ないことを決定すると、
    前記サービス要求が位置するセッションを決定することと、
    前記決定されたセッションに対応するトークンが存在するかどうかを決定することであって、前記トークンは、前記サービス要求が位置する前記セッションに対応する、ことと、
    前記サービス要求の認証が合格したかどうかを決定することと
    を含む行為を実行させる、１つまたは複数のコンピュータ可読媒体。
16. 前記行為は、
    前記決定されたセッションに対応する前記トークンが存在すると決定することに応えて、前記サービス要求の前記認証が合格したと決定すること、または
    前記決定されたセッションに対応する前記トークンが存在しないと決定することに応えて、前記サービス要求の前記認証が失敗したと決定すること、
    をさらに含む、請求項１５に記載の１つまたは複数のコンピュータ可読媒体。
17. 前記行為は、
    前記生成されたトークンが前記セッションに対応する前記セッション記憶領域に格納された後に、前記サービス要求によって伝えられるリンクアドレスに前記セッション記憶領域に格納される前記トークンをコピーすることと、
    をさらに含む、請求項１５に記載の１つまたは複数のコンピュータ可読媒体。
18. 前記決定されたセッションに対応する前記トークンが存在するかどうかを決定することは、前記決定されたセッションに対応する前記トークンが前記セッションに存在しないときに、前記決定されたセッションに対応する前記トークンが前記リンクアドレスに存在するかどうかを決定することを含む、請求項１７に記載の１つまたは複数のコンピュータ可読媒体。

Images